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

mmiikk · Post Mon Apr 13, 2026 6:32 pm

Powiedz mi jeszce 2 - 3 rzeczy zanim wóce do eksperymentów:
1.JAkoś sie gniazdko uniezalezniło do bramk, tzn nie reagije na stan w cloud, przypuszcam ze sie rozparowalo po prostu, jak je sparowac spowrotem, czy tylko usunac z cloud i dodać na nowe i przepisac z nim wszystkie akcje? (w zasadzie wszystkie jesli kolejnosć akcji ma znaczenie) Czy jest może lepszy sposób na przywrócenei działania rozparowanego gniazdka (urzadzenia)?
Nie usuwaj nic z Cloud, zacznij od SPR (Standardowa Procedura Reanimacji):
- włącz przełącznik Force device to bind gateway again,
- włącz przełącznik parowania w bramce,
- uruchom parowanie w gniazdku.

Dziękuję.
Udało sie, gniazdko znowu jest sterowalne,
bramka jednak stracila wszytkie logiczne bramki jakie dodałem, virtual binary i wszystkie nazwy: channel name (local) jakie nadałem, to tak ma być? Czy ja coś źle zrobiłem?

vajera · Post Mon Apr 13, 2026 6:39 pm

mmiikk wrote: Mon Apr 13, 2026 6:32 pm

Powiedz mi jeszce 2 - 3 rzeczy zanim wóce do eksperymentów:
1.JAkoś sie gniazdko uniezalezniło do bramk, tzn nie reagije na stan w cloud, przypuszcam ze sie rozparowalo po prostu, jak je sparowac spowrotem, czy tylko usunac z cloud i dodać na nowe i przepisac z nim wszystkie akcje? (w zasadzie wszystkie jesli kolejnosć akcji ma znaczenie) Czy jest może lepszy sposób na przywrócenei działania rozparowanego gniazdka (urzadzenia)?
Nie usuwaj nic z Cloud, zacznij od SPR (Standardowa Procedura Reanimacji):
- włącz przełącznik Force device to bind gateway again,
- włącz przełącznik parowania w bramce,
- uruchom parowanie w gniazdku.
Dziękuję.
Udało sie, gniazdko znowu jest sterowalne,
bramka jednak stracila wszytkie logiczne bramki jakie dodałem, virtual binary i wszystkie nazwy: channel name (local) jakie nadałem, to tak ma być? Czy ja coś źle zrobiłem?

Nie powinno tak się zdarzyć - bardzo dziwna sprawa?

mmiikk · Post Mon Apr 13, 2026 7:27 pm

vajera wrote: Mon Apr 13, 2026 6:39 pm
mmiikk wrote: Mon Apr 13, 2026 6:32 pm

Nie usuwaj nic z Cloud, zacznij od SPR (Standardowa Procedura Reanimacji):
- włącz przełącznik Force device to bind gateway again,
- włącz przełącznik parowania w bramce,
- uruchom parowanie w gniazdku.
Dziękuję.
Udało sie, gniazdko znowu jest sterowalne,
bramka jednak stracila wszytkie logiczne bramki jakie dodałem, virtual binary i wszystkie nazwy: channel name (local) jakie nadałem, to tak ma być? Czy ja coś źle zrobiłem?
Nie powinno tak się zdarzyć - bardzo dziwna sprawa?

Zdarzyło mi isę tak dwókrotnie, al enei potrafię stwierdzić ppo jakich czynnosciach, na pewno bramka była restartowana, na pewno byly zmiany w kanałach bramki (nazwy) i w lokalnych akcjach.
AL teraz mam jeszcze inny problem, powtarzalny, w następnym poście opisze.

mmiikk · Post Mon Apr 13, 2026 7:33 pm

post niżej

mmiikk · Post Mon Apr 13, 2026 7:36 pm

2. Jaki stan po starcie bramki ma VIRTUAL BINARY (VB)? OFF czyli 0? Czy mozna to gdzies podglądać bieżący stan?

To mi się zdarzyło juz dwukrotnie i jest zakakżdym razem replikowalne.
Dodanie LOCAL VIRTUAL BINARY i włączenie w cloud rejestracje nowych urzadzeń powoduje ze sie pojawia, tam sensor ktroy ustawiam na binary sensor - pk
Ale teraz dodanie akcji z tym bvirtual binatry , a moze ustawienei autoset, powoduje ze po pierwszym restarcie mamy w cloud konflikt wlasnie na tym dodanym czujnku wirtualnym.
Jesli w cloud nei wlaczymy dodawanai nowych urzadzen wszytko bedzie dizac, ale przy pierwszym nowym urzadzeniu o i po ponownym restarcie bramki zawsze mamy konflikt.
Musze usunac tem binary sensor z cloud zeby bramka zechciala dzialac.

Drugi raz było jednak gorzej, jakby brama straciła wszystkie dodane urzadzenia w channels (w GUI ich nie widać) natomiast w devices wszystkie sa na miejscu.
Bramka nie działa, jest konflikt przy kazdym dodanym fizycznym urzadzeniu do bramiki w cloud. Nie pomogło nawet skasowanie wszystkich akcji lokalnych (myślałem ze one powodują konfliokt) i restart.
W zakładce channels gui bramki jest tylko jedno urzadzenie GATEWAY EVENTS, wszystkie inne zniknęły.

STOP
zrobiłem teraz restart z Rebuild missing Supla channels on next startup
i Wszystkie kanały w gui bramki się pojawiły konflikt zniknął, ale moje nazwy zniknęły, virtual binary zniknął, bramki zniknęły, tak jak wcześniej opisywałem.

vajera · Post Mon Apr 13, 2026 7:44 pm

mmiikk wrote: Mon Apr 13, 2026 7:36 pm To mi się zdarzyło juz dwukrotnie i jest zakakżdym razem replikowalne.
Dodanie LOCAL VIRTUAL BINARY i włączenie w cloud rejestracje nowych urzadzeń powoduje ze sie pojawia, tam sensor ktroy ustawiam na binary sensor - pk
Ale teraz dodanie akcji z tym bvirtual binatry , a moze ustawienei autoset, powoduje ze po pierwszym restarcie mamy w cloud konflikt wlasnie na tym dodanym czujnku wirtualnym.
Jesli w cloud nei wlaczymy dodawanai nowych urzadzen wszytko bedzie dizac, ale przy pierwszym nowym urzadzeniu o i po ponownym restarcie bramki zawsze mamy konflikt.
Musze usunac tem binary sensor z cloud zeby bramka zechciala dzialac.

Ale teraz sie nei udało, bramka nei dział, jest konflikt przy kazdym dodanym fizycznym urzadzeniu do bramiki w cloud.

Coś musiało się wydarzyć, bo to nie jest typowe zachowanie bramki?
Jak dodajesz taki VR/VB, to robisz później restart za pomocą przycisku Restart Gateway?

mmiikk · Post Mon Apr 13, 2026 7:56 pm

vajera wrote: Mon Apr 13, 2026 7:44 pm
mmiikk wrote: Mon Apr 13, 2026 7:36 pm To mi się zdarzyło juz dwukrotnie i jest zakakżdym razem replikowalne.
Dodanie LOCAL VIRTUAL BINARY i włączenie w cloud rejestracje nowych urzadzeń powoduje ze sie pojawia, tam sensor ktroy ustawiam na binary sensor - pk
Ale teraz dodanie akcji z tym bvirtual binatry , a moze ustawienei autoset, powoduje ze po pierwszym restarcie mamy w cloud konflikt wlasnie na tym dodanym czujnku wirtualnym.
Jesli w cloud nei wlaczymy dodawanai nowych urzadzen wszytko bedzie dizac, ale przy pierwszym nowym urzadzeniu o i po ponownym restarcie bramki zawsze mamy konflikt.
Musze usunac tem binary sensor z cloud zeby bramka zechciala dzialac.

Ale teraz sie nei udało, bramka nei dział, jest konflikt przy kazdym dodanym fizycznym urzadzeniu do bramiki w cloud.
Coś musiało się wydarzyć, bo to nie jest typowe zachowanie bramki?
Jak dodajesz taki VR/VB, to robisz później restart za pomocą przycisku Restart Gateway?

Zaktualizowałem post wyżej:

vajera · Post Mon Apr 13, 2026 8:06 pm

mmiikk wrote: Mon Apr 13, 2026 7:36 pm
2. Jaki stan po starcie bramki ma VIRTUAL BINARY (VB)? OFF czyli 0? Czy mozna to gdzies podglądać bieżący stan?
To mi się zdarzyło juz dwukrotnie i jest zakakżdym razem replikowalne.
Dodanie LOCAL VIRTUAL BINARY i włączenie w cloud rejestracje nowych urzadzeń powoduje ze sie pojawia, tam sensor ktroy ustawiam na binary sensor - pk
Ale teraz dodanie akcji z tym bvirtual binatry , a moze ustawienei autoset, powoduje ze po pierwszym restarcie mamy w cloud konflikt wlasnie na tym dodanym czujnku wirtualnym.
Jesli w cloud nei wlaczymy dodawanai nowych urzadzen wszytko bedzie dizac, ale przy pierwszym nowym urzadzeniu o i po ponownym restarcie bramki zawsze mamy konflikt.
Musze usunac tem binary sensor z cloud zeby bramka zechciala dzialac.

Drugi raz było jednak gorzej, jakby brama straciła wszystkie dodane urzadzenia w channels (w GUI ich nie widać) natomiast w devices wszystkie sa na miejscu.
Bramka nie działa, jest konflikt przy kazdym dodanym fizycznym urzadzeniu do bramiki w cloud. Nie pomogło nawet skasowanie wszystkich akcji lokalnych (myślałem ze one powodują konfliokt) i restart.
W zakładce channels gui bramki jest tylko jedno urzadzenie GATEWAY EVENTS, wszystkie inne zniknęły.

STOP
zrobiłem teraz restart z Rebuild missing Supla channels on next startup
i Wszystkie kanały w gui bramki się pojawiły konflikt zniknął, ale moje nazwy zniknęły, virtual binary zniknął, bramki zniknęły, tak jak wcześniej opisywałem.

Rebuild missing Supla channels on next startup to procedura ratunkowa w przypadku uszkodzenia pliku z danymi kanałów. Ta procedura próbuje odbudować kanały Supla na podstawie zapisanych danych urządzeń Zigbee, dlatego nie odbuduje logiki lokalnej. Wniosek - w trakcie eksperymentów z lokalną logiką musiało dojść do uszkodzenia tablicy kanałów.
Czy to jest bramka testowa czy produkcyjna? Zrobiłeś kopię zapasową?
Przyznaję, że bardzo trudno jest mi powtórzyć ten błąd w moim środowisku testowym, więc czekam na każdą informację, która może pomóc - możesz opisać proces dodawania VR/VB/bramek logicznych do bramki?

mmiikk · Post Mon Apr 13, 2026 8:49 pm

vajera wrote: Mon Apr 13, 2026 8:06 pm
mmiikk wrote: Mon Apr 13, 2026 7:36 pm
2. Jaki stan po starcie bramki ma VIRTUAL BINARY (VB)? OFF czyli 0? Czy mozna to gdzies podglądać bieżący stan?
To mi się zdarzyło juz dwukrotnie i jest zakakżdym razem replikowalne.
Dodanie LOCAL VIRTUAL BINARY i włączenie w cloud rejestracje nowych urzadzeń powoduje ze sie pojawia, tam sensor ktroy ustawiam na binary sensor - pk
Ale teraz dodanie akcji z tym bvirtual binatry , a moze ustawienei autoset, powoduje ze po pierwszym restarcie mamy w cloud konflikt wlasnie na tym dodanym czujnku wirtualnym.
Jesli w cloud nei wlaczymy dodawanai nowych urzadzen wszytko bedzie dizac, ale przy pierwszym nowym urzadzeniu o i po ponownym restarcie bramki zawsze mamy konflikt.
Musze usunac tem binary sensor z cloud zeby bramka zechciala dzialac.

Drugi raz było jednak gorzej, jakby brama straciła wszystkie dodane urzadzenia w channels (w GUI ich nie widać) natomiast w devices wszystkie sa na miejscu.
Bramka nie działa, jest konflikt przy kazdym dodanym fizycznym urzadzeniu do bramiki w cloud. Nie pomogło nawet skasowanie wszystkich akcji lokalnych (myślałem ze one powodują konfliokt) i restart.
W zakładce channels gui bramki jest tylko jedno urzadzenie GATEWAY EVENTS, wszystkie inne zniknęły.

STOP
zrobiłem teraz restart z Rebuild missing Supla channels on next startup
i Wszystkie kanały w gui bramki się pojawiły konflikt zniknął, ale moje nazwy zniknęły, virtual binary zniknął, bramki zniknęły, tak jak wcześniej opisywałem.
Rebuild missing Supla channels on next startup to procedura ratunkowa w przypadku uszkodzenia pliku z danymi kanałów. Ta procedura próbuje odbudować kanały Supla na podstawie zapisanych danych urządzeń Zigbee, dlatego nie odbuduje logiki lokalnej. Wniosek - w trakcie eksperymentów z lokalną logiką musiało dojść do uszkodzenia tablicy kanałów.
Czy to jest bramka testowa czy produkcyjna? Zrobiłeś kopię zapasową?
Przyznaję, że bardzo trudno jest mi powtórzyć ten błąd w moim środowisku testowym, więc czekam na każdą informację, która może pomóc - możesz opisać proces dodawania VR/VB/bramek logicznych do bramki?

Powtórzę jutro wszystkie kroki i zobaczymy czy znajdę schemat , bramka jest kopią pierwszej bramki, zrobioną przez wrzucenie nowego firmwaru full i kopii backupu bramki pod odpowiedni adres wg wątku który mi kiedys podałeś. Potem sparówałem czunjnik otwarcia i przycisk a potem tylko wgrałem update do wersji z autoset dla virtual binary: Z2S-1.5.1-07/04/26
Potem zacząłem eksperymentować z autoset zmieniałem nazwy i robiłem i zmieniałem lokalne akcje.

vajera · Post Mon Apr 13, 2026 8:52 pm

mmiikk wrote: Mon Apr 13, 2026 8:49 pm Powtórzę jutro wszystkie kroki i zobaczymy czy znajdę schemat , bramka jest kopią pierwszej bramki, zrobioną przez wrzucenie nowego firmwaru full i kopii backupu bramki pod odpowiedni adres wg wątku który mi kiedys podałeś. Potem sparówałem czunjnik otwarcia i przycisk a potem tylko wgrałem update do wersji z autoset dla virtual binary: Z2S-1.5.1-07/04/26

OK, jedno ważne pytanie - bramka jest kopią pierwszej bramki - co się stało z oryginałem? Rozumiem, że nie uruchamiałes obu bramek jednocześnie?