Cześć, jestem tutaj nowy i to mój pierwszy post, więc wybaczcie jeśli pytam o rzeczy dla Was oczywiste i jeśli robię to w niewłaściwym miejscu. Może po prostu przedstawię swój problem.
Mam kilka urządzeń Tuya (głównie przełączniki), które podpiąłem pod MQTT. W Tuya mogłem skonfigurować ich stany domyślne tak aby po powrocie zasilania po wyłączeniu były domyślnie wyłączone. W HA nie mogę sobie dać z tym rady. Nie potrafię znaleźć możliwości skonfigurowania zachowania domyślnego i nie umiem też zbudować flow w Node-REDzie, który by to robił skoro nie daje się inaczej. Czy macie jakieś gotowe rozwiązania do wykorzystania dla początkującego? Ostatnio często są zaniki zasilania i zdarza się, że żarówki świecą się po parę godzin zanim się zorientuję co się dzieje.
To nie wygląda jak rozwiązanie dla początkującego a angielski dodatkowo je komplikuje ale rozumiem, że nie ma prostszych…
Ponieważ obawiam się, że zgłębienie zagadnienia dotyczącego flaszowania urządzeń Tasmotą chwilę mi zajmie a w międzyczasie żarówki się będą palić jak dotychczas, to zapytam uzupełniająco - czy daje się zrobić jakieś powiadomienia, mówiące o tym że dane urządzenie było przez chwilę unavailable? Wtedy mógłbym je wyłączyć ręcznie. Co prawda teraz tez mogę tak zrobić ale wchodzenie co chwila w aplikację HA, żeby sprawdzić czy coś nie jest załączone jest niezbyt smart…
Obawiam, się że skoro już połączyłeś te żarówki z chmurą Tuya, to może nie być możliwa ich konwersja na alternatywny soft przez OTA (bo prawdopodobnie Tuya zaktualizowała im firmware).
W Tasmota można zdecydować o domyślnym stanie urządzenia po powrocie zasilania (i w sumie żadna zewnętrzna automatyka nie jest do tego potrzebna).
Dzięki za info. Zła wiadomość to też wiadomość użyteczna 
Będę brał pod uwagę, że może nie udać mi się wgranie Tasmoty - nawet jak już się tego nauczę. Tym bardziej aktualne jest pytanie o monitorowanie stanu ‘unavailable’, by potem ręcznie lub jakimś innym procesem wyłączyć urządzenia, które po restarcie złośliwie się załączyły… Daje się zrobić coś takiego?
Podobno w HA można wszystko.
Jakkolwiek zupełnie nie czaję sytuacji w której jesteś - z 1 posta wynika że zmieniłeś firmware z Tuya na coś innego, więc w tym “czymś innym” ustaw zachowanie po powrocie zasilania (nie ma potrzeby strzelać z armaty do muchy - po zaniku zasilania żarówki czy moduły przekaźników jakie by nie były wystartują i tak znacznie wcześniej niż router/sieć LAN, a już tym bardziej jakiś bardziej rozbudowany system automatyki).
Jeśli nadal masz w nich soft Tuya, to ustaw z poziomu chmury Tuya zachowanie po starcie (o ile to możliwe, bo szczerze mówiąc nie pamiętam jak to wygląda, ale nie kojarzę takich opcji).
Dzięki za sensowne pytanie i radę @szopen. Może zbyt skrótowo napisałem - miałem kilka przełączników i wtyczek w Tuya. Po zmianie środowiska na HA zmieniłem też bramkę na Sonoff ZBDongle USB ZigBee 3.0 CC2652P ZigBee2MQTT a przełączniki (OXT i inne Tuya) odinstalowałem z bramki Tuya i podłączyłem do tego Sonoffa. Niestety chociaż w Tuya przełączniki mialy w konfiguracji możliwość ustawienia zachowania po zaniku zasilania, teraz poprzez Sonoffa już tej opcji nie ma (chociaż żarówki z Ikei, które kupiłem później mają takie ustawienie). W żadnym z przełączników nie aktualizowałem firmware - mogły mieć miejsce tylko zwykłe aktualizacje wersji.
Ja też wolałbym nie strzelać z armaty do muchy ale po prostu nie mam już tych właściwości w przełącznikach. Zastanawiam się nad jeszcze jednym scenariuszem (chociaż wygląda mi to trochę na czary mary ale w kilku wypowiedziach zauważyłem taki wątek, więc może to działa) - podłączyć ponownie do Tuya, ustawić zachowanie po zaniku pamięci i bez odinstalowywania z Tuya sparować z tym CC2652P - może wówczas właściwość (albo chociaż sposób reakcji na przywrócenie zasilania) się przeniesie?
To całkowicie zmienia postać rzeczy - byłem przekonany, że piszesz o sprzęcie WiFi, bo się nie zająknąłeś nawet o Zigbee szczegołnie, że wspomniałęś o Tasmocie (która jest tylko na sprzęt WiFi i to pod warunkiem, że ma MCU Espressif, są pewne wyjątki od Espessif’a i wtedy nie Tamota lecz coś innego - OpenBeken, ale wciąż chodzi tylko o sprzęt WiFi).
Właściwie możesz zapomnieć o tym co było wcześniej w tym wątku, niestety szklane kule nie działają za dobrze.
Jest to jakieś rozwiązanie (swoją drogą na systemowej bramce Tuya jest szansa na aktualizację firmware).
“właściwość” się raczej nie przeniesie tzn. póki Zigbee2MQTT (w skrócie z2m) nie będzie miało takich opcji uwzględnionych w pliku “sterownika” (oficjalne to się nazywa konwerter, bo służy tłumaczeniu np. z zamkniętej odmiany Zigbee tworzonej przez Tuya na bardziej uniwersalny język automatyki) to te opcje się nie pojawią w interfejsie, ale jest jakiś cień szansy, że niektóre ustawienia zapisane wewnątrz w rejestrze urządzenia pozostają niezmienione przy ponownym parowaniu (to już zależy co wymyślił producent, teoretycznie jest możliwość ustawienia części opcji by się nie resetowały przy parowaniu, ale użytkownik nie ma na to wpływu).
Dziękuję za poświecenie w ciemności @szopen! Dzięki Tobie nie będę tracił czasu na rozkminianie zagadnień, które nie posuną mnie do przodu Spróbuję, więc jeszcze ponownego parowania i - jeśli nie zadziała - będę pracował nad próbą przejęcia kontroli nad problemem przy pomocy node_RED’a
Po prostu napisz na githubie do Koenkk - twórcy zigbee2mqtt. Napisz o jaki model chodzi, wrzuć fragment z pliku database.db dotyczące tego urządzenia i po max 2 dniach powinieneś mieć tę funkcjonalność na razie w gałęzi dev, a w najbliższym czasie w podstawowym wydaniu dla “ludu”. Wpierw tak zrobiłem, a dla kolejnego urządzenia wysłałem mu gotowca, tylko go dołączył i tyle.