Po powrocie na miejsce połączenia działają nadal. Czyli magia…
Dzięki. Uratowałeś Conbee przed utylizacją
Dzięki. Uratowałeś Conbee przed utylizacją
@Goral64 Z ciekawości spytam.
Czemu przeszedłeś z cc2531 na conbee2?
Ja zaraz zamontuje rolety na zigbee i mam nadzieję że 17 ruterów i 11 końcowych uciagnie cc2531. 
Bo sporo osób go rekomenduje, a postanowiłem trochę urządzeń zigbee nabyć i chciałem mieć najlepsze rozwiązanie.
Żadna moja zasługa. Niemniej powtórzę jeszcze raz. Aktualizujecie coś czy taż podmieniacie sprzęt to:
Backup, restart (lub zatrzymanie urządzenia), aktualizacja i cierpliwość, oszczędzi wam sporo czasu i nerwów.
Ja wiem @macek że w teorii to wystarczy zatrzymanie/restart usługi (sam utrzymuję hypervisora, maszyny na nim stacje robocze i kilka innych rzeczy) ale w praktyce higiena to podstawa. A bramka to nie serwer na którym pracuje dziesiąt użytkowników i nic się nie stanie jak przez kilka minut nie bedzie pracowała.
Ja tylko przypomnę że po zmianie z CC2531 na Conbee2 należy ponownie sparować wszystkie urządzenia - zmiana koordynatora z 1.2 na 3.0.
U mnie nie było takiej potrzeby…
U mnie tez nie. Czy to znaczy że wszystkie urządzenia pracują teraz w 1.2? Jak to sprawdzić?
Jaki urządzenie Zigbee masz do rolet?
Poki co pracuje tylko jeden na testy ale reszta czeka już w szafie na wymiane.
W tej chwili rolety na Supla są
Jeszcze taka ciekawostka, może ktoś zna odpowiedź…
Sparowałem wszystkie docelowe urządzenia ZB i zrobiłem mapkę. Część urządzeń podłączona do Conbee a część do gniazdka Lidla. Nic sienie połączyło z pozostałymi routerami.
Odłączyłem więc perfidnie gniazdko Lidla z sieci i zeskanowałem mapę. Skan trwał 264 sekundy… i wyszedł sobie taki…
Nie wiadomo do czego są podłączone urządzenia końcowe, które były podpięte pod gniazdko Lidla… Co ciekawe niby jakieś połączenie z gniazdkiem Lidla jest, w jedną stronę…
No nic, widać jeszcze trochę spędzę czasu na rozgryzanie tej krainy czarów…
Zastanówmy sie trochę i przeanalizujmy sytuację:
Część urządzeń podłączona do Conbee a część do gniazdka Lidla.
czyli wszystkie urzadzenia sie podłaczyły i co najmniej raz skomunikowaly sie z koordynatorem
Odłączyłem więc perfidnie gniazdko Lidla z sieci i zeskanowałem mapę.
czyli mapa powstała na podstawie komunikacji z routerami Zigbee ale UWAGA jeżeli w tym czasie nie nastąpila zmiana stanu na czujniku Zigbee na baterii to niby skąd koordynator ma wiedziec z czym ten czujnik jest polaczony skoro gniazdko Lidla zniknelo z sieci Zigbee, pamiętaj, ze nie mozna wymusić z koordynatora odczytu czujnika Zigbee zasilanego z baterii, możesz to zrobic z przycisku (jezeli jest) na czujniku. Po nacisnieciu takiego przycisku, czujnik polaczy sie z koordynatorem, wtedy zeskanuj mape i bedziesz widzial ten czujnik podłączony na mapie.
widać jeszcze trochę spędzę czasu na rozgryzanie tej krainy czarów…
Żadne czary tylko podstawowe zasady działania sieci Zigbee.
Mam nadzieję, ze jestes swiadomy takiej sytuacji:
- działa sobie siec Zigbee a w niej czujnik zalania Zigbee na baterie
- robisz restart usługi Zigbee/bramki itp czyli w pewnym okresie czasu, załóżmy przez 1 sekundę nie działa całe Zigbee
- dokładnie w tym czasie (w tej 1s przerwie) następuje zalanie, czujnik to wykrywa i wysyła sygnał, który oczywiście nigdzie nie dotrze.
- usługa Zigbee/bramka wstaje i nie masz żadnej informacji, że czujnik wykrył zalanie - woda caly czas leci i zalewa Ci mieszkanie.
1 polubienie
W tzw. międzyczasie też do tego doszedłem
Później jeszcze sobie to porozkminiam, bo w tej chwili to znaczną większość urządzeń mam w jednym pokoju, więc poczekam, aż je wszystkie umieszczę w miejscach docelowych.
Rozumiem, że urządzenie bateryjne komunikuje się z adapterem tylko kiedy zmienia stan, co określony czas raportując stan baterii i po krótkim naciśnięciu przycisku parowania?
Tak.
co określony czas raportując stan baterii
Nie, nie ma żadnego określonego czasu, tylko w przypadku zmiany stanu, jak zmienia sie np. bateria to w transmisji wysyłane sa wszystkie wartości jakie obsługuje czujnik (battery, water_leak, battery_low, tamper, voltage, linkquality)
po krótkim naciśnięciu przycisku parowania
Tak.
Na stronie projektu Zigbee2MQTT, przy danym wspieranym urządzeniu możesz sprawdzić co można odczytać , np. To read the current state of this switch publish a message to topic zigbee2mqtt/FRIENDLY_NAME/get with payload {"state": ""} . a co jest tylko publikowane np. Value can be found in the published state on the energy property. It’s not possible to read ( /get ) or write ( /set ) this value.
1 polubienie
OK. To jeszcze jedno pytanie. Jeden kontaktron raportuje swoją zmianę stanu, widać to w zigbee2mqtt ale na mapie nie chce się ani razu przyznać, do którego urządzenia jest aktualnie podpięte… O co tutaj może chodzić?
Z tym czasem to nie jest do końca tak - mam automatyzacje pilnujące częstotliwości aktualizacji temperatury i dodałem do tej automatyzacji też sprawdzanie innych urządzeń i z tego co pamiętam najdłuższy czas aktualizacji był na poziomie 1 doby. Co oczywiście jest nadal odległym terminem w przypadku wycieku wody.
Tego niestety nie wiem, nie wiem też jak sprawdzić, nie miałem czasu tego zgłębić.
Zauważyłem jeszcze dziwną rzecz. Rozumiem, że urządzenie bateryjne samo inicjuje wysłanie informacji do koordynatora i dopóki tego nie zrobi, to koordynator nie wie jakie jest status urządzenia, poziom baterii, etc.
Jednak podczas restartu zigbee2mqtt na brokerze pokazują się pozycje typu:
ZBK02_0x00124b0023423cf1 = {"battery":100,"battery_low":false,"contact":false,"linkquality":null,"tamper":false,"voltage":3200}
U mnie dla wszystkich 25 czujników otwarcia/zamknięcia i w każdym wpisie jest aktualny status (ostatni jaki przesłał czujnik). Niestety, w encjach HA jest porażka 
HA zdążył tylko ustawić jeden stan czujnika i jeden stan baterii
Czyżby nie zdążył przetworzyć komunikatów z MQTT?
Na Pulpicie serwisu Zigbee2Mqtt widzę aktualne statusy i poziomy baterii dla wszystkich czujników.
Dlaczego HA się nie zaktualizowało?
EDIT
pm2 restart ais
pomogło…
W nocy wszystkie 25 czujników otwarcia zameldowało się do kontrolera pomimo braku zmiany stanu czujnika. Pomimo braku jakiejkolwiek zmiany w parametrach przesyłanych przez czujnik.
A sprawdź dokladnie czy zmienił się poziom sygnału linkquality czujników? Czy wszystkie czujniki zameldowały się w tym samym czasie? Pytam bo nigdzie nie ma informacji, że urządzenia Zigbee End Device same wysyłają swój stan, może to zależy od producenta sprzętu.
Dziś od 11:37 do 13:34 zgłosiło się 24 czujników. Niestety, jeszcze nie mam historii obejmującej poprzednie połączenie, więc nie wiem czy zmienił się LQI i dlatego pojawił się payload czy to coś innego.
Zastanawia mnie natomiast coś, co jest na zakładce w zigbee2mqtt dla danego urządzenia Raportowanie, w sumie nie wiem do czego służy…
Właśnie sprawdziłem w MQTT Explorer. Czujnik, który wysłał swój payload o 11:37
{
"battery": 100,
"battery_low": false,
"contact": false,
"linkquality": 255,
"tamper": false,
"voltage": 3200
}
o godzinie 17:22 wysłał identyczny
{
"battery": 100,
"battery_low": false,
"contact": false,
"linkquality": 255,
"tamper": false,
"voltage": 3200
}
Tylko teraz pytanie, czy to fizycznie wysłał czujnik do kontrolera a zigbee2mqtt do brokera czy zigbee2mqtt wysłało do brokera to co ma w jakiejś pamięci podręcznej co kiedyś dostało od kontrolera?