Zgłoszenia nowych urządzeń [bramka Zigbee]

[vajera]

Witam, poproszę o dodanie:

https://www.leroymerlin.pl/produkty/pil ... 5wQAvD_BwE

Peer Model is "ZBEK-26"
Peer Manufacturer is "ADEO"

Ciekawy przycisk - kupiłem go sobie dzisiaj w LM i przy okazji dodałem do bramki.

BWNU: 1.1.44-14/01/26

[vajera]

Witam, poproszę o dodanie:

https://www.leroymerlin.pl/produkty/zar ... 72286.html
Peer Model is "ZBEK-1"
Peer Manufacturer is "ADEO"



https://www.leroymerlin.pl/produkty/zar ... 72283.html
Peer Model is "ZBEK-12"
Peer Manufacturer is "ADEO"

BWNU: 1.1.44-14/01/26

[vajera]

Witam, poproszę o dodanie:

https://www.leroymerlin.pl/produkty/pil ... 5wQAvD_BwE

Peer Model is "ZBEK-26"
Peer Manufacturer is "ADEO"

Przetestowałem go zarówno w wersji legacy (VR), jak i modern (AT) - wszystkie przyciski działają.

[akr]

Dzień dobry , czy będzie kiedyś możliwość dodawania własnych urządzeń do bramki , podobnie jak to jest w GUI - Generic Builder ?

[Robert Błaszczak]

Dzień dobry , czy będzie kiedyś możliwość dodawania własnych urządzeń do bramki , podobnie jak to jest w GUI - Generic Builder ?

Możesz rozwinąć temat? Zrobiłeś własne urządzenie Zigbee?

[akr]

Chodzi o urządzenie działające w Zigbee w oparciu o wsad wygenerowany podobnie jak to jest GUI-Generic .

[vajera]

Chodzi o urządzenie działające w Zigbee w oparciu o wsad wygenerowany podobnie jak to jest GUI-Generic .

Dodanie nowego urządzenia Zigbee do bramki zasadniczo może przebiegać według trzech schematów;

1. Obsługa danego urządzenia jest już w bramce, użytkownik zgłasza nowe id - wtedy dodanie nowego urządzenia do bazy to właściwie operacja kopiuj/wklej - czas wykonania poniżej 1 minuty

2. Obsługa danego urządzenia jest już w bramce, ale zgłaszane urządzenie ma nieco inny zakres parametrów/datapoints i wymaga dostosowania kodu, np. dodajemy nowy przycisk wirtualny - większość kodu jest taka sama, ale trzeba ogarnąć nazwy i funkcje przycisków - to jest kilka/kilkanaście/kilkadziesiąt linii kodu - czas pracy zwykle poniżej godziny, ale może przedłużyć się do kilku (zwłaszcza, gdy konieczne są zdalne testy).

3. Użytkowni zgłasza urządzenie, którego nie ma w bazie i którego mechanizm działania nie został do tej pory zaimplementowany w kodzie bramki. Tutaj trzeba zacząć od poszukiwań informacji, później budowanie algorytmów, testy, szukanie błędów - czas liczony w dniach a czasami w tygodniach

Oczywiście kod jest otwarty i każdy może dodać sobie dowolne urządzenie, natomiast takiej opcji jak w GG nie ma i nie będzie, bo to inna filozofia.
Można ewentualnie rozważyć mechanizm umożliwiający użytkownikowi samodzielną realizację schematu nr 1 - tutaj mam kilka pomysłów.

[lukasz06]

Cześć, proszę o dodanie przełącznika dwukanałowego Sonoff
Unknown model SONOFF::MINI-ZB2GS, no binding is possible

[akr]

Chodzi o urządzenie działające w Zigbee w oparciu o wsad wygenerowany podobnie jak to jest GUI-Generic .

Dodanie nowego urządzenia Zigbee do bramki zasadniczo może przebiegać według trzech schematów;

1. Obsługa danego urządzenia jest już w bramce, użytkownik zgłasza nowe id - wtedy dodanie nowego urządzenia do bazy to właściwie operacja kopiuj/wklej - czas wykonania poniżej 1 minuty

2. Obsługa danego urządzenia jest już w bramce, ale zgłaszane urządzenie ma nieco inny zakres parametrów/datapoints i wymaga dostosowania kodu, np. dodajemy nowy przycisk wirtualny - większość kodu jest taka sama, ale trzeba ogarnąć nazwy i funkcje przycisków - to jest kilka/kilkanaście/kilkadziesiąt linii kodu - czas pracy zwykle poniżej godziny, ale może przedłużyć się do kilku (zwłaszcza, gdy konieczne są zdalne testy).

3. Użytkowni zgłasza urządzenie, którego nie ma w bazie i którego mechanizm działania nie został do tej pory zaimplementowany w kodzie bramki. Tutaj trzeba zacząć od poszukiwań informacji, później budowanie algorytmów, testy, szukanie błędów - czas liczony w dniach a czasami w tygodniach

Oczywiście kod jest otwarty i każdy może dodać sobie dowolne urządzenie, natomiast takiej opcji jak w GG nie ma i nie będzie, bo to inna filozofia.
Można ewentualnie rozważyć mechanizm umożliwiający użytkownikowi samodzielną realizację schematu nr 1 - tutaj mam kilka pomysłów.

Dzięki za odpowiedź , jeśli gniazdko lub czujnik, przycisk był już raz dodany , to każde kolejne nowe urządzenie tego typu będzie dodane do bramki , czy każde musi być dodane osobno ?

[vajera]

Chodzi o urządzenie działające w Zigbee w oparciu o wsad wygenerowany podobnie jak to jest GUI-Generic .

Dodanie nowego urządzenia Zigbee do bramki zasadniczo może przebiegać według trzech schematów;

1. Obsługa danego urządzenia jest już w bramce, użytkownik zgłasza nowe id - wtedy dodanie nowego urządzenia do bazy to właściwie operacja kopiuj/wklej - czas wykonania poniżej 1 minuty

2. Obsługa danego urządzenia jest już w bramce, ale zgłaszane urządzenie ma nieco inny zakres parametrów/datapoints i wymaga dostosowania kodu, np. dodajemy nowy przycisk wirtualny - większość kodu jest taka sama, ale trzeba ogarnąć nazwy i funkcje przycisków - to jest kilka/kilkanaście/kilkadziesiąt linii kodu - czas pracy zwykle poniżej godziny, ale może przedłużyć się do kilku (zwłaszcza, gdy konieczne są zdalne testy).

3. Użytkowni zgłasza urządzenie, którego nie ma w bazie i którego mechanizm działania nie został do tej pory zaimplementowany w kodzie bramki. Tutaj trzeba zacząć od poszukiwań informacji, później budowanie algorytmów, testy, szukanie błędów - czas liczony w dniach a czasami w tygodniach

Oczywiście kod jest otwarty i każdy może dodać sobie dowolne urządzenie, natomiast takiej opcji jak w GG nie ma i nie będzie, bo to inna filozofia.
Można ewentualnie rozważyć mechanizm umożliwiający użytkownikowi samodzielną realizację schematu nr 1 - tutaj mam kilka pomysłów.

Dzięki za odpowiedź , jeśli gniazdko lub czujnik, przycisk był już raz dodany , to każde kolejne nowe urządzenie tego typu będzie dodane do bramki , czy każde musi być dodane osobno ?

Gdyby wszyscy producenci urządzeń Zigbee trzymali się standardu opracowanego przez Zigbee Alliance, to odpowiedź na Twoje pytanie byłaby twierdząca.
W standardzie jest kilkanaście tzw. klastrów (OnOff, Level Control, Color Control, Thermostat) ze ściśle zdefiniowanymi atrybutami i rozkazami i rok temu wydawało mi, że ich implementacja rozwiąże 99% przypadków....Oh, sweet summer child chciałoby się powiedzieć samemu sobie sprzed roku
Okazuje się, że w rzeczywistości ilość wyjątków prawie dorównuje polskiemu prawu podatkowemu

Poniżej masz przykład, jak bardzo może różnić się ilość i stopień złożoności kodu implementującego jedną funkcję w przypadku trzech markowych głowic TRV:

viewtopic.php?p=218006#p218006