Przyznaję bez bicia, nie czytałem… teraz próbuję czytać, tylko nie wiem czy już nie za późno na rozwiązanie problemu… 
mądry Polak po szkodzie
Nigdy nie jest za późno, a w ostateczności
- to Linux i wszystko jest gdzieś ustawiane w plikach konfiguracyjnych,
- można skorzystać z backupu (ale to NIE jest konieczne, bo i tak musisz dostosować konfiguracje)
a lepiej późno niż wcale.
Dzięki, doczytałem - aby przywrócić sensor.XXX_action należy dodać jedną linijkę kodu w configuration.yaml
Hmm jakoś opacznie czytasz dokumentację, zasadniczo chodzi o to aby pozbyć się zaszłości konfiguracyjnych, bo wkrótce (?) nadejdzie wersja która przestanie je obsługiwać…
Mam problem z konfiguracją tego noda:
Rozumiem, że w pierwszym kroku należy dodać serwer Z2M:
Więc próbuję go dodać zgodnie z poniższą konfiguracją wyciągnietą z Z2M:
Dodaję serwer:
Na końcu wybieram Refresh Device list w poniższym kroku ale lista urządzeń wciąż pozostaje pusta…
Wygląda więc na to, że nie ma wjazdu na serwer MQTT…
Możesz pokazać jak wyglada u Ciebie kompletna konfiguracja noda [in]?
Jest podobna do Twojej. Mój użytkownik i hasło są skonfigurowane w Ustawienia → Osoby–> Użytkownicy. Tak skonfigurowany użytkownik nie musi znajdować się w konfiguracji brokera MQTT.
To ma być użytkownik do łączenia się z brokerem mqtt a nie ten z konfiguracji dodatku zigbee2mqtt.
Możesz użyć też zwykłego noda mqtt in i zasubskrybować pojedynczy topic swojego przycisku i otrzymasz to samo …
1 Like
I właśnie ^tutaj^ był mój błąd.
Musiałem także zmienić adres serwera MQTT z url na ip.
Po zmianie zadziałało natychmiast!
Dziękuję
2 Likes
Dziękuję wszystkim za informacje w tym temacie - zwłaszcza Tobie @szopen
Bardzo obawiałem się tej aktualizacji (m.in. ze względu na nieaktualizowany koordynator, czyli jeden z pierwszych SkyConnect 7.1.1.0) ale dzięki temu wątkowi udało się prawie od “pierwszego strzału”.
Zgodnie z zaleceniami nie chcę aktualizować na razie SkyConnect, bo to ta seria ma podobno problem z zasilaniem. Tym bardziej, że w trakcie jego używania przez 2 lata nie wystąpił ŻADEN problem 
Uzupełniłem config o:
advanced:
homeassistant_legacy_entity_attributes: false
homeassistant_legacy_triggers: false
legacy_api: false
legacy_availability_payload: false
device_options:
legacy: false
Po restarcie dodatku zmieniłem “false” na “true” w całej sekcji advanced aby móc sterować urządzeniami z poziomu HA.
Działa ale niepokoją mnie wpisy, które powtarzają się w logu Supervisor:
2025-01-08 06:20:29.398 WARNING (MainThread) [supervisor.addons.options] Option 'advanced' does not exist in the schema for Zigbee2MQTT (45df7312_zigbee2mqtt)
2025-01-08 06:20:29.398 WARNING (MainThread) [supervisor.addons.options] Option 'device_options' does not exist in the schema for Zigbee2MQTT (45df7312_zigbee2mqtt)
Powinienem jednak usunąć te sekcje? Czy jednak to wina braku uaktualnienia do wersji 2025.01?
Tak, najwyraźniej czytałeś wymyślone przez użytkowników obejścia problemu aktualizacji (gdzie na siłę ludzie uruchamiają opcje przeznaczone do wycofania zamiast zmodyfikować konfiguracje systemów ID używających Z2M), a nie dokumentację, wiele z opcji usunięto i można je śmiało wywalić z pliku konfiguracyjnego, część zmieniono i teoretycznie powinny były zostać podczas wielofazowej aktualizacji zmienione na ich nowe odpowiedniki.
Dlatego pisałem by dostosować konfigurację do breaking changes PRZED aktualizacją, by skrypty modyfikujące pliki konfiguracyjne miały łatwiej.
Zigbee2MQTT jest ODDZIELNYM serwerem i on w ogóle nie współpracuje z HA (inna kwestia to konteneryzacja obsługiwana przez Supervisora, ale nikt tu nie mówi o konfiguracji Dodatku, tylko mówimy o konfiguracji serwera Z2M, która nie ma nic do HA).
Działało Z2M i przestało. Problem zaczął się chyba po awarii zasilania. Próbowałem wrócić do starej wersji Z2M i nic mi nie wychodzi. Dongl jest widoczny w sprzęcie w HA. Gdzie jest problem? Konfiguracja poniżej:
socat:
enabled: false
master: pty,raw,echo=0,link=/tmp/ttyZ2M,mode=777
slave: tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5
options: "-d -d"
log: false
mqtt: {}
serial:
port: >-
/dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_c0919871610cee11b76b2fd6f49e3369-if00-port0
Logi:
READ THIS CAREFULLY
Refusing to start because configuration is not valid, found the following errors:
- devices/0xa4c1385ee5b8c8d0/homeassistant/name must be string
If you don't know how to solve this, read https://www.zigbee2mqtt.io/guide/configuration
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[20:54:20] INFO: Preparing to start...
[20:54:20] INFO: Socat not enabled
[20:54:21] INFO: Starting Zigbee2MQTT...
Starting Zigbee2MQTT without watchdog.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Oczywiście dopisałem adapter: zstack w konfiguracji, ale to nie pomaga.
UWAGA z góry założyłem, że zrobiłeś aktualizację Z2M do wersji 2.x.x z 1.x.x w nieodpowiedzialny sposób i dlatego przeniosłem posty tutaj (to nie jest żaden “brak dongla”!)
Bo zapewne dopisałeś to w konfiguracji Dodatku, a nie samego serwera Z2M,
ponadto masz też jakieś grubsze błędy w konfiguracji, ale najwyraźniej nie czytasz tylko robisz na pałę i to mogą być tego skutki.
By się cofnąć do starszej wersji musisz albo przywrócić kompletny backup wraz z konfiguracją (a nie samego addona), bo konfiguracja już została “zmielona” przy procesie aktualizacji
albo wykorzystać backup cząstkowy i ręczną edycję plików
twoja stara konfiguracja dla wersji 1.x.x jest teraz w pliku
configuration_backup_v1.yaml
więc można się cofnąć ręcznie, ale to trzeba robić z głową…
jeśli już cofnąłeś wersję addona z cząstkowego backupu
- zatrzymaj dodatek,
- skopiuj wszystkie pliki konfiguracyjne gdzieś na bok, np. w udziale
sharezrób sobie jakiś katalog na to śmietnisko i tam wrzuć wszystko co masz w tej chwili w/config/zigbee2mqtt - następnie wywal wszystko co jest zbędne z
/config/zigbee2mqtt(masz już kopie gdzieś indziej zrobione w 2. ale jeśli olałeś kopię, to nic nie usuwaj!), a nazwę plikuconfiguration_backup_v1.yamlzmień naconfiguration.yaml(to wymaga myślenia co się robi, bo już jedenconfiguration.yamltam jest więc np. zmień temu istniejącemu nazwę naconfiguration.yaml.bakalbo usuń) - teraz możesz uruchomić starą wersję Z2M czyli 1.x.x (nie wiem jaką miałeś przed aktualizacją, ale to właśnie do niej możesz wrócić)
- jeśli działa przeczytaj dokumentację i ochłoń
- przygotuj się mentalnie na zmiany, w szczególności pozbądź się wszystkich przeszkód dla breaking changes, trzeba mieć na to czas, bo będziesz musiał edytować swoje automatyzacje, przepływy NR czy cokolwiek co integrowałeś z Z2M
- póki w katalogu konfiguracyjnym serwera Z2M jest takie śmietnisko nie możesz aktualizować Dodatku do wersji 2.x.x pokaż WSZYSTKO co masz to ustalimy co naprawdę robić…
2 Likes
… najwyraźniej czytałeś wymyślone przez użytkowników obejścia problemu aktualizacji …
Nie do końca rozumiem co masz na myśli, bo dopisałem sekcje do configuration.yaml postępując zgodnie z informacją dotyczącą aktualizacji do nowej wersji Zigbee2MQTT 2.0.0
Po co jest więc powyższa informacja dotycząca zmian w configuration.yaml przed aktualizacją?
Zresztą nie ważne - ważne, że działa nawet po usunięciu dopisanych sekcji.
Ale miało być tam false, a nie true.
No chyba, że się dowinąłem do jakiegoś innego posta omyłkowo, edit - tak sorry to nie był twój post ;D
edit2
A nie, to w ogóle inna historia - nie usunąłeś zbędnych linijek (powinien się ich pozbyć któryś z etapów migracji, no ale każdej sytuacji nikt nie przewidzi), no ale to jest przecież w dokumentacji…
Jakkolwiek nie czuj się urażony - nie było to nic personalnego.
W nawale kłód rzucanych pod nogi w styczniowych aktualizacjach chyba nikt nie ma dość czasu na głęboką analizę każdego przypadku.
Sam robię już 3 dzień porządki w komponentach niestandardowych (tak, sam sobie “zapuściłem” tą instalację, że nadal końca nie widać, szkoda że takie okoliczności, bo normalnie był materiał na parę wątków popularyzujących jakieś gotowe rozwiązania, ale ważność tego jest teraz zerowa…)
Znalazłem chyba to o czym pisałeś - odnośnie wygenerowania PAN ID:
W skrócie - może się komuś przyda:
Set
network_key: GENERATEto let Zigbee2MQTT generate a new random key on the first start. Theconfiguration.ymlgets updated with the new key. Changing the network_key requires repairing of all devices.
Zostawię to jednak na nieokreśloną przyszłość ze względu na konieczność ponownego parowania wszystkich urządzeń …