KPOP w supla-device

[klew]

Nie bardzo wiem co chcesz mi powiedzieć, przedtem zapisywałem na adresie 0 i druga zmienna na adresie 1. Pojawiały się wartości "skądś".
Zmieniłem adresy na 100 i 101. Problem wydaje się zniknął.
Możesz napisać co było źle? Supla już używała tych adresów do czego innego? Uczę się cały czas.

Klasa Storage działa domyślnie od adresu 0. Adres końcowy ciężko określić, jest to jakieś kilkadziesiąt bajtów + kilka bajtów razy każdy kanał co zapisuje dane...
Dlatego łatwiej jest dodać offset do klasy storage i ustawić żeby zapisywał np od adresu 100 w górę. Wtedy wiesz że na adresach 0-99 możesz robić co chcesz i Supla tego nie nadpisze

[SOYER]

Bardzo dziękuję. Cenne.
Jak to zrobić najprościej? Muszę dodawać biblioteki od supla storage? Czy wystarczy samo:
Supla::Eeprom eeprom(10);
?
Czy jeszcze inaczej?

[klew]

Klasa Supła::Eeprom dziedziczy po Storage. Także trzeba dodać do niej plik nagłówkowy i dodać tak jak napisałeś.

Trzeba też pamiętać, że to nie jest prawdziwy Eeprom, tylko zapis do flasha, który nazywa się Eeprom, bo w Arduino jest Eeprom. Także pamiętaj o limicie ilości zapisów, aby żywotność flasha nie była zbyt krótka.

[SOYER]

Dzięki, tak myślałem i przeczytałem wcześniej tu:
viewtopic.php?t=7162
tylko nie wiedziałem o co chodzi z tym offsetem, teraz już wiem.
Co do ilości zapisów to ich raczej za dużo nie będzie(?). Jeden co godzinę i jeden na dobę. To już 25 na dobę minimum przy resetowaniu liczników deszczu. To jest około 10000 rocznie. Dodatkowo dwa przy ew. resecie esp/wgrywaniu nowego szkicu. No i 4 zapisy na każde 0.15mm deszczu. Co przy rocznej ilości opadów w Polsce w okolicach 300L/m2, daje ok 2000 zapisów. To razem 12000 zapisów od samego deszczu na rok. Ile wykonuje Supla nie wiem. Kupować FRAM?

Jeszcze w temacie, jak użyć metod Supla/storage/eeprom do zapisu/odczytu konkretnej zmiennej w konkretnym, wybranym przeze mnie czasie?

[klew]

Flash z reguły ma deklarowane 100000 zapisów. Także przy 10000 rocznie, powinno działać koło 10 lat.
Jeszcze dużo zależy od tego jak ta klasa Eeprom realizuje zapisy i czy robi tzw wear-leveling - to może znacząco zwiększyć ilość możliwych zapisów.

Po co chcesz zapisywać ten opad godzinny?

[SOYER]

Niestety po ustawieniu offestu najpierw na 10, a potem nawet na 100, problem nie zniknął. Na adresie 0 i 1 pojawiają się wartości 83 i 85 jak dobrze pamiętam. Cofnąłem szkic do wersji mojego zapisu na adresach 100 i 101. Jest ok.

[SOYER]

Po co chcesz zapisywać ten opad godzinny?

Tego wymaga weatherclod do wyświetlania rain rate co sobie tłumaczę jako intensywność opadów.

[klew]

Po co chcesz zapisywać ten opad godzinny?

Tego wymaga weatherclod do wyświetlania rain rate co sobie tłumaczę jako intensywność opadów.

To wiem. Zastanawiam się w jakim celu chcesz to do flasha zapisywać.

[SOYER]

Po co chcesz zapisywać ten opad godzinny?

Tego wymaga weatherclod do wyświetlania rain rate co sobie tłumaczę jako intensywność opadów.

To wiem. Zastanawiam się w jakim celu chcesz to do flasha zapisywać.

A jak esp zrobi reset w środku ulewy? Nie będę znał intensywności opadów;)

[klew]

A jak esp zrobi reset w środku ulewy? Nie będę znał intensywności opadów;)

Godzinowy opad zawiera dane o opadzie w ciągu godziny .
Przy zapisie co godzinę, możesz utracić dane z ostatnich ~60 min. A jak już minie godzina i wyślesz te dane na serwery, to już tego nie potrzebujesz.
Także trzeba by częściej to zapisywać, aby tego pomiaru godzinnego nie utracić.

BTW. wrzuciłem przed chwilą drobną aktualizację dla KLOP-a - doszła metdoa setKeepStateInStorage(bool) - jak odalisz ją z "true", to klasa będzie zapisywać stan do Storage.
Także będzie to działało dość podobnie do IC.