Dziwna sprawa z bramką i sparowanymi gniazdkami

[mmiikk]

Dziwna sprawa z bramką i sparowanymi gniazdkami

Zaktualizowałem starą bramkę do najnowszej wersji. Były na niej sparowane duzo wczesniej 3 gniazdka: jedno Sonoff i dwa Tuya. Sparowałem z nią 2 czujniki, a potem zrobiłem pełny backup całych 8 MB i przerzuciłem go na drugie ESP32-C6.

Włączyłem drugą, skopiowaną bramkę i niby wszystko było OK, ale zauważyłem, że wszystkie gniazdka były rozłączone. Jedno gniazdko było fizycznie odłączone od zasilania, więc nie wzbudziło to moich podejrzeń, ale dwa pierwsze były cały czas pod napięciem.

Tymczasem w aplikacji i w chmurze miały status „rozłączone”.

Stwierdziłem, że wymuszę ponowne parowanie, bo może w bramce źródłowej były stare ustawienia (?). Włożyłem więc trzecie gniazdko do zasilania.

W bramce ustawiłem:

Enable/disable pairing mode (180 s)
Force device to bind gateway again

Po jakimś czasie dwa gniazdka się połączyły, trzecie nie chciało. Zrestartowałem bramkę i ponowiłem próbę, ręcznie zmuszając trzecie gniazdko do parowania. Wtedy połączyły się wszystkie gniazdka, a nowe czujniki również były podłączone.

Wyciągnąłem trzecie gniazdko z zasilania.

Ku mojemu zdziwieniu wszystkie trzy gniazdka się rozłączyły.

Włożyłem trzecie gniazdko ponownie i jeszcze raz ustawiłem te dwie opcje w bramce na „on”.

Wszystkie gniazdka się połączyły.

Wyciągnąłem wtyczkę trzeciego gniazdka i znowu wszystkie trzy się rozłączyły.

Miałem też sytuację, że w gniazdku Sonoff odczyty energii („month”, „yesterday”) były widoczne jako połączone, a reszta parametrów oraz samo gniazdko (przekaźnik) już nie.

Natomiast czujniki, które parowałem już po aktualizacji, cały czas pozostają połączone.

Dziwna sprawa — nie potrafię tego rozgryźć, dlaczego wyciągnięcie trzeciego gniazdka powoduje rozłączenie również dwóch pozostałych.
Do głowy przychodzi mi tylko ze to trzecie gniazdko któremu wymusiłem recznie ponowne parowanie fizycznym przuciskiem, jakos zajeło w konfiguracji bramki miejsce takze w 2ch pozostalych gniazdkach (nadpisalo swoj identyfikator w tabeli?) i wyciągniecie wtyczki raportuje ze 3 sa odlączone bo wskazuja na to jedno fizyczne gnaizdko nr 3.

[mmiikk]

tak to wygląda w cloud zwróćcie uwage a sonofa kóry nmby jest rozłaczony ale 3 kanały ma włączone

[vajera]

tak to wygląda w cloud zwróćcie uwage a sonofa kóry nmby jest rozłaczony ale 3 kanały ma włączone

Czy masz dla tych kanałów poustawiane jakieś wartości w Channel timings?

[mmiikk]

O ile pamiętam ustawiałem keepalive = 10
timeout = 15 sek

Po nocy jest to samo.
Sprawa jest jednak bardzo dziwna, bo jak włożyłem teraz z powrotem gniazdko numer 3 do zasilania, to wszystkie 3 gniazdka są online, a najlepsze, że się prawidłowo sterują, czyli włączając w aplikacji gniazdko Sonoff, steruję faktycznie Sonoffem, czyli to nie podmiana adresu w konfiguracji, bo wtedy wszystkie gniazdka sterowałyby gniazdkiem nr 3.

[vajera]

O ile pamiętam ustawiałem keepalive = 10
timeout = 15 sek

Po nocy jest to samo.
Sprawa jest jednak bardzo dziwna, bo jak włożyłem teraz z powrotem gniazdko numer 3 do zasilania, to wszystkie 3 gniazdka są online, a najlepsze, że się prawidłowo sterują, czyli włączając w aplikacji gniazdko Sonoff, steruję faktycznie Sonoffem, czyli to nie podmiana adresu w konfiguracji, bo wtedy wszystkie gniazdka sterowałyby gniazdkiem nr 3.

1. To czy konkretny kanał Supla dla danego urządzenia ZigBee ma w aplikacji/Cloud status online/offline zależy od tego, czy dla tego konkretnego kanału włączony został mechanizm weryfikacji obecności (keepalive/timeout/refresh). W teorii jest więc możliwe, że cześć kanałów jest offline, bo mają włączoną te weryfikację a cześć ma status online.

2. Dla kanałów typu GPM/KPOP nie implementowałem mechanizmu keepalive/timeout z uwagi na to, że bardzo często nie ma możliwości zmuszenia urządzenia żeby wysłało dane (keepalive), ale to było dawno temu. Teraz teoretycznie mógłbym wykorzystać nowe rozwiązania i zrobić tak, że jeżeli jeden kanał urządzenia ZigBee przechodzi w offline, to wszystkie pozostałe również - dopiszę to do listy zadań.

3. To zjawisko, które opisujesz może mieć następujące wyjaśnienie - każde gniazdko pełni też funkcję routera w sieci ZigBee - możliwe, że część gniazdek łączy się z bramką poprzez inne gniazdko. Po wyłączeniu routera one powinny nawiązać połączenie z bramką inną drogą - przez inny router albo bezpośrednio. Ta procedura zajmuje zwykle chwilę czasu, jeżeli ustawiłeś timeout na 15 sekund (tak z ciekawości - skąd taka wartość?), to mogą nie zdążyć nawiązać nowego połączenia.

4. Możliwy jest też taki scenariusz, że te gniazdka są za daleko od bramki i nie mogą połączyć się bezpośrednio, więc łączą się przez router, a gdy go zabraknie tracą połączenie z siecią.

[Robinson74]

jeżeli ustawiłeś timeout na 15 sekund (tak z ciekawości - skąd taka wartość?), to mogą nie zdążyć nawiązać nowego połączenia.

Włączę się w dyskusję z pytaniem.
Rozumiem, że nawet mimo tak "agresywnego" ustawienia timeout, to po jakimś czasie urządzenie powinno ponownie wejść w stan POŁĄCZONY, jeśli będzie w zasięgu innego routera?

[vajera]

jeżeli ustawiłeś timeout na 15 sekund (tak z ciekawości - skąd taka wartość?), to mogą nie zdążyć nawiązać nowego połączenia.

Włączę się w dyskusję z pytaniem.
Rozumiem, że nawet mimo tak "agresywnego" ustawienia timeout, to po jakimś czasie urządzenie powinno ponownie wejść w stan POŁĄCZONY, jeśli będzie w zasięgu innego routera?

Tak, bo jeżeli parametr keepalive > 0, to bramka cały czas odpytuje urządzenie, również w sytuacji, gdy urządzenie samo coś wyśle, kanał powinien przejść w stan online.

[Robinson74]

Teraz teoretycznie mógłbym wykorzystać nowe rozwiązania i zrobić tak, że jeżeli jeden kanał urządzenia ZigBee przechodzi w offline, to wszystkie pozostałe również - dopiszę to do listy zadań.

Super.
Bardzo popieram takie rozwiązanie.

[mmiikk]

jeżeli ustawiłeś timeout na 15 sekund (tak z ciekawości - skąd taka wartość?), to mogą nie zdążyć nawiązać nowego połączenia.

Włączę się w dyskusję z pytaniem.
Rozumiem, że nawet mimo tak "agresywnego" ustawienia timeout, to po jakimś czasie urządzenie powinno ponownie wejść w stan POŁĄCZONY, jeśli będzie w zasięgu innego routera?

Tak, bo jeżeli parametr keepalive > 0, to bramka cały czas odpytuje urządzenie, również w sytuacji, gdy urządzenie samo coś wyśle, kanał powinien przejść w stan online.

Rozumiem ze parametry keep alive są trzymane w urzadzeniu wykonawczym nie bramce? Da sie jakoś pobrać bieżące wartości?

Wiecie co wygląda na to ze problemu już nei ma chociaż jeszcze rano był,
co zrobiłem?
Odpiąłem bramkę od zasilania i podpiąłem ponownie.

Wcześniej robiłem tylko restart gateway z gui.
I teraz wszystko wydaje pokazywać prawidłowo niezależnie czy gn nr 3 jest włożone do zasilania czy nie.

[vajera]

Włączę się w dyskusję z pytaniem.
Rozumiem, że nawet mimo tak "agresywnego" ustawienia timeout, to po jakimś czasie urządzenie powinno ponownie wejść w stan POŁĄCZONY, jeśli będzie w zasięgu innego routera?

Tak, bo jeżeli parametr keepalive > 0, to bramka cały czas odpytuje urządzenie, również w sytuacji, gdy urządzenie samo coś wyśle, kanał powinien przejść w stan online.

Rozumiem ze parametry keep alive są trzymane w urzadzeniu wykonawczym nie bramce? Da sie jakoś pobrać bieżące wartości?

Wiecie co wygląda na to ze problemu już nei ma chociaż jeszcze rano był,
co zrobiłem?
Odpiąłem bramkę od zasilania i podpiąłem ponownie.

Wcześniej robiłem tylko restart gateway z gui.
I teraz wszystko wydaje pokazywać prawidłowo niezależnie czy gn nr 3 jest włożone do zasilania czy nie.

Cały mechanizm keepalive/timeout realizowany jest przez bramkę - urządzenie nic o nim nie wie - dlatego jest uniwersalny.