Przyciski, guziki, kontrolery scen - zgłoszenia, uwagi, pomysły [bramka ZigBee]

[LukiSpajder]

Taka sytuacja zdarza się też kiedy usuwamy urządzenie z bramki ,czujnik otwarcia okna zadziała, występuje to w chwil polaczenia z Supla. Tu logi z takiej sytuacji na bramce testowej. Pod koniec to jest , czujnik w Supli dalej jest offline a zmienił stan .
Może coś tam wypatrzycie , chyba że tak ma być. Logika nieodwrócona w czujniku okna.

Chciałbym się upewnić:
1. Masz czujnik na z2s i jest widoczny w Cloud. Powiedzmy, że ma stan 1 oraz odwróconą logikę (więc jest nieaktywny w Cloud).
2. Na bramce go usuwasz (ale nie w Cloud).
3. Urządzenie restuje połączenie i próbuje łączyć się ponownie
4. Pojawia sie konflikt kanałów
5. W cloud aktywuje się ten usunięty czujnik (stan pewnie zmienia się na 0, ale jest odwrócona logika, więc robi się "aktywny")
6. Po jakimś czasie usuwasz kanały tego urządzenia z Cloud

Tak?

Mam kilka urządzeń na bramce : głowica , termometr , czujnik otwarcia okna i przycisk Ikea . Te trzy pierwsze spięte ze sobą w Cloud pod termostatem. Usuwam przycisk Ikea z bramki , potem konflikt kanałów w Cloud , usuwam kanał z konfliktem . Układ się łączy z Supla i po chwili aktywuje się czujnik otwarcia okna . Który nadal jest offline w zakładce „i”.

[LukiSpajder]

Zebrałem jeszcze logi kiedy czujnik raportują stan zadziałania po uruchomieniu bramki. W sytuacji po przywróceniu z kopi zapasowej . Po starcie bramki czujnik zalania zmienia stan ( odwrócona logika w Cloud) ale czujniki okna pewnie też to zrobił tylko nie ma odczytu temperatury i apka tego nie pokaże po pojawieniu się odczytu temp. wskoczyło okno otwarte.

Nie wiem czy to wiarygodna sytuacja i czy warto na to spoglądać - oceńcie sami

[vajera]

Zebrałem jeszcze logi kiedy czujnik raportują stan zadziałania po uruchomieniu bramki. W sytuacji po przywróceniu z kopi zapasowej . Po starcie bramki czujnik zalania zmienia stan ( odwrócona logika w Cloud) ale czujniki okna pewnie też to zrobił tylko nie ma odczytu temperatury i apka tego nie pokaże po pojawieniu się odczytu temp. wskoczyło okno otwarte.

Nie wiem czy to wiarygodna sytuacja i czy warto na to spoglądać - oceńcie sami

Nie patrzyłem na logi - wyjaśnienie poniżej:

Przyznaję, że nie miałem świadomości, że implementacja Storage korzysta z partycji nvs - dopiero @klew mi to uświadomił.
Partycja nvs znajduje się standardowo PRZED partycją OTA, więc standardowy backup bramki (od adresu 0x290000/0x690000) jej nie obejmie. W związku z tym, jeżeli po backupie zostanie dodane/usunięte urządzenie zapisujące swój stan w Storage, to po przywróceniu backupu wystąpi niezgodność i Supla wyzeruje Storage.
Nie jest to duża niedogodność (a może jest?), ale jeżeli komuś przeszkadza, to widzę dwa rozwiązania:

1. Robimy backup całego C6, w razie potrzeby odtwarzamy go i dopiero wtedy wgrywamy ewentualny upgrade kodu bramki.

2. Oprócz standardowego backupu robimy jeszcze backup partycji nvs (od adresu 0x9000, rozmiar 0x5000) i w razie potrzeby odtwarzamy oba.

Moim zdaniem rozwiązanie nr 1 jest znacznie wygodniejsze, ale tylko nr 2 pozwoli przenieść partycję nvs pomiędzy 4 a 8 MB FLASH.

[LukiSpajder]

Zebrałem jeszcze logi kiedy czujnik raportują stan zadziałania po uruchomieniu bramki. W sytuacji po przywróceniu z kopi zapasowej . Po starcie bramki czujnik zalania zmienia stan ( odwrócona logika w Cloud) ale czujniki okna pewnie też to zrobił tylko nie ma odczytu temperatury i apka tego nie pokaże po pojawieniu się odczytu temp. wskoczyło okno otwarte.

Nie wiem czy to wiarygodna sytuacja i czy warto na to spoglądać - oceńcie sami

Nie patrzyłem na logi - wyjaśnienie poniżej:

Przyznaję, że nie miałem świadomości, że implementacja Storage korzysta z partycji nvs - dopiero @klew mi to uświadomił.
Partycja nvs znajduje się standardowo PRZED partycją OTA, więc standardowy backup bramki (od adresu 0x290000/0x690000) jej nie obejmie. W związku z tym, jeżeli po backupie zostanie dodane/usunięte urządzenie zapisujące swój stan w Storage, to po przywróceniu backupu wystąpi niezgodność i Supla wyzeruje Storage.
Nie jest to duża niedogodność (a może jest?), ale jeżeli komuś przeszkadza, to widzę dwa rozwiązania:

1. Robimy backup całego C6, w razie potrzeby odtwarzamy go i dopiero wtedy wgrywamy ewentualny upgrade kodu bramki.

2. Oprócz standardowego backupu robimy jeszcze backup partycji nvs (od adresu 0x9000, rozmiar 0x5000) i w razie potrzeby odtwarzamy oba.

Moim zdaniem rozwiązanie nr 1 jest znacznie wygodniejsze, ale tylko nr 2 pozwoli przenieść partycję nvs pomiędzy 4 a 8 MB FLASH.

Oki , dziękuję za wyjaśnienie

[Zibi_007]

Zebrałem jeszcze logi kiedy czujnik raportują stan zadziałania po uruchomieniu bramki. W sytuacji po przywróceniu z kopi zapasowej . Po starcie bramki czujnik zalania zmienia stan ( odwrócona logika w Cloud) ale czujniki okna pewnie też to zrobił tylko nie ma odczytu temperatury i apka tego nie pokaże po pojawieniu się odczytu temp. wskoczyło okno otwarte.

Nie wiem czy to wiarygodna sytuacja i czy warto na to spoglądać - oceńcie sami

Nie patrzyłem na logi - wyjaśnienie poniżej:

Przyznaję, że nie miałem świadomości, że implementacja Storage korzysta z partycji nvs - dopiero @klew mi to uświadomił.
Partycja nvs znajduje się standardowo PRZED partycją OTA, więc standardowy backup bramki (od adresu 0x290000/0x690000) jej nie obejmie. W związku z tym, jeżeli po backupie zostanie dodane/usunięte urządzenie zapisujące swój stan w Storage, to po przywróceniu backupu wystąpi niezgodność i Supla wyzeruje Storage.
Nie jest to duża niedogodność (a może jest?), ale jeżeli komuś przeszkadza, to widzę dwa rozwiązania:

1. Robimy backup całego C6, w razie potrzeby odtwarzamy go i dopiero wtedy wgrywamy ewentualny upgrade kodu bramki.

2. Oprócz standardowego backupu robimy jeszcze backup partycji nvs (od adresu 0x9000, rozmiar 0x5000) i w razie potrzeby odtwarzamy oba.

Moim zdaniem rozwiązanie nr 1 jest znacznie wygodniejsze, ale tylko nr 2 pozwoli przenieść partycję nvs pomiędzy 4 a 8 MB FLASH.

Jest takie narzędzie: https://thelastoutpostworkshop.github.io/ESPConnect/
Nim można sobie zgrać i odtworzyć każdą partycję. Używam już tylko tego, bo skrypt viewtopic.php?t=17758 na najnowszej wersji Windows 11 odmówił współpracy.
I jeszcze jedno, bo może wszyscy nie wiedzą. Rozwiązanie nr 1 zadziała o ile aktualizujemy z wersji 0.9.54-03/10/2025 lub nowszej. W przypadku starszych też będzie zmiana stanu na czujnikach spowodowana użyciem Supla::Storage::Instance()->enableChannelNumbers();

[LukiSpajder]

Jest takie narzędzie: https://thelastoutpostworkshop.github.io/ESPConnect/
Nim można sobie zgrać i odtworzyć każdą partycję. Używam już tylko tego, bo skrypt viewtopic.php?t=17758 na najnowszej wersji Windows 11 odmówił współpracy.
I jeszcze jedno, bo może wszyscy nie wiedzą. Rozwiązanie nr 1 zadziała o ile aktualizujemy z wersji 0.9.54-03/10/2025 lub nowszej. W przypadku starszych też będzie zmiana stanu na czujnikach spowodowana użyciem Supla::Storage::Instance()->enableChannelNumbers();

Testowałem ostatnio ten kombajn , opcji dużo , można konkretne partycje zgrać jako i cały wsad.
Chociaż jak chodziłem logi tym zebrać to coś nie zabardzo

[Zibi_007]

Jest takie narzędzie: https://thelastoutpostworkshop.github.io/ESPConnect/
Nim można sobie zgrać i odtworzyć każdą partycję. Używam już tylko tego, bo skrypt viewtopic.php?t=17758 na najnowszej wersji Windows 11 odmówił współpracy.
I jeszcze jedno, bo może wszyscy nie wiedzą. Rozwiązanie nr 1 zadziała o ile aktualizujemy z wersji 0.9.54-03/10/2025 lub nowszej. W przypadku starszych też będzie zmiana stanu na czujnikach spowodowana użyciem Supla::Storage::Instance()->enableChannelNumbers();

Testowałem ostatnio ten kombajn , opcji dużo , można konkretne partycje zgrać jako i cały wsad.
Chociaż jak chodziłem logi tym zebrać to coś nie zabardzo

A bo to w okienku u góry musisz ustawić 115200 (baud rate), jak wejdziesz na serial monitor. Wtedy powinno być już OK

[vajera]

Wersja 1.1.34-09/01/26 przywraca funkcjonalność debounce dla przycisków w wersji action trigger.
Zachowana została również dotychczasowa zasada - jeżeli ten czas nie jest ustawiony, bramka przyjmuje 100 ms (1500 ms dla Moes 4x3).

[robertklepacki94]

Wersja 1.1.34-09/01/26 przywraca funkcjonalność debounce dla przycisków w wersji action trigger.
Zachowana została również dotychczasowa zasada - jeżeli ten czas nie jest ustawiony, bramka przyjmuje 100 ms (1500 ms dla Moes 4x3).

Dzięki za info, u mnie same Moesy także dziś testy:)

[vajera]

Wersja 1.1.35-09/01/26 dodaje do GUI (zakładka Gateway) przełącznik umożliwiający wybór modelu dodawania urządzeń typu smart buttons (AT/legacy VR).

Przełącznik domyślnie jest włączony, czyli urządzenia dodają się jako AT, jego wyłączenie nie zmieni nic w temacie już dodanych urządzeń, natomiast nowe urządzenia będą się wtedy dodawać jako VR. Oczywiście cały czas zachowana zostaje możliwość pracy obu mechanizmów jednocześnie, tzn. w obrębie jednej bramki można mieć przyciski pracujące jako VR i jako AT, ale w obrębie różnych urządzeń Zigbee.

Zachęcam do korzystania z nowego modelu, ten tryb legacy nie będzie już zasadniczo rozwijany.