Nowa funkcjonalność - lokalne akcje i warunkowanie [bramka ZigBee]

[vajera]

Wiesz... to Ty jesteś czarodziej Zigbee
Najpierw myślałem o tym, aby wykorzystać skanowanie sieci. Jeśli mamy PAN ID, to też mamy Extended PAN ID, które jednoznacznie identyfikują bramkę.
I teraz Extended PAN ID (64-bitowy) koordynatora często pokrywa się lub jest podobny do MAC Ethernet/Wi-Fi.
Pierwsze bajty zwykle są te same, bo to OUI (Organizationally Unique Identifier) producenta.

Na przykład u mnie:
Extended PAN ID = 40:4C:CA:5E:29:30:A6:A8
MAC bramki w routerze: 40:4C:CA:5E:29:30

No i na koniec odczytać/przypisać (przez ARP) adres IP na podstawie MAC.

Ale później odkryłem że w Arduino nie ma wbudowanego ARP skanera i trzeba by go było napisać
Nie jest to jakaś specjalna filozofia (nawet na szybko zrobiłem szkic), ale to dodatkowa robota i po przemyśleniu nie wiem, czy ma sens...

Ambitnie podszedłeś do tematu

Wypróbowałem mDNS - wydaje się działać - w każdym razie GUI bramki otworzyło się po wpisaniu adresu w przeglądarkę.

I teraz tak:

W teorii każdy przekaźnik może być połączony z inną bramką - w tej chwili adres IP jest przechowywany w strukturze kanału, więc jest to możliwe.
W przypadku mDNS musimy przechować nazwę bramki, więc potrzebne jest na to miejsce w powyższej strukturze a dodatkowo każdy przekaźnik musi mieć swoją kopię, chociaż tutaj mogę dać wskaźnik do tej nazwy w strukturze kanału. Powiedzmy, że dam 11 znaków na unikalną nazwę bramki - to chyba wystarczy każdemu?

[Zibi_007]

[...]
Czekam na opinie i uwagi - również te krytyczne

Teraz jako Advocatus diaboli: w Supli mamy możliwość ustawienia reakcji, w wyniku której możemy włączyć, wyłączyć, przełączyć, użyć a nawet skopiować stan z innego kanału. Czy nie powielasz tutaj dostępnej już funkcjonalności.
To nie tyle krytyka, ile głos Promotor fidei, aby wyjaśnić wątpliwości i uświadomić, że to być może taki dodatek i uzupełnienie tych funkcji.

@klew - skoro już jest w cloud opcja "Skopiuj stan z innego kanału" to może warto by było dodać "Skopiuj stan na inny kanał"?

[vajera]

[...]
Czekam na opinie i uwagi - również te krytyczne

Teraz jako Advocatus diaboli: w Supli mamy możliwość ustawienia reakcji, w wyniku której możemy włączyć, wyłączyć, przełączyć, użyć a nawet skopiować stan z innego kanału. Czy nie powielasz tutaj dostępnej już funkcjonalności.
To nie tyle krytyka, ile głos Promotor fidei, aby wyjaśnić wątpliwości i uświadomić, że to być może taki dodatek i uzupełnienie tych funkcji.

@klew - skoro już jest w cloud opcja "Skopiuj stan z innego kanału" to może warto by było dodać "Skopiuj stan na inny kanał"?

Oczywiście, że powielam - podobnie, jak w przypadku lokalnych reakcji Idea od początku jest taka sama - zbudować logikę na poziomie lokalnym bez pośrednictwa chmury, która faktycznie w ostatnim czasie jest praktycznie niezawodna. Niemniej z internetem bywa już różnie, chociaż tutaj również jest znacznie lepiej niż kilka lat temu.

Pytanie - czy ta opcja kopiowania stanu dotyczy również np. termometru - bo nie pamiętam?

[Mario78]

[]]

Oczywiście, że powielam - podobnie, jak w przypadku lokalnych reakcji Idea od początku jest taka sama - zbudować logikę na poziomie lokalnym bez pośrednictwa chmury, która faktycznie w ostatnim czasie jest praktycznie niezawodna. Niemniej z internetem bywa już różnie, chociaż tutaj również jest znacznie lepiej niż kilka lat temu.

Idea jest super. Juz widze potencjał takiego zastosowania. Chmura faktycznie jest niezawodna ale np dostęp do internetu juz roznie

[Zibi_007]

Pytanie - czy ta opcja kopiowania stanu dotyczy również np. termometru - bo nie pamiętam?

Generalnie przełączników, przy termostatach można ustawić temperaturę. Jak to było wprowadzane @klew chyba wyjaśniał (opisywał możliwości). Telefon się na mnie obraził i nie chce wyszukać na Forum

[klew]

Nie wiem czy to dobry pomysł aby teraz dodawać komunikację lokalną do bramek.
Wiem, że to fajna zabawa, ale nie ma na obecnym etapie żadnych zabezpieczeń. Pewnie każdy może po prostu połączyć się z odpowiednim portem i zrobić z tym "przekaźnikiem" co chce.

Taka funkcja będzie dodana do Supli. Wiem, że to wszystko wolno idzie i że temat lokalnej komunikacji pewnie niedługo będzie miał kolejne urodziny.

mDNS też będzie dodany do SD, bo będzie to używane w lokalnej komunikacji

[vajera]

Nie wiem czy to dobry pomysł aby teraz dodawać komunikację lokalną do bramek.
Wiem, że to fajna zabawa, ale nie ma na obecnym etapie żadnych zabezpieczeń. Pewnie każdy może po prostu połączyć się z odpowiednim portem i zrobić z tym "przekaźnikiem" co chce.

Każdy, kto przeanalizuje kod bramki oraz będzie znał adresy bramek i numery kanałów. W związku z tym proponuję nie podłączać takiego przekaźnika pod żadne krytyczne elementy infrastruktury, jak na przykład chłodzenie domowego reaktora

Natomiast mówiąc poważnie, masz oczywiście rację - należało by wprowadzić przynajmniej jakiś klucz szyfrujący albo puścić to przez SSL, ale temat jest bardzo świeży i może się okazać wart jedynie zaparkowania.

Taka funkcja będzie dodana do Supli. Wiem, że to wszystko wolno idzie i że temat lokalnej komunikacji pewnie niedługo będzie miał kolejne urodziny.

mDNS też będzie dodany do SD, bo będzie to używane w lokalnej komunikacji

W międzyczasie wrzucam wersję 0.9.100-18/10/2025 - dodałem w niej obsługę mDNS - każdej bramce można teraz nadać unikalną nazwę (do 11 znaków - bez spacji!) i posługiwać się nią np. otwierając GUI w przeglądarce (do nazwy bramki dodajemy wtedy .local, np bramka_36.local), więc ta funkcjonalność przyda się każdemu.

W konfiguracji zdalnych przekaźników są teraz dwie możliwości - albo wpisujemy IP połączonej bramki albo jej nazwę mDNS - wtedy należy ją poprzedzić przedrostkiem mdns://, np. mdns://bramka_36.

Rodzaj adresu można zmieniać wielokrotnie, zmiany realizowane są w czasie rzeczywistym, bez konieczności restartu bramki.

Ciekawostka - używając mDNS wyraźnie widać niewielkie opóźnienie w synchronizacji przekaźników, którego brak przy stosowaniu adresów IP.

Rozważam jeszcze taką opcję, że przekaźnik za pierwszym razem skorzysta z mDNS, później będzie korzystał z zapisanego IP a dopiero przy nieudanym połączeniu z tym IP ponowi kwerendę mDNS. W teorii wiąże się to z pewnym ryzykiem - jeżeli bramka B wypadnie z sieci lub zmieni IP a jej IP dostanie inna bramka, to przekaźnik będzie wysyłał dane do nieprawidłowej bramki. W praktyce taka sytuacja raczej nie powinna mieć miejsca, aczkolwiek więcej jest rzeczy na niebie i ziemi...

[PijanySmerf]

Im więcej czytam tym mniej wiem.... Nie można prościej ??

[Zibi_007]

W międzyczasie wrzucam wersję 0.9.100-18/10/2025 - dodałem w niej obsługę mDNS - każdej bramce można teraz nadać unikalną nazwę (do 11 znaków - bez spacji!) i posługiwać się nią np. otwierając GUI w przeglądarce (do nazwy bramki dodajemy wtedy .local, np bramka_36.local), więc ta funkcjonalność przyda się każdemu.

Pięknie działa. Fajna sprawa

Zrzut ekranu 2025-10-19 021626.png

Rozważam jeszcze taką opcję, że przekaźnik za pierwszym razem skorzysta z mDNS, później będzie korzystał z zapisanego IP a dopiero przy nieudanym połączeniu z tym IP ponowi kwerendę mDNS. W teorii wiąże się to z pewnym ryzykiem - jeżeli bramka B wypadnie z sieci lub zmieni IP a jej IP dostanie inna bramka, to przekaźnik będzie wysyłał dane do nieprawidłowej bramki. W praktyce taka sytuacja raczej nie powinna mieć miejsca, aczkolwiek więcej jest rzeczy na niebie i ziemi...

W praktyce, to tu można wykorzystać teraz to PAN ID. Jeśli za pierwszym razem skorzysta z mDNS, to oprócz zapisania IP, niech zapisze PAN ID. I teraz przed wysłaniem przez przekaźnik danych do bramki docelowej (po IP) niech sprawdza jej PAN ID. No chyba, że to w praktyce jest trudniejsze do zrobienia, niż tutaj napisałem.

[Zibi_007]

Im więcej czytam tym mniej wiem.... Nie można prościej ??

@vajera pisze już tak prosto, że chyba bardziej nie można. Podziwiam go za to, bo sam tak nie potrafię.

Zerknij może tutaj https://www.ionos.com/digitalguide/serv ... icast-dns/ - to takie podstawy podstaw, może będzie później łatwiej zrozumieć