Witam w kolejnej części serii artykułów poświęconych geolokalizacji tym razem zajmiemy się tą częścią, która jest najważniejsza w inteligentnych domach czyli automatyzacją. W poprzednich artykułach dowiedzieliśmy jak śledzić użytkowników oraz jak tworzyć strefy. Teraz pora połączyć jedno z drugim. Zrobimy więc dwie automatyzacje, które potrafią wykorzystać te informacje:

  • notyfikacja gdy dziecko dotrze/opuści szkołę
  • zmniejszenie ogrzewania gdy nikogo nie ma w domu

Te proste przykłady powinny wystarczyć aby zrozumieć działanie i sposób użycia posiadanych informacji. Zatem zaczynamy.

Będzie nam potrzebna lokalizacja dziecka (po informacje jak lokalizować osoby odsyłam do części pierwszej tej serii artykułów) i strefa szkoły (dodawanie ich opisałem w części drugiej).

Mając obie te informacje nie pozostaje nam nic innego jak przejść do Node-Red aby utworzyć nasze automatyzacje. Instalacje Node-Red'a opisałem tutaj, a w tym artykule wyjaśniam podstawy jego użytkowania.

Gotowy przykładowy proces dla powyższych obu automatyzacji może wyglądać następująco:

Jest to ogólny proces, który wysyła powiadomienie gdy dana osoba znajdzie się lub opuści określoną lokalizację. Prześledźmy szczegółowo jego składowe biorąc pod uwagę przykład z dzieckiem docierającym/opuszczającym szkołę.

Wyzwalaczem tego procesu jest zmiana lokalizacji danej osoby czyli w moim przypadku córki Julii. Dlatego jako wyzwalacza używam nodu event:state bo proces ma się uruchomić na zmianę stanu, a jak wiemy z poprzedniego artykułu gdy dana osoba jest w jakiejś strefie to stan tej osoby przyjmuje nazwę tej strefy. Poniżej szczegółowa konfiguracja wyzwalacza dla Julii:

Oczywiście istotne są dwa pola Entity ID które w moim przypadku odpowiada osobie Julii (która w konfiguracji w HA ma przypisany swój telefon i z niego pobierana jest jej lokalizacja. Przypisanie urządzeń do osób opisuję w tym filmie). Drugie pole to Output only on state change co jest raczej oczywiste. Interesuje mnie wyzwalanie procesu tylko jeżeli status ulegnie zmianie.

Kolejny nod to change jego konfiguracja wygląda następująco.

Jest to o tyle ciekawe że pokazuje możliwość NR, który zezwala na tworzenie zmiennych możliwych do wykorzystania później (w tym przypadku jest to zmienna msg.person z imieniem osoby i msg.czasownik z żeńską lub męską formą czasownika dotrzeć). Wszystko dlatego, że w komunikatach używam później jednego tekstu, a w zależności od tego kto się gdzie pojawi komunikat brzmi poprawnie - "po polsku". Wyjaśni się to za chwilę gdy będziemy omawiać nod z wiadomością do powiadomienia.

Następny nod to switch, a jego konfiguracja jest następująca:

Tu upewniam się, że nowa lokalizacja jest faktycznie inna od poprzedniej aby nie wysyłać komunikatów tylko dlatego że system stwierdził, że nastąpiła jakaś zmiana, a tak naprawdę osoba jest ciągle w tej samej strefie. Jak łatwo się domyślić tu porównuje czy aktualna nazwa strefy jest różna od poprzedniej jaka wzbudziła proces. Jest to element zabezpieczający przed nadmiernymi komunikatami i przy założeniu, że wszystko poprawnie zawsze zadziała można go pominąć jednak ja wolę go mieć.

Kolejny element procesu to nod stoptimer, który wygląda następująco:

Jest to kolejne zabezpieczenie przed chwilową zmianą strefy (np.: z powodu błędu GPS) dopiero jeżeli zmiana stanu utrzyma się przez 3 minuty proces jest puszczany dalej. W innym wypadku następuje reset całego procesu i nie mamy mylnych komunikatów.

Następny w procesie to ponownie nod switch, który rozdziela już proces na poszczególne interesujące nas strefy. Jego konfiguracja wygląda następująco:

Z komunikatu msg, który jest głównym komunikatem całego procesu wyjmuję nazwę strefy przekazanej od wyzwalacza, a przechowywanej w payload. Dodaje kolejne warunki na każdą zdefiniowaną w HA strefę (w tym tą istotną dla tego przykładu - szkola), dzięki czemu na każdą z nich mogę określić inną czynność w procesie. W naszym przypadku ta czynność to będzie powiadomienie.  

W kolejnym kroku używam nodu function by zdefiniować treść komunikatu powiadomienia. Jego konfiguracja dla strefy szkola wygląda następująco:

Pod zmienną payload podstawiam wiadomość, którą później wysyłam na komunikator bądź na głośniki w domu (do tego używany jest podproces Powiadomienie omówienie go nie jest częścią tego artykułu i można go zastąpić wysyłając wiadomość na dowolny nod odpowiadający Waszym powiadomieniom). Jak widać treść tej wiadomości zawiera zdefiniowane wcześniej zmienne: msg.person i msg.czasownik. Dzięki czemu dla przypadku gdy Julia dotrze do szkoły treść komunikatu będzie następująca:

Informuję, że Julia dotarła do szkoły

natomiast gdy ja dotrę do szkoły to treść komunikatu będzie następująca:

Informuję, że Artur dotarł do szkoły

wynika to z faktu, że dla mnie zmienna msg.person ma wartość Artur, a zmienna msg.czasownik wartość dotarł.

Przypadek opuszczenia strefy jest obsłużony przez strefę not_home gdyż taką wartość przyjmuje każdy kto nie znajduje się w żadnej zdefiniowanej strefie. Więc każde opuszczenie jakiejś strefy daje u mnie ogólny komunikat, który widać poniżej:

Czyli za każdym razem gdy ktoś opuszcza dowolną strefę dostaję powyższy komunikat.

Jak widać powyższy proces nie jest jakiś bardzo skomplikowany, a daje nam szerokie pole do popisu. Nie musimy się ograniczać do powiadomień. W moim przypadku można go usprawnić o przechowywanie ostatniej strefy w jakiej ktoś się znajdował przed jej opuszczeniem i dodanie jej do komunikatu opuszczenia strefy. Tak aby brzmiał on zamiast 

Artur opuścił aktualną strefę

to

Artur opuścił pracę

Kolejny mój błąd, który pewnie będę poprawiał w najbliższej przyszłości to dla opuszczenia strefy jest zawsze czasownik w formie męskiej co denerwuje dziewczyny u mnie bo komunikat to np:

Julia opuścił aktualną strefę

Jednak pomimo tych braków, które u siebie możecie łatwo zmienić to cały proces działa bez żadnych problemów, a jego konstrukcja z wykorzystaniem zmiennych umożliwia łatwą rozbudowę i upraszcza jego konstrukcję.

Zachęcam do obejrzenia filmu, który jest częścią tego artykułu gdzie omawiam rzeczy jeszcze dokładniej, a do tego przedstawiam dodatkowy przykład podany na początku.