[Problem-rozwiązany] Licznik wielofunkcyjny Manufacturer name _TZE284_5m4nchbm | model ID TS0601 [bramka ZigBee]

[slawek]

Oczywiście - no problem...

[vajera]

Oczywiście - no problem...

Więc tak:

W tej wersji 1.4.67 przestawiłem zapis na co 1 kWh, dodatkowo okazało się, że bramka nie robi zapisu również przy restarcie z poziomu Cloud/GUI - wypróbuj wersję 1.4.68-02/03/26 - robiłem dzisiaj test na "udawanym" liczniku i wydaje się działać prawidłowo.

[klew]

Jeżeli tak jest i licznik raportuje zużycie energii z dokładnością do 0,01 kWh, to mogę wymusić zapis np. co 0,1 kWh? Przy średnim obciążeniu rzędu 1 kW zapis będzie mniej więcej 10×/h = 87600 zapisów rocznie. Biorąc pod uwagę, że LittleFs ma wbudowany wear levelling a bramka zapisuje tam niewiele danych, to daje lata pracy?

Ogólnie liczniki typu MEW itd. zawsze zapisują stan przed wysłaniem danych na serwer, co przy stałym obciążeniu potrafi robić zapis co 5-10 s.
Taka częstotliowość może szybko flash wykończyć.

Aktualnie najczęściej stosuję mechanizm "wear levelingu", który zrobiłem specjalnie na potrzeby "Storage" w SUPLI. Zajmuje np. 500 kB i zapisuje tam za każdym razem w inne miejsce w kółko. To potrafi dać spodziewaną żywotność flasha na poziomie kilkudziesięciu lat (więc jest spory zapas).

Przy LittleFs - nie wiem jak to działa. LittleFs na pewno ma swój narzut odnośnie ilości danych. Wear leveling jest też zawsze oparty o rozmiar partycji. Jeśli LittleFs ma 20 kB, to niewiele z tego się wyciśnie.

Także ja bym tutaj nie szedł w wyliczenia na oko. Te 87k zapisów rocznie to już dobra estymata. Pytanie na ile niezależnych zapisów LittleFs to rozłoży. Bo jeśli wyjdzie ich kilka, to w zasadzie wykończysz flash w "kilka" lat (albo w rok, jeśli ktoś doda 3 takie liczniki i każdy będzie w swoim czasie robił zapis).

W gotowych urządzeniach, zapis jest zawsze przed wysłaniem, aby uniknąć tych "reset licznika" widocznych w Cloud. Jeśli będziesz zapisywał co 1 kWh (czy inną wybraną wartość), to każdy reset zasilania/bramki będzie generował tego typu "reset licznika" na wykresie (on się pojawia, gdy odczyt licznika jest mniejszy niż poprzedni z historii).

[vajera]

Aktualnie najczęściej stosuję mechanizm "wear levelingu", który zrobiłem specjalnie na potrzeby "Storage" w SUPLI. Zajmuje np. 500 kB i zapisuje tam za każdym razem w inne miejsce w kółko. To potrafi dać spodziewaną żywotność flasha na poziomie kilkudziesięciu lat (więc jest spory zapas).

Przy LittleFs - nie wiem jak to działa. LittleFs na pewno ma swój narzut odnośnie ilości danych. Wear leveling jest też zawsze oparty o rozmiar partycji. Jeśli LittleFs ma 20 kB, to niewiele z tego się wyciśnie.

LittleFs ma swój własny, dynamiczny mechanizm wear leveling - sporo szczegółów jest w dokumentacji technicznej tego systemu.

Także ja bym tutaj nie szedł w wyliczenia na oko. Te 87k zapisów rocznie to już dobra estymata. Pytanie na ile niezależnych zapisów LittleFs to rozłoży. Bo jeśli wyjdzie ich kilka, to w zasadzie wykończysz flash w "kilka" lat (albo w rok, jeśli ktoś doda 3 takie liczniki i każdy będzie w swoim czasie robił zapis).

Zmieniłem już częstotliwość na 1kWh.

W gotowych urządzeniach, zapis jest zawsze przed wysłaniem, aby uniknąć tych "reset licznika" widocznych w Cloud. Jeśli będziesz zapisywał co 1 kWh (czy inną wybraną wartość), to każdy reset zasilania/bramki będzie generował tego typu "reset licznika" na wykresie (on się pojawia, gdy odczyt licznika jest mniejszy niż poprzedni z historii).

Czyli sugerujesz żebym wysyłał do Supla tylko te pomiary, które się zapiszą, tak? Wtedy licznik w aplikacji Supla/Cloud będzie pokazywał pomiary co 1 kWh, chyba, że użytkownik uruchomi bramkę ponownie z poziomu Cloud/GUI - wtedy licznik też się zapisze, ale ta wartość zostanie wysłana jako pierwsza przy ponownym uruchomieniu, więc nie będzie efektu "resetu licznika".
"

[klew]

Nie sugeruję. Chciałem tylko napisać dlaczego coś jest robione i jakie będą skutki różnych rozwiązań.

To samo odnośnie wear levelingu. To nie jest żadna magiczna technika, tylko po prostu rozkładanie kolejnych zapisów po całym dostępnym obszarze flasha.
Jeśli little fs będzie miał małą partycję, to WL niewiele da. Nie czytałem dokumentacji little fs w tym zakresie, tylko piszę aby nie zakładać że będzie ok, tylko to przeliczyć

[slawek]

Testuję wersję 1.4.68-02/03/26 i chyba jest tak jak powinno być - restart bramki w GUI jak i z poziomu clouda powoduje, że stan licznika zmniejsza się nieco, ale zawsze poniżej 1 kWh. Stan z bieżącego miesiąca nie zmienia się, ale on jest trochę do tyłu (ciekawe, bo po 3 restartach bramki w kilkuminutowych odstępach czasu ten odczyt jest wyższy od stanu total - czyli jest zapisywany inną metodą?).
Restart licznika nie zmienia i nie gubi wskazań.
Jeśli nie będzie częstych restartów bramki, to nie powinno się to mocno rozjeżdżać. Rozumiem, że po restarcie jest ponownie wpisywana ostatnia zapisana wartość, która aktualizuje się co 1 kWh?

[vajera]

Testuję wersję 1.4.68-02/03/26 i chyba jest tak jak powinno być - restart bramki w GUI jak i z poziomu clouda powoduje, że stan licznika zmniejsza się nieco, ale zawsze poniżej 1 kWh. Stan z bieżącego miesiąca nie zmienia się, ale on jest trochę do tyłu (ciekawe, bo po 3 restartach bramki w kilkuminutowych odstępach czasu ten odczyt jest wyższy od stanu total - czyli jest zapisywany inną metodą?).
Restart licznika nie zmienia i nie gubi wskazań.
Jeśli nie będzie częstych restartów bramki, to nie powinno się to mocno rozjeżdżać. Rozumiem, że po restarcie jest ponownie wpisywana ostatnia zapisana wartość, która aktualizuje się co 1 kWh?

W wersji 1.4.69-02/03/26 zrobiłem jeszcze inaczej - tam licznik uaktualnia się co 1kWh i wtedy również następuje zapis wartości licznika.
W teorii nie powinno to powodować żadnego rozjeżdżania się wartości, ale w najmniej korzystnym scenariuszu (restart przy 1,99 kWh) te 0,99 kWh przepadnie.

[klew]

Jeśli miałeś zapisy historii:
0,1
1,0
1,5
Reset
Powrót do 1,0
1,6
2,0
2,4
Reset
Powrót do 2,0
its
To: licznik finalnie pokaże 2,0, a miesiąc 2,8-2,9

[vajera]

Jeśli miałeś zapisy historii:
0,1
1,0
1,5
Reset
Powrót do 1,0
1,6
2,0
2,4
Reset
Powrót do 2,0
its
To: licznik finalnie pokaże 2,0, a miesiąc 2,8-2,9

W wersji 1.4.69-02/03/26 zrobiłem to inaczej:

1. licznik "główny" MM
2. licznik buforowy BM

Każda zmiana energii dodawana jest do BM, dopiero kiedy BM przekroczy 100 (1 kWh), to:

1. wartość BM jest dodawana do MM,
2. BM zeruje się,
3. MM zapisuje się w pamięci FLASH,
3. Do ElectricityMeter (Supla) leci setFwdEnergy(0, MM).

Tym sposobem do historii będą trafiać tylko zapisy
0,0 kWh
1,0 kWh
2,0 kWh
i każdy taki zapis trafi również do FLASH, więc po resecie (planowanym i nieplanowanym) stany licznika w bramce i w Supla powinny się zgadzać (również te miesięczne). Wadą jest ryzyko utraty do 0,99 kWh/restart, natomiast w przypadku tego licznika i tak nie uzyskamy wysokiej precyzji pomiaru, bo np. każda aktualizacja kodu bramki spowoduje, że część pomiarów nie zostanie zarejestrowana, podobnie w przypadku dodawania nowego urządzenia itd.

[Instal]

Jeśli miałeś zapisy historii:
0,1
1,0
1,5
Reset
Powrót do 1,0
1,6
2,0
2,4
Reset
Powrót do 2,0
its
To: licznik finalnie pokaże 2,0, a miesiąc 2,8-2,9

W wersji 1.4.69-02/03/26 zrobiłem to inaczej:

1. licznik "główny" MM
2. licznik buforowy BM

Każda zmiana energii dodawana jest do BM, dopiero kiedy BM przekroczy 100 (1 kWh), to:

1. wartość BM jest dodawana do MM,
2. BM zeruje się,
3. MM zapisuje się w pamięci FLASH,
3. Do ElectricityMeter (Supla) leci setFwdEnergy(0, MM).

Tym sposobem do historii będą trafiać tylko zapisy
0,0 kWh
1,0 kWh
2,0 kWh
i każdy taki zapis trafi również do FLASH, więc po resecie (planowanym i nieplanowanym) stany licznika w bramce i w Supla powinny się zgadzać (również te miesięczne). Wadą jest ryzyko utraty do 0,99 kWh/restart, natomiast w przypadku tego licznika i tak nie uzyskamy wysokiej precyzji pomiaru, bo np. każda aktualizacja kodu bramki spowoduje, że część pomiarów nie zostanie zarejestrowana, podobnie w przypadku dodawania nowego urządzenia itd.

Czy powyższa zmiana dotyczy wszystkich liczników ( tych tzw gniazdowych)?