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

[Zibi_007]

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 ?

Patrz punk 1. odpowiedzi od @vajera (nawet zacytowałeś).

[akr]

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

Dzięki za odpowiedź , wydaje się że pomysł ze schematem nr1 byłby pomocny.

[trozwadowski89]

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

ZBEK-26 - działa idealnie - dzięki vajera

ZBEK-1 oraz ZBEK-12 nie mogę dodać do bramki

[vajera]

ZBEK-26 - działa idealnie - dzięki vajera

Git! Fajny ten przycisk - rozgryzłeś wszystkie AT, czy dodałeś go klasycznie?

ZBEK-1 oraz ZBEK-12 nie mogę dodać do bramki

W bazie są obie żarówki - może daj jakieś logi?

[trozwadowski89]

Logi ze skanera ? Czy postawić bramkę z log i pobrać log?

[vajera]

Logi ze skanera ? Czy postawić bramkę z log i pobrać log?

Nie ma takiej potrzeby - wszystko już jest jasne - napisałeś "ADEO" a tam jest "Adeo". W logach ze skanera jest "Adeo", ale ja sugerowałem się Twoim wpisem

[vajera]

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

BWNU: 1.1.45-15/01/26

[vajera]

Logi ze skanera ? Czy postawić bramkę z log i pobrać log?

Poprawiłem ADEO na Adeo

BWNU: 1.1.45-15/01/26

[klajonek007]

Witam
Zwracam się z dużą prośbą o dodanie water leak sensor, jest pokazany jako: Nieznany model Zbeacon::SNZB-05P, nie ma możliwości wiązania

Zrzut ekranu 2026-01-15 170500.png

[Zibi_007]

Witam
Zwracam się z dużą prośbą o dodanie water leak sensor, jest pokazany jako: Nieznany model Zbeacon::SNZB-05P, nie ma możliwości wiązania
Zrzut ekranu 2026-01-15 170500.png

Wyłącz sobie automatyczne tłumaczenia (chyba, że jest Ci bardzo potrzebne), bo dziwnie to wygląda. Nie wiem jak w Z2S, ale niekiedy przez to nie działają niektóre funkcje w interfejsach webowych (ale nie ma to nic wspólnego z brakiem możliwości sparowania Twojego czujnika zalania).