Data Update po zerwaniu/odzyskaniu połączenia.

Masz pomysł na funkcjonalność lub koncepcję na rozwój projektu. Opisz wszystko tutaj.
Post Reply
lgorek
Posts: 21
Joined: Sat Aug 31, 2019 8:35 pm

Thu Oct 10, 2019 8:53 am

Witam,

Od jakiegoś czasu jestem użytkowaniem Supla. Projekt jest dość prężenie rozwijany jednak wg mnie brakuje bardzo ważnej rzeczy a dokładnie Data Update po zerwaniu połączenia. Wiele z was wie o co chodzi ale dla tych, którzy nie wiedzą.

Przykład:
Czujniki DS18B20 oraz BME280, przekazują dane do chmury wszystko jest do czasu kiedy:
1. brak połączenia wifi pomiędzy ESP a routerem
2. brak połączenia internetowego
3. brak prądu a ESP na zasilaniu awaryjnym np 18650
4. brak prądu

Ostatni punkt jest chyba jasny. Jednak w obecnej formie, gdy zabraknie internetu na 12 godzin internetu w wykresach mamy dziurę. Na poniższym screenie są chwilowe zaniki. Warto rozważyć opcję Data Update po zerwaniu/odzyskaniu połączenia.

Przykład:
1. ESP traci połączenie z wifi przez co nie może wysyłać na chmurę, jednak zapisuje to w swojej pamięci i gdy zostanie ponownie nawiązane połączenie z chmurą wyśle brakujące dane.
2. j.w.
3. j.w.
4. będzie dziura w wykresie, ewentualnie wykres zostanie automatycznie uzupełniony tak aby nie było dziur.

Nie wszyscy mają stałe łącze internetowe, obecnie tam gdzie mieszkam mam przez GSM internet jest ale różnie z nim bywa. Dlatego Data Update after lost connection byłby idealnym rozwiązaniem.

Dodatkowo mam pytanie, w przypadku kiedy nasz ESP traci połączenie lub jest wyłączony etc. w Supla pojawia się czerwona kropka, wszystko było by dobrze ale nie jesteśmy w stanie wejść w wykres. Dlaczego kiedy czujnik nie jest podłączony do internetu nie możemy wejść w jego dane. A co w sytuacji gdy sam układ uległ spaleniu ewentualnie temperatura była za wysoka, fajnie gdyby można było to sprawdzić. Bo jakby nie patrzeć dane w chmurze są.


Image
User avatar
pzygmunt
Posts: 6613
Joined: Tue Jan 19, 2016 9:26 am
Location: Paczków
Contact:

Thu Oct 10, 2019 8:57 am

Odnośnie przechowywania pomiarów w pamięci ESP.
Zasadniczo odpada z prostego powodu.... brak miejsca.
Musiałbyś mieć coś większego np. raspberry ale to już lekka przesada/marnotrastwo aby trzymać jeden termometr na RBPI.
Rozwiązaniem dla Ciebie jest Twój własny serwer lokalnie w domu.

Co do dostępu do danych w trybie offline (gry widoczna jest czerwona kropka).
Planujemy wprowadzić taką możliwość.
lgorek
Posts: 21
Joined: Sat Aug 31, 2019 8:35 pm

Thu Oct 10, 2019 9:17 am

pzygmunt wrote:
Thu Oct 10, 2019 8:57 am
Odnośnie przechowywania pomiarów w pamięci ESP.
Zasadniczo odpada z prostego powodu.... brak miejsca.
Musiałbyś mieć coś większego np. raspberry ale to już lekka przesada/marnotrastwo aby trzymać jeden termometr na RBPI.
Rozwiązaniem dla Ciebie jest Twój własny serwer lokalnie w domu.

Co do dostępu do danych w trybie offline (gry widoczna jest czerwona kropka).
Planujemy wprowadzić taką możliwość.
Czy jak mamy takiego Wemos D1 mini PRO gdzie ma 32Mb flash to jest to za mało miejsca, tak samo w przypadku ESP-01 z 8Mb flash? Czy tego miejsca nie da się wykorzystać ?
User avatar
pzygmunt
Posts: 6613
Joined: Tue Jan 19, 2016 9:26 am
Location: Paczków
Contact:

Thu Oct 10, 2019 10:10 am

32MB to jeszcze rzadkość. Większość to 512/1024/2048KB. Za chwile byłoby 1000 problemów osób które nie mają dostępnych nawet kilku bajtów.
Ponadto co Ci po 32MB jak ilość cykli zapisu jest ograniczona, a jeden cykl musi obejmować cały sektor ?
Pisanie obsługi lokalnego składowania w sytuacji gdy możesz postawić sobie lokalny serwer to nierozsądnie wykorzystanie zasobów, których jest i tak mało.

[EDIT]
Kolejna sprawa zegar czasu rzeczywistego.
Wyobraź sobie, że ESP podczas braku internetu się restartuje i nie wie w jakim momencie w czasie jest ?
Wyobrażasz sobie użytkowników montujących RTC do ESP jak z DS-ami są problemy ?

Nie sztuka zrobić rozwiązanie, które rodzi nowe problemy. Sztuka to zaproponować takie, które rozwiązuje stare, a nie rodzi nowych.
lgorek
Posts: 21
Joined: Sat Aug 31, 2019 8:35 pm

Thu Oct 10, 2019 11:41 am

pzygmunt wrote:
Thu Oct 10, 2019 10:10 am
32MB to jeszcze rzadkość. Większość to 512/1024/2048KB. Za chwile byłoby 1000 problemów osób które nie mają dostępnych nawet kilku bajtów.
Ponadto co Ci po 32MB jak ilość cykli zapisu jest ograniczona, a jeden cykl musi obejmować cały sektor ?
Pisanie obsługi lokalnego składowania w sytuacji gdy możesz postawić sobie lokalny serwer to nierozsądnie wykorzystanie zasobów, których jest i tak mało.

[EDIT]
Kolejna sprawa zegar czasu rzeczywistego.
Wyobraź sobie, że ESP podczas braku internetu się restartuje i nie wie w jakim momencie w czasie jest ?
Wyobrażasz sobie użytkowników montujących RTC do ESP jak z DS-ami są problemy ?
Tak wiem, że dostępne są różne wielkości pamięci flash, jednak ta wartość będzie rosła a nie malała.
Co do RTC to miałem o tym pisać ale już była Twoja odpowiedź, dokładnie niby pierdoła ale zegar musi być. Bo bez internetu nie zna godziny.

Jeżeli chodzi o własny serwer jest to może dobre rozwiązanie ale musimy go na czymś postawić a i tak gdy stracą czujniki sygnał z bazą to nie zapiszą nam temperatury.

Nie sztuka zrobić rozwiązanie, które rodzi nowe problemy. Sztuka to zaproponować takie, które rozwiązuje stare, a nie rodzi nowych.
Tutaj masz rację.
klew
Posts: 60
Joined: Thu Jun 27, 2019 12:16 pm

Thu Oct 10, 2019 12:40 pm

Na Arduino Mega jest 8 kB pamięciu ;). kB, nie MB.
RTC jest konieczny tylko jeśli pojawiłby się reset. Poza tym wystarczą interwały czasowe, a te są znane kontrolerowi. Tylko protokół się komplikuje, bo trzeba sprawdzać, czy wysłanie wiadomości się powiodło, następnie trzeba by dodać "wiek/godzinę" do wiadomości wysyłającej dane. Nie wiem czy to jest gra warta świeczki.

Pomiary służa tylko do logowania danych. Jeśli dla kogoś są to dane krytyczne, to powinien oprzeć swój termoemtr na przemysłowych rozwiązaniach, a nie domowych/DIY :)
Post Reply