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

[klew]

Z jednej strony udało się odczytać storage:

Code: Select all

Storage initialization
readStorage: 8; Read: [53 55 50 4C 41 1 0 1 ]
Storage: Number of sections 1
Reading section: 0
readStorage: 7; Read: [3 7 0 DB 50 DB 50 ]
Section type: 3; size: 7
storedCRC 20699, CRC calc 20699
LittleFsConfig: file "/supla-dev.cfg" size 390
LittleFsConfig: initializing storage from file...
LittleFsConfig: init result success

Ale potem przy wczytywaniu elementów, padła walidacja:

Code: Select all

 *** Supla - Load state storage
Validating storage state section with current device configuration
Warning! Attempt to write state outside of section size.
Storage: rewriting element state section. All data will be lost.
Element state section size doesn't match current device configuration
 *** Supla - Load state storage done

Komunikat mówi o tym, że jest więcej "Elementów", które próbują pisać/czytąć ze Storage, niż było przed zapisem.

W poprzednim logu (tam gdzie stan był 0) nie ma tego błędu.

Jakby było więcej logów, to byłoby lepiej
Tak aby było od startu, przez update + 2 minuty pracy.

[klew]

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?

[klew]

Logi (update z 0.8.91 do 1.24 - moduł 4MB)
1. Bramka na sofcie w wersji 0.8.91 (postawiona na nowo)
2. Sparowany 1 czujnik (ruchu)
3. Czujniki z ustawioną odwróconą logiką (aby prawidłowo wskazywał)
4. Update bramki do 1.24 po kablu
5. I sukces, a raczej błąd, bo czujnik wstaje ze stanem aktywnym. Trzeba go wzbudzić i poczekać, jak wróci do stanu wyjściowego (nieaktywny). Wtedy już działa OK.
6. Logi w załączniku
7. To musi być to (tal linijka kodu), o której pisał @vajera.

Znalazłem - ta zmiana w kodzie pierwszy raz pojawia się w wersji 0.9.54-03/10/2025.

Wcześniej nieuważnie czytałem.

Jeśli wersja 0.9.54 wprowadza to ustawienie na Storage, to aktualizacja z wersji przed tą zmianą, do nowszego będzie wysypywała storage. Samo parowanie urządzeń nie ma znaczenia.
Po prostu zmienia się format danych i nie da się tego sensownie odczytac.

Ta linijka musi zostać, bo inaczej Storage na bramce będzie się dużo częściej wysypywał.

[vajera]

Logi (update z 0.8.91 do 1.24 - moduł 4MB)
1. Bramka na sofcie w wersji 0.8.91 (postawiona na nowo)
2. Sparowany 1 czujnik (ruchu)
3. Czujniki z ustawioną odwróconą logiką (aby prawidłowo wskazywał)
4. Update bramki do 1.24 po kablu
5. I sukces, a raczej błąd, bo czujnik wstaje ze stanem aktywnym. Trzeba go wzbudzić i poczekać, jak wróci do stanu wyjściowego (nieaktywny). Wtedy już działa OK.
6. Logi w załączniku
7. To musi być to (tal linijka kodu), o której pisał @vajera.

Znalazłem - ta zmiana w kodzie pierwszy raz pojawia się w wersji 0.9.54-03/10/2025.

Wcześniej nieuważnie czytałem.

Jeśli wersja 0.9.54 wprowadza to ustawienie na Storage, to aktualizacja z wersji przed tą zmianą, do nowszego będzie wysypywała storage. Samo parowanie urządzeń nie ma znaczenia.
Po prostu zmienia się format danych i nie da się tego sensownie odczytac.

Ta linijka musi zostać, bo inaczej Storage na bramce będzie się dużo częściej wysypywał.

Jest jeszcze jedna hipoteza - w którejś z 1.1.x włączyłem zapis stanu w lokalnych VirtualBinary (tych tworzonych w bramce np. na potrzeby lokalnej logiki) - jeżeli ktoś ma takowe, to to uaktualnienie też mogło skasować Storage.

[klew]

Jest jeszcze jedna hipoteza - w którejś z 1.1.x włączyłem zapis stanu w lokalnych VirtualBinary (tych tworzonych w bramce np. na potrzeby lokalnej logiki) - jeżeli ktoś ma takowe, to to uaktualnienie też mogło skasować Storage.

W takiej sytuacji wręcz musi kasować a hipoteza staje się udowodnionym twierdzeniem

[Zibi_007]

Jakby było więcej logów, to byłoby lepiej
Tak aby było od startu, przez update + 2 minuty pracy.

No to już chyba niepotrzebne, ale może w celach edukacyjnych proszę bardzo:

Logi (update z 0.8.91 do 1.24 - moduł 4MB)
1. Bramka na sofcie w wersji 0.8.91 (postawiona na nowo)
2. Sparowany 1 czujnik (ruchu) aby nie zaśmiecać niczym więcej logów
3. Czujniki z ustawioną odwróconą logiką (aby prawidłowo wskazywał)
4. Update bramki do 1.24 po kablu
5. Czujnik wstaje ze stanem aktywnym. Trzeba go wzbudzić i poczekać, jak wróci do stanu wyjściowego (nieaktywny). Wtedy już działa OK.
6. Logi w załączniku - od restartu bramki po update, przez wzbudzenie czujnika aby był aktywny, powrót do stanu wyjściowego, ponowna aktywacja i czekanie na powrót.

[vajera]

Jest jeszcze jedna hipoteza - w którejś z 1.1.x włączyłem zapis stanu w lokalnych VirtualBinary (tych tworzonych w bramce np. na potrzeby lokalnej logiki) - jeżeli ktoś ma takowe, to to uaktualnienie też mogło skasować Storage.

W takiej sytuacji wręcz musi kasować a hipoteza staje się udowodnionym twierdzeniem

q.e.d.

[klew]

q.e.d.

Ten skrót, choć pisany inaczej, kojarzy mi się z elektrodynamiką kwantową

[vajera]

q.e.d.

Ten skrót, choć pisany inaczej, kojarzy mi się z elektrodynamiką kwantową

Fakt

[Zibi_007]

q.e.d.

Ten skrót, choć pisany inaczej, kojarzy mi się z elektrodynamiką kwantową

Fakt

I jak to na takim Forum można szybko przejść od Archimedesa przez Halmosa do Feynmana. To tylko tutaj jest możliwe