Gateway do kilku systemów/producentów technologii ZigBee

nic nie przeszkadza by korzystać z wielu protokołów. Ja używam trzech - wi-fi, zigbee i z-wave. Wygodniej używać jednego, ale nie zawsze tak wychodzi. Wi-fi jest najprostsze i najłatwiej tym zarządzać, zigbee - b. mały pobór prądu, zatem urządzenia, czujniki żyją na baterii długi czas.

U mnie zigbee działa niezadowalająco, ale to wina sprzętu. Muszę wygospodarować trochę czasu i przebuduję to. Mam mały zasięg i opóźnienia.

Zastanawiam się nad zakupem bramki i głowicy termo na testy (zigbee).

OpenHab / Home Assistant lub Domoticz na rpi + CC2531 

Taki zestaw wystarczy do połączenia wszystkiego w domu co korzysta z wifi lub zigbee

@pawell32 

Świetnie! Dziękuję za odpowiedzi i promyk nadziei. 

Jeśli chodzi o WiFi chętnie wykorzystałbym kontakty (switch) do sterowania oświetleniem z tego powodu, że są dużo tańsze od kontaktów z ZigBee. 

Urządzenia, które miałyby pracować na zasilaniu bateryjnym - wybór na pewno padnie na ZigBee ze względu na pobór energii. Jeśli rzeczywiście jest to ~2 lata to jest to wyśmienity czas pracy. 

Poczytałem, popatrzyłem. 

Z tego co udało mi się ustalić to są dwa opensource ciekawe systemy (oprócz Domoticza):

- OpenHab

- Zigbee2Mqtt

Zigbee2Mqtt imponuje listą wspieranych urządzeń.

Jak to jest ze wspieraniem tych urządzeń. Do Zigbee2Mqtt wystarczy dokupić do PC/RPI ZigBee Dongle - jak jest w przypadku obsługi smart urządzeń WiFi? Na pewno potrzebny jest moduł WiFi - ale w którym miejscu to spiąć? Co pozwoli mi na ustawianie scen/akcji korzystając jednocześnie z urządzeń ZigBee i WiFi. 

Dajmy na to mam przełącznik WiFi i na akcji ON chcę wyzwolić akcję w urządzeniu ZigBee - czego muszę użyć do zestawienia takiej akcji? Które z oprogramowań zgrupuje mi te dwa urządzenia?

Pawell32 z czego korzystasz jeśli mogę wiedzieć?  

@jakubmalinowski

systemy masz co najmniej 3 - OpenHab, Domoticz, HomeAssistant.

Zigbee2Mqtt to wtyczka, potrzebujesz np. sniffera https://allegro.pl/oferta/usb-zigbee-cc2531-zigbee2mqtt-homeassistant-9845355198. To on wraz w wtyczką realizuje połączenia po Zigbee.

W systemie widzisz urządzenia tak samo, nie ma znaczenia czy włączasz lampę (przekaźnik wi-fi) za pomocą włącznika zigbee czy odwrotnie. Ja na ten przykład załączam żarówki Zigbee pilotem 433MHz. 

@pawell32 Bombowo! Tego mi było trzeba. 

Zigbee2MQtt to nie system - wtyczka. 

Paweł, bardzo mi pomogłeś. Teraz tylko trzeba się wybrać na zakupy 😉 

@jakubmalinowski zacznij od warzywniaka 🙂

Ja ze swojej rzucę garścią detali. W przypadku openhaba zigbee jest wspierane "natywnie" tj. obsługa całego protokołu jest zaimplementowana w Javie i openhab "gada" bezpośrednio z modułem radiowym. Ma to swoje blaski i cienie.

Przede wszystkim poprawiona integracja do openHABa będzie kiedyś certyfikowana pod kątem "zigbee application controller". Znam autora tego dodatku (Chris Jackson) i wiem że do tego się przymierzał w minionym roku. Niestety przez COVID wszystko się odsunęło w czasie. Pracowałem z nim nad poprawieniem pewnych aspektów w OH, które są potrzebne aby integracja była jeszcze "gładsza".

Z wad tego podejścia należy zaznaczyć czasami czas, który jest konieczny do tego aby coś weszło do integracji. Wynika to stąd, że niektóre wymagania wychodzące ze strony dodatku wymagają zmian w OH, które nie są mile widziane. Jednym z nich jest np. obsługa priorytetów poleceń czy też złożonych struktur danych typu lista/grafik.

Na czym polega podstawowa różnica między podejściem OH a zigbee2mqtt? Generalnie całość sprowadza się do tego gdzie jest dostępny moduł radiowy. W przypadku zigbee2mqtt system obsługujący asortymenty może być zlokalizowany w sieci lokalnej tam gdzie normalnie sygnał zigbee jest zbyt słaby. W OH od wersji 3.0 problem ten jest rozwiązany przez tzw. "remote binding" - dwa openhaby mogą wymieniać informacje między sobą bez konieczności walki z portem szeregowym po ip. 😉

@ldywicki pytanie - Czy w przypadku remote binding tworzona jest jedna sieć zigbee ? Jeżeli nie to jaka to różnica czy wepnę dwa sniffery do różnych sprzętów i zepnę je zdalnie ?

@isom Adapter zigbee pracuje tylko w jednym miejscu. Połączenie pomiędzy openhabami odbywa się w oparciu o HTTP. Drugi openhab (ten bez adaptera zigbee) tworzy wirtualne urządzenia, które są repliką urządzeń zigbee z pierwszego. Dzięki temu jedyne czego potrzebujesz to openhab tam gdzie zigbee i openhab tam gdzie masz interfejs użytkownika.

@ldywicki ok czyli chodzi tylko o to, że jest slave z adapterem  i master który widzi urządzenia slave , ja myślałem ze przy bardziej rozległych sieciach oba OH mogą mieć adapter i tworzy się wspólna sieć co by naprawdę było innowacją , w takim przypadku jak teraz nie widzę praktycznego pożytku z takiej funkcjonalności , podasz przykład zastosowania ?

Interfejs użytkownika zakładam , że jest dostępny z  dowolnego miejsca , pomóż mi zrozumieć sens takiego połączenia 

Może jeszcze inaczej , ja mogę połączyć dwa niezależnie pracujące serwery na których będą dwa adaptery czyli są dwie sieci zigbee , serwer master będzie widział swoją sięć i urządzenia serwera slave z poziomu master mogę zarządzać i urządzeniami master i slave , z poziomu slave tylko slave . 

Czy ta współpraca dwóch OH ma podobnie działać wykluczając drugi adapter ?

@isom Celem samego rozwiązania (tzw. remotebinding) jest uproszczenie instalacji i konfiguracji. W wielu przypadkach ludzie mają problem z tym gdzie jest sygnał zigbee a gdzie jest sam openhab. Były różne próby obejścia tego - np. przez ser2net + socat lub np. zigbee2MQTT i później zarządzanie konfiguracją MQTT po stronie OH. W przypadku wykorzystania remotebinding masz A) wykrywanie kolejnych instancji B) wykrywanie podłączonych rzeczy C) synchronizację ich stanu pomiędzy instancjami. Komenda na "masterze" OH jest delegowana do "slave". Zmiana stanu urządzenia lub kanału na "slave" trafia automatycznie do "mastera". Działa to tak samo dla innych bindingów.

U siebie planuję to wykorzystać w następującej sytuacji - OH działa na NAS razem z influxem - w kotłowni mam malinkę z OH i interfejsem ebus/usb. Ze względu na narzuty czasowe socat i opóźnienia IP nie pozwalają na stabilną pracę bindingu. Chcę też wyrzucić adapter zwave poza NAS bo jest pod nim uciążliwe zarządzanie sterownikami.. no i kiepski zasięg. Dzięki temu mam jeden interfejs użytkownika (na NAS) i do chmury (nieszczęsny myopenhab), jedną bazę danych i podzielone odpowiedzialności/konfiguracje.

W powyższym przykładzie który podałem obie instalacje są aktywne. "slave" jest slave tylko z nazwy (tzn. OH z interfejsem zigbee), działa niezależnie od mastera.
Jeżeli ktoś potrzebuje przedłużyć zasięg sieci to właściwym rozwiązaniem jest wykorzystanie stosownych repeaterów sprzętowych działających w określonym standardzie. OH to tylko kontroler i charakterystyka jego pracy jest nieco inna.
Zrobienie scenariusza że obydwa OH mają adaptery zigbee jest wykonalne tyle że wymaga już ręcznego pisania reguł do przerzucania komend/stanów pomiędzy asortymentem zigbee.

Panowie a nie komplikujecie tego niepotrzebnie?

Zigbee działa w topologii mesh, część urządzeń (co do zasady zasilane sieciowo, z paroma wyjątkami) pracuje jako routery zwiększając zasięg sieci. Najprostszy przykład to urządzenie od IKEA które przy okazji jest ładowarką USB. Ale w ten sposób pracuje większość modułów do sterowania zasilaniem, zarządzalnych gniazd sieciowych i żarówek.

To będzie lżejsze podejście niż stawianie drugiego serwera OH którym się trzeba zajmować i jeszcze pilnować połączenia.

Sam binding w OH: ja osobiście poszedłem jednak w Zigbee2MQTT - cykl developmentu jest jednak szybszy, a stabilne wystarczająco.

Z innej beczki samo CC2531 ma spore ograniczenie (ja się jeszcze nie nadziałem, ale mam małą sieć) - ma mało zasobów i przy sieciach ponad 20 urządzeń może być problemowy, obecnie zaleca się inne układy.