Output on connect nie działa po uruchomieniu HA

Zordrac · 24 Listopad 2020 21:04

Witam wszystkich!
Od niedawna zainteresowałem się tematem inteligentnego domu, trafiłem na blog/YT Artura i… wciągnąłem się w temat Bardzo dobra robota, Artur!
Na razie jestem na etapie oglądania szybkich porad, tutoriali, generalnie przyswajam wiedzę… Trafiłem na kilka problemów, które jakoś udało mi się rozwiązać, natomiast nie umiem przeskoczyć jednego.

HA postawiony na Dell Wyse (Debian 10 + docker).

Zainspirowany jednym z filmów (ten o ostrzeżeniach pogodowych) postanowiłem zrobić sobie takie + automatyzacja (idzie burza -> wyłącz TV. Coś prostego na początek ;))

Problem: Node-Red po uruchomieniu HA nie odświeża status nodów - nie szczytuje ich stanów tylko pokazuje status “running” i nic się nie dzieje - nie ma dalszych wiadomości…

Oczywiście opcja “Output on connect” jest zaznaczona…

Co może być przyczyną? Dlaczego proces nie sczytuje stanu czujnika (on/off) i nie wysyła wiadomości?

Tak jak pisałem, HA na dockerze, HA w wersji 0.118.3, Node-Red w wersji 7.2.11

Wydaje mi się, że wcześniej przynajmniej po ręcznym Deploy proces działał (node wystawiał wiadomość) - teraz nawet to nie pomaga (odświeża się status - zamiast Running jest on lub off, ale nie wystawia wiadomości…).

Proszę szacowną społeczność o pomoc za co z góry dziękuję!
Dzięki za cierpliwość dla świeżaka…

Marcin_Domański · 25 Listopad 2020 03:58

Witaj na forum @Zordrac. Gdybyś załączył swój proces było by łatwiej doszukiwać się problemu. Lub porobił zdjęcia nodów jak masz poustawiane. Może gdzieś jest literówka…

Zordrac · 25 Listopad 2020 07:39

Oczywiście. Generalnie, na potrzebę pokazania problemu stworzyłem szybki proces:
Słońce nad horyzontem? -> Działaj…

Output on connect zaznaczony - i nie działa… Robię Deploy lub uruchamiam HA ponownie i nic się nie dzieje…
Czy ja robię coś źle, czy tak właśnie ma być, czy rzeczywiście jest jakiś błąd?

Wklejam proces:
[
{
“id”: “2dfa7978.8ee216”,
“type”: “server-state-changed”,
“z”: “7d7a21e8.4d1338”,
“name”: “”,
“server”: “45dcff6e.bc9d6”,
“version”: 1,
“exposeToHomeAssistant”: false,
“haConfig”: [
{
“property”: “name”,
“value”: “”
},
{
“property”: “icon”,
“value”: “”
}
],
“entityidfilter”: “sun.sun”,
“entityidfiltertype”: “exact”,
“outputinitially”: true,
“state_type”: “str”,
“haltifstate”: “above_horizon”,
“halt_if_type”: “str”,
“halt_if_compare”: “is”,
“outputs”: 2,
“output_only_on_state_change”: true,
“for”: 0,
“forType”: “num”,
“forUnits”: “minutes”,
“ignorePrevStateNull”: false,
“ignorePrevStateUnknown”: false,
“ignorePrevStateUnavailable”: false,
“ignoreCurrentStateUnknown”: false,
“ignoreCurrentStateUnavailable”: false,
“x”: 190,
“y”: 180,
“wires”: [
[
“9b90412e.202e”
],
[
“eb1d1f0e.1a6898”
]
]
},
{
“id”: “45dcff6e.bc9d6”,
“type”: “server”,
“name”: “Home Assistant”,
“legacy”: false,
“addon”: true,
“rejectUnauthorizedCerts”: true,
“ha_boolean”: “y|yes|true|on|home|open”,
“connectionDelay”: true,
“cacheJson”: true
}
]

Zordrac · 25 Listopad 2020 10:15

Dodatkowe info.

Jeśli odświeżam Flow (proces) z taką opcją:

(tylko ten Flow)
To NIE działa - odświeża się tylko status State Noda (podpisik na dole) ale nie wysyła wiadomości dalej
Jak odświeżam wszystkie procesy (Full Deploy) to
DZIAŁA - odświeża się status i wysyła wiadomość dalej
Wada: wtedy odświeżają się (startują) wszystkie procesy - nie tylko ten który aktualnie mam wyświetlony (modyfikowany)
Jak uruchamiam ponownie serwer Home Assistant (konfiguracja -> kontrola serwera -> uruchom ponownie) to
NIE działa - status State Nodów to “Running” i nie wysyłają wiadomości dalej…
Jak uruchamiam ponownie cały system - restart Debian-a (Supervisor -> system -> reboot) to
DZIAŁA - State Nody odświeżają status i wysyłają wiadomości dalej

Najbardziej nurtuje mnie pkt. 3… Jak zrobić, aby po restarcie HA State Nody się odświeżyły?

Załóżmy, że mamy sytuację:

serwer HA jest wyłączony/restartuje się
w międzyczasie czujnik (zalania/dymu,etc) zmienia swój stan na ON - (zalewa nas, pali się, etc.)
po uruchomieniu się HA automatyzacja stoi - State Node nie odświeża się, nie ma alarmu, woda się leje, chałupa się pali…

Czy to wina tego, że HA działa w dokerze, o co chodzi? Jak odświeżyć stany State Nodów po uruchomieniu się HA?

Marcin_Domański · 26 Listopad 2020 04:01

Restartując Home Assistant (HA) nie restartujesz Node-Red (NR). Jest to wielokrotnie powtarzane na tym forum. Trzeba to przyjąć do wiadomości. NR resetuje się tylko gdy robisz to ręcznie z Supervisor->Node-RED->RESTART lub gdy fizycznie zresetujesz całą maszynę na której jest zainstalowany HA z NR

Używając opcji:

Resetujesz tylko nody zmodyfikowane. Jeśli nie są one początkowymi (nie stoją jako pierwsze, które wyzwalają ścieżkę wiadomości (MSG), to nic w NR się nie zmieni dopóki wiadomość nie dotrze do tego zmodyfikowanego nodu.

Wracając do głównego wądku:
Jaką masz wersję NR?:

bo ja zrobiłem przykład zrobiony przez Ciebie i mam efekty zakładane przez Ciebie:

z uwagi że pisze to w nocy musiałem użyć poniżej horyzontu

zwróć uwagę na jedną rzecz:
Importując przykład dodajesz sobie “wirtualne” instancje HA do NR - widoczne są one na liście z poniższego zdjęcia:

po imporcie musisz zmienić każdy nod na HA pierwszy na liście inaczej w trakcie przetwarzania noda nie zaczyta danych z Twojej instancji NR.

Te zaimportowane “wirtualne” instancje możesz usunąć z listy w ten sposób:

Kiedy usuniesz te wirtualne instancje sererów NR - wyskoczy Ci lista nodów, które nie poprawiłeś po zaimportowaniu do NR, tak aby korzystały z twojego serwera HA.

wybierz Cancel, popraw nody z listy i usuń wirtualne serwery jeszcze raz.
Sprawdź, czy teraz będzie prawidłowo działać.

Zordrac · 26 Listopad 2020 09:01

Bardzo Ci dziękuję za obszerną i merytoryczną odpowiedź.

Na pewno przyda mi się wiedza odnośnie importowania przykładów i dodawania “wirtualnych” instancji. Prawdę mówiąc miałem z tym kłopot, bo nie wiedziałem o co chodzi.
Wczoraj postawiłem cały system (łącznie z Debianem) on nowa - jest na czysto, bez żadnych wirtualnych instancji.

Wracając do wątku. Po kolei:

Chyba najnowszą… (7.2.11)

Ja niestety nadal mam tak samo jak miałem - po przerestartowaniu HA proces stoi (State Node nie odświeża się):

U mnie tak to nie działa. Używając opcji Modified Flows NIE resetują mi się pierwsze nody (w moim przypadku State Node nadal stoi na “running”…).
State Node odświeża się dopiero gdy wybiorę opcję Full Deploy (w moim przypadku State Node:sun-sun zmienia się wtedy na chwilę na disconnected, by po chwili wyświetlić prawidłową wartość - u mnie już above_horizon i dopiero wtedy cały proces leci dalej). Problemem jest to, że w przypadku testowania jakiegoś procesu muszę odświeżyć (Full Deploy) wszystkie pozostałe.

Dziękuję za tą informację.

Aby podsumować, bo w sumie nadal nie wiem, czy mam bug-a czy feature-a (na innym forum potwierdziłem informację, że to bug i ktoś podobno to zgłosił w odpowiednie miejsce):

Czy po restarcie HA (tylko HA, nie NR) State Nody (pierwsze nody - wyzwalacze) powinny oświeżyć swój status? U mnie się nie odświeżają…
Czy mój przykład działa u Ciebie po restarcie HA? (czy od razu po restarcie HA dostaniesz powiadomienie o aktualnym stanie słońca/czujnika zalania/itp.?)
Czy po wykonaniu Deploy z opcją Modified Flows only (nie Full Deploy) State Nody powinny odświeżyć swój status? U mnie się nie odświeżają.

Jak jest u Ciebie?

Marcin_Domański · 26 Listopad 2020 10:26

Sprawdzę w wolnej chwili.
…
Po naciśnięciu:

efekt jak u Ciebie:

w trakcie uruchamiania

po zajściu zdarzenia - czyli odcięciu zasilania od żarówki (fizyczny włącznik na ścianie) zostaje wywołane zdarzenie:

analogicznie u Ciebie takie zdarzenie powinno być wywołane przez wschód słońca

u mnie kolejne wywołanie zdarzenia (włączenie światła przełącznikiem) powoduje ponowne wywołanie zdarzenia na ścieżce MSG

Po restarcie HA:

stan - z ostatniego zdarzenia

Po restarcie Node-RED:

stan - uruchamianie (czyli reset)

wywołanie zdarzenia…

fizyczny restart maszyny

stan - uruchamianie (czyli reset)

ad. 1

(…) (czy od razu po restarcie HA dostaniesz powiadomienie o aktualnym stanie słońca/czujnika zalania/itp.?)

NIE - dopiero po nadejściu zdarzenia

ad. 2

Czy po wykonaniu Deploy z opcją Modified Flows only (nie Full Deploy) State Nody powinny odświeżyć swój status?

NIE RESETUJE SIĘ - pozostaje w stanie z ostatniego zdarzenia

Zordrac · 28 Listopad 2020 17:24

Bardzo Ci dziękuję za tak obszerne wyjaśnienia!
Najbardziej zastanawiało mnie czy czujnik (np. czujnik zalania) odświeży swój status jeśli zalanie nastąpi w trakcie restartu HA. Wg tego:

Powinien odświeżyć się dopiero po zmianie swojego stanu znowu na off, co było by poważnym problemem…

Jednak - wczoraj otrzymałem pierwsze zabawki, między innymi czujnik zalania (Aqara). Zrobiłem test.

Czujnik suchy
Restartuję HA
W tym czasie wkładam czujnik do wody
Po restarcie HA czujnik się odświeża na on, puszcza wiadomość - jest alarm, jest OK.
To dla mnie zamyka wątpliwość, którą miałem dotyczącą czy to zadziała…

Mam trochę inny problem - Artur mówił w filmie:

że u siebie sprawdza za pomocą noda !Catch jeśli czujka przestanie działać.

Jak to zrobić?
U mnie, po wyciągnięciu baterii z czujnika po 20 minutach:

Node Red pokazuje off na czujniku (brak zalania)
sensor baterii pokazuje 100%
Zigbee2MqttAssistant - pokazuje czujnik cały czas na mapie (tak, jakby był normalnie podłączony)

Czyli czujnik na pewno nie zadziała, a użytkownik jest przekonany, że wszystko jest ok…

Jak sprawdzacie czy dana czujka jest jeszcze dostępna?

macek · 28 Listopad 2020 18:32

A jaką masz pewność, że faktycznie dokładnie w momencie restartu HA, tym samym czasie (co do kilku milisekund) włożyłeś czujnik do wody? . Aby taki test byl wiarygodny, powinno byc:

Czujnik suchy
Stop HA
Wkładam czujnik do wody
Start HA
Weryfikacja stanu czujnika

Zordrac · 28 Listopad 2020 22:29

Spokojnie, HA restartuje się dobre kilkanaście sekund. Czujnik wkładałem do wody jak był restartowany.
Poza tym, robiąc stop HA muszę (chyba?) ponownie uruchomić całego Debiana (albo przynajmniej dokcera?) co powoduje odświeżenie wszystkich czujników… O tym wiedziałem i to od początku było ok…
Zastanawiała mnie tylko sytuacja po restarcie HA (tylko HA) - State Nody mają wtedy status Running (nie pokazują aktualnego statusu)… Jeszcze raz - jak zrobię reset całego systemu to Status Nody pokazują swoje statusy (odświeżają się)…

OK, to jest nie ważne już.

Pytanie z trochę innej beczki: w jaki sposób sprawdzić czy dany czujnik (w moim przypadku Aqara Leak Sensor) jest nadal dostępny - czy cały czas jest online?

Nie bardzo potrafię to ogarnąć:

używam CC2531
czujkę mam wrzuconą w kuchni, za szafką, na podłodze - jakieś 8 m od CC2531
po jakimś czasie HA (w sekcji developer) pokazuje link_quality tej czujki: “0” - ale czujka działa - wrzucam do wody i jest ok, działa
po wyciągnięciu czujki “na powierzchnię” odświeżam jej status guzikiem (na sensorze) - pokazuje np. quality 34
wyciągam baterię - po 30 minutach quality nadal pokazuje “34”, widać ją na mapie Zigbee2MqttAssistant - słowem nie ma żadnych widocznych objawów, że jest off-line, ale oczywiście w przypadku zalania nie zadziała…

Pytanie: jak sprawdzać z poziomu NR (lub HA) czy czujka cały czas jest online?

Marcin_Domański · 29 Listopad 2020 11:27

Nie posiadam urządzeń na Zigbee, nie pomogę w tej kwestii… @macek ma rację, powinieneś sprawdzić zmianę stanu po zatrzymaniu HA i dopiero potem go uruchomić.
Zmiana stanu może być fałszywa, bo dokonałeś jej w trakcie zatrzymywania usługi lub jej uruchamiania (nie znasz dokładnego momentu)… nie masz wtedy 100% pewności zadziałania.
Ktoś mądrzejszy powinien się wypowiedzieć, czy stan czujki nie jest zapisywany/zaczytywany z czujek przez Twój CC2531 i to z niego pobiera dane sam HA, bo na logikę przy restarcie samego HA nie dochodzi do odcięcia zasilania portu USB CC2531. Nie znam zasad działania protokołu Zigbee. Jeżeli chodzi o mqqt to przy korzystaniu z urządzeń z oprogramowaniem układowym Tasmota reguluje się okres raportu stanu końcówki.

Sprawdź, czy czasem w czujniku nie ma kondensatora podtrzymującego w razie wyczerpania baterii.
Wyciągnij baterie kiedy jest suchy czujnik, zamknij obudowę i zasymuluj zalanie czujnika. Jak się zmieni stan to znaczy że ma kondensator (chwilowe podtrzymanie).

macek · 29 Listopad 2020 12:25

Dokładnie jest tak jaki piszesz, Tasmota co TelePeriod wysyła stan czujników i oczywiście przy każdej zmianie stanu. Czujnik Zigbee (taki na baterie) wysyła dane tylko przy zmianie stanu, nie ma czegoś takiego jak cykliczne wymuszanie przesyłania stanu. Czujnik (na baterie) ma dodatkowy przycisk na obudowie, którym można wymusić przesłanie stanu.
Ostatnio “zepsułem” sobie CC2531 i koordynator uruchomiłem dopiero po 3 dniach, stan wszystkich czujników był sprzed 3 dni, dopiero po zmianach stanów czujników (np. linkquality) poprawne wartości pokazały się w HA. Do tej pory (z braku czasu) nie udało mi się dowiedzieć czy można ręcznie wymusić stan czujników Zigbee wysyłając odpowiednie zapytanie (publish message) przez mqtt.
Nie wiem jak to działa w przypadku korzystania z Conbee II.

Zordrac · 29 Listopad 2020 13:21

Po kolei:
Odnośnie testów czujki wody (Aqara Leak Sensor)

1 test

HA wyłaczony (stop)
poczekałem 3 minuty, czujka do wody
uruchomiłem ponownie cały system (Debian)
po uruchomieniu - status czujki: “Running” - brak alarmu !!! (czekałem 5 minut na ewentualne odświeżenie)
po wyciągnięciu czujki z wody, jej wytarciu i ponownym włożeniu do wody - dopiero wtedy działa

Tak samo się zachowała gdy zasymulowałem zanik zasilania.

czujka sucha
wyciągnąłem zasilanie z komputerka na którym jest HA
czujka do wody
zasilanie on
wszystko się uruchomiło, czekam 5 minut, czujka ma status “Running” i brak alarmu!!!
dopiero jej wyciągnięcie z wody i włożenie z powrotem daje efekt…

Bez ręcznego odświeżenia stanu (czujka ręcznie z wody i z powrotem do wody) status w systemie to cały czas off (niby cisza, spokój, a dom jest zalewany )

Wniosek: tak jak pisze @macek, czujnik na baterie Zigbee wysyła dane tylko przy zmianie swojego stanu (rzeczywiście przy wrzuceniu do wody miga na chwilę niebieskie światełko). Wydaje się, że może nas spotkać sytuacja, że zacznie nas zalewać (palić się, cokolwiek) przy restarcie serwera - nie otrzymamy o tym żadnego powiadomienia, alarm nie uruchomi się!!!
Jak to obejść?

2 test

HA działa, czujka sucha
wyciągam baterię
czujka do wody
jest alarm
Czujka ma podtrzymanie przez kondensator, energii starczyło na dwie zmiany (do wody - on, z wody off), później już przestała działać.

Bardzo nurtuje mnie kwestia z testu 1 (czyli zdarzenie w momencie braku zasilania serwera i trwanie stanu po uruchomieniu się HA) oraz (co również jest powiązane z bezpieczeństwem), jak sprawdzać czy dana czujka (niech będzie ta Aqara Leak, zigbee) jest cały czas online?

@artur w tym filmie opowiada o tym, że kontroluje swoje “super ważne procesy”, np. czujkę zalania poprzez obsługę błędów.
Czy ktoś mógłby to rozwinąć?

Czy (i jak) da się wymusić odświeżenie stanów czujek (Zigbee) po restarcie serwera?
Czy (i jak) sprawdzać czy dana czujka jest cały czas obecna?

Zordrac · 29 Listopad 2020 20:49

Na pkt 2. mam wstępną koncepcję - nasłuchuję w Node-Red tematu MQTT na którym nadaje czujka (w moim przypadku zigbee2mqtt/leak_sensor1). Jak nie ma ponowienia komunikatu na tym kanale powyżej 2h (node: trigger) to dostanę alarm.
Trigger zaczyna liczyć czas po otrzymaniu ostatniego komunikatu - pewną wadą na tą chwilę jest ewentualny reset HA/systemu (trigger nie rozpocznie odliczania) - chociaż to pewnie jest łatwe do poprawy… (sprawdzenie czy HA się zresetował i odpalenie odliczania na triggerze)

Nadal nie wiem jak ogarnąć pkt.1 - jak odświeżyć stan czujki po restarcie sytemu??

Marcin_Domański · 30 Listopad 2020 01:11

Sprawdź tą opcje, czy po restarcie maszyny / Node-RED’a nie odpali Ci Trigera.

artpc · 30 Listopad 2020 01:54

Sprawdź Automatyzacje HA " Power state on HA start-up"
Przy uruchomieniu możesz sprawdzić stan czujników

platform: homeassistant
event: start
service: mqtt.publish
data:
data: null
topic: cmnd/%shutters grouptopic%/shutterposition
payload: ‘’

Zordrac · 30 Listopad 2020 07:44

Odpala, dziękuję.
Po restarcie systemu podaje ostatni stan sprzed restartu i odpala triggera (wystarcza do sprawdzania czy czujka odzywa się co jakiś czas). Przy okazji, Aqara Leak Sensor podaje swój status co 50 minut (jakby kogoś to interesowało), lub oczywiście w momencie zmiany stanu zalania.
Oczywiście problemem nadal jest to, że po restarcie i wykonaniu “output on connect” podaje stan sprzed restartu (czyli np. off) a nie aktualny (w międzyczasie czujka zaczęło nas zalewać i powinno być on…) dlatego chciałbym rozgryźć to:

Próbuję to wpisywać do automations.yaml (między nawiasy - na razie ten plik mam pusty, są tam tylko nawiasy kwadratowe), ale otrzymuję błąd, że konfiguracja jest nieprawidłowa…
Jak to dokładnie powinno wyglądać?
Domyślam się, że będzie trzeba też jakoś zmodyfikować topic (nie shutter-sy tylko leak_sensor…).

Zastanawiam się czy to w ogóle ma szansę zadziałania - słabo się na tym znam, ale z tego co zauważyłem/doczytałem to komunikacja z bateryjnymi urządzeniami Zigbee jest raczej inicjowana jednostronnie (to urządzenie musi rozpocząć transmisję, następuje wymiana informacji i urządzenie/czujka przechodzi w stan “bez odbioru” - aby oszczędzać baterię).
Jeśli tak jest to rzeczywiście może się okazać, że nie będzie dało się odświeżyć stanu tej czujki - trzeba czekać 50 minut na kolejne jej zgłoszenie…

Czy ktoś może to skomentować? Czy do bateryjnej czujki Zigbee można “zagadać” i ona odpowie czy trzeba czekać na transmisję z jej strony?

macek · 5 Grudzień 2020 08:50

Zgodnie z uzupełnioną dokumentacją na stronie Xiaomi SJCGQ11LM control via MQTT | Zigbee2MQTT nie ma takiej możliwości, np.

Water_leak

Indicates whether the device detected a water leak. Value can be found in the published state on the water_leak property. It’s not possible to read (/get) or write (/set) this value. If value equals true water_leak is ON, if false OFF.

Dotyczy to także pozostałych podobnych parametrów i czujników. Transmisję wyzwala czujnik na baterię.

Zordrac · 6 Grudzień 2020 18:16

Dziękuję. Już wszystko rozumiem. Warto o tym pamiętać (po restarcie HA “widzi” ostatni stan sprzed restartu - nie koniecznie stan aktualny…).