NODE-RED-CONTRIB-HAPCAN UI
#Node-RED #HAPCAN #dariahomesystem #IoT #home automation #automatyka domowa
Jak podłączyć Hapcana do panelu dotykowego Node-RED?
Core vs dodatki
Node-RED i współpracujący z nim plugin do Hapcana działają u mnie na minikomputerze z systemem Windows. W innych przypadkach prawdopodobnie działa to wszystko na Raspberry Pi. Nie jest najlepszym rozwiązaniem aby logiką sterowania podstawowymi funkcjami systemu zajmował się komputer, zwłaszcza z systemem Windows.
Nie chodzi nawet o stabilność takiego rozwiązania, ale o chociażby aktualizacje systemu bądź oprogramowania, które wykonywane ręcznie czy automatycznie odcina całą automatykę w domu.
Z tego też względu, podstawowe funkcje takie jak światła, rolety muszą być od tego niezależne i u mnie jest to oprogramowane na poziomie Hapcana — gdzie moduły komunikują się pomiędzy sobą realizując podstawowe funkcje. Komputer główny zaś zajmuje się całą inteligentną stroną systemu i jego obecność nie jest wymagana.
W systemie Hapcan można również zaimplementować sceny typu powolne wygaszanie świateł, powolne zapalanie z rana ale to postanowiłem przenieść level wyżej, czyli do Node-REDa. Przyczyna jest prosta — można tam stworzyć o wiele bardziej złożone scenariusze i zdecydowanie łatwiej też nimi zarządzać.
Node-RED-dashboard
Jest to podstawowy plugin do tworzenia graficznego interfejsu dotykowego w Node-RED. Na jego podstawie omówię sposób sterowania Hapcanem z takiego interfejsu. Nie będę wnikał w szczegóły jego działania, bo to można wyczytać z jego dokumentacji.
Umieszczenie w przepływie bloczka z kategorii dashboard powoduje pojawienie się go na ekranie sterowania. Domyślnie znajduje się on pod adresem localhost:1880/ui.
Na ekranie powyżej dodałem przycisk (button), do którego wejścia podczepiony jest bloczek relay input, zaś do wyjścia relay output z Hapcana.
Jedna, bardzo ważna zasada przy podłączaniu wszelkiego rodzaju wskaźników stanu, czy to będzie dioda LED w module, czy przycisk wirtualny na ekranie:
Zawsze wyświetlaj status zwrócony z urządzenia, nie polegaj na statusie naciśnięcia przycisku, przełącznika, progressbara.
Przykładowo, jeśli zmienisz stan wirtualnego przełącznika, który wysyła dane do urządzenia to na ekranie stan tego przełącznika powinien się zmienić dopiero gdy urządzenie nada informację o zmianie statusu. W przeciwnym wypadku prędzej czy później dojdzie do rozsynchronizowania statusów. A już na pewno tak się stanie, gdy jedno urządzenie będzie sterowane z różnych źródeł.
Dlatego też, naciśnięcie przycisku 4 na dashboardzie, powoduje wysłanie do Hapcana wiadomości przełącz, zaś wykonanie tego polecenia wraca z powrotem do przycisku 4 z bloczka relay input. Dzięki temu stan przełącznika/przycisku odpowiada stanowi faktycznemu urządzenia.
Dodatkowo, jeśli klikanie w przycisk nie zmienia jego statusu, od razu widać, że coś gdzieś nie działa poprawnie.
Zmiana koloru przycisku
Przycisk sam w sobie jest jednostanowy. Można mu jednak zmienić tło, dzięki czemu będziemy w stanie odróżnić czy światło jest włączone czy nie. Przykładowo jaśniejszy kolor oznacza włączone światło.
W ustawieniach bloczka button odnajdziemy kolor tła przycisku, któremu można podać ścieżkę do wartości koloru przesłaną na wejście bloczka.
Podałem tutaj pole userField znajdujące się w obiekcie payload wiadomości msg. Dlaczego akurat tak? Ano dlatego, że bloczek relay input zaopatrzony jest w specjalne pole o nazwie userField, w którym można podać własne wartości, które zostaną dołączone do wiadomości emitowanej przez ten bloczek w zależności od stanu przekaźnika.
Jak widzisz, podane są tutaj wartości koloru, który jest potem wykorzystany jako tło. Pole userField można wykorzystać również do innych celów, tak aby uprościć połączenia i aby nie trzeba było wstawiać dodatkowe bloczki pośrednie przeliczające stan na pożądaną wartość.
Światła płynnie zapalane a status przycisku
Załóżmy scenariusz, w którym obok zwykłych świateł na przekaźnikach są podłączone również listwy LED do modułu RGB — połączone oddzielnie, tak aby móc sterować jasnością tych listew. Moduł RGB umożliwia płynne rozjaśnianie i ściemnianie świateł, więc taka też akcja dzieje się po wciśnięciu przycisku.
Problem polega na tym, że moduł RGB wysyła informację o statusie dopiero po zakończeniu animacji. Gdyby wykorzystać zatem tę informację, to naciskanie przycisku nie będzie zmieniało jego stanu aż do momentu zakończenia rozjaśniania/ściemniania. Jak to zatem rozwiązać?
Najprościej, dodać trzeci stan przycisku, pt. "trwa animacja". Poniżej, na pomarańczowo.
Animacja, czyli kolor pomarańczowy, przycisk uaktywnia w momencie naciśnięcia, zaś gdy moduł RGB zakończy rozjaśnianie/ściemnianie wyśle status, który ustawi odpowiedni kolor odzwierciedlający jego stan. Jak do tego podejść w Node-RED? Dodając bloczek change z wyjścia buttona na jego wejście.
Wejście bloczka change, podłączamy do wyjścia button, modyfikując tutaj payload na obiekt zawierający pole userField i kierujemy to do wejścia przycisku button 3. W polu userField wstawiamy wartość koloru animacji (pomarańczowy). Dzięki temu po wciśnięciu trójki, na wejście trafia wiadomość zawierająca kolor animacji, a gdy moduł RGB zakończy animację, wyśle status, który ustawi odpowiedni kolor.
Należy tutaj jednak uważać, ponieważ w tym przypadku bloczek RGB output, który steruje światłem (4,2)[2] zmienia stan na przeciwny niezależnie od tego co otrzyma na wejściu. Używając bloczka change zmieniamy wiadomość wychodzącą z bloczka button 3, zatem jeśli zawartość tej wiadomości jest istotna to ten sposób może nie zadziałać i trzeba stworzyć osobną wiadomość z kolorem.
Wincyj wejść!
W pewnym momencie możemy dojść do nieco kuriozalnej sytuacji, że przy wielu źródłach sterowania światłami nasz prosty układ zacznie wyglądać tak:
A to zechcemy dodać sterowanie pilotem, potem dodamy REST API do sterowania światłem z tableta, potem jeszcze MQTT, może bot ze Slacka też powinien móc reagować na polecenia, aha, jeszcze rozpoznawanie mowy. Zrobi się tego niezły potworek, którego późniejsze zarządzanie okaże się bardzo skomplikowane. A miało być tak pięknie :).
Oczywiście w takim przypadku jednym z rozwiązań jest podzielenie tego wszystkiego na osobne przepływy. Np. sterowanie z MQTT na osobnej zakładce, sterowanie z REST API na osobnej. Okaże się jednak, że i taki sposób jest toporny w zarządzaniu — np. gdy chcemy zmienić kolor animacji, trzeba będzie przerabiać bloczki na wielu zakładkach.
Jak to ja zrobiłem, pokażę w kolejnym wpisie dotyczącym brokera MQTT.
Inicjalizacja stanu przycisków
Jeszcze jedna ważna kwestia do ogarnięcia. Po włączeniu Node-RED nasz panel będzie świecił pustkami, do momentu aż moduł wykonawczy nada swój aktualny status. Oczywiście sam tego nie zrobi, bo i po co. Trzeba go albo ręcznie zmusić do zmiany statusu, albo go o niego zapytać.
Pójdziemy tą drugą drogą i po uruchomieniu Node-REDa odpytamy wszystkie moduły o ich status, tak aby cały system miał świeże informacje o statusie urządzeń. Do tego celu użyć można bloczka state output, oczywiście z biblioteki node-red-contrib-hapcan.
Domyślnie bloczek state output odpytuje wskazany moduł (node i group) o status. Korzystając jednak z rozszerzonych możliwości sterowania, można mu wysłać wiadomość sterującą (temat control), a w payloadzie przekazać tablicę grup do odpytania.
5 sekund po starcie Node-REDa bloczek inject wyśle taką wiadomość, którą będzie również wysyłał co 60 minut, profilaktycznie, aby upewnić się, że status wszystkich urządzeń jest poprawny. Statusy mogłyby się rozjechać np. w przypadku zagubienia ramki statusu z jakiegoś powodu, więc lepiej dmuchać na zimne.
W payloadzie, zgodnie z informacjami w pomocy do bloczka można przesłać np:
[
{
"group": 1
},
{
"group": 2
},
{
"group": 8
},
{
"group": 9
}
]
Warto również w bloczku state output ustawić opóźnienie odpytywania kolejnych grup, tak aby wszystkie urządzenia z każdej grupy nie zaczęły odpowiadać w tej samej chwili. Grozi to konfliktami na magistrali i przepełnieniem buforów innych modułów, a i może jakiś status zaginąć po drodze.
CZYTAJ DALEJ POZOSTAŁE CZĘŚCI TEGO ARTYKUŁU
TO MOŻE CIĘ ZAINTERESOWAĆ
