Data Update po zerwaniu/odzyskaniu połączenia.

Masz pomysł na funkcjonalność lub koncepcję na rozwój projektu. Opisz wszystko tutaj.
lgorek
Posty: 44
Rejestracja: sob sie 31, 2019 8:35 pm

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ą.


Obrazek
Awatar użytkownika
pzygmunt
Posty: 18333
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontakt:

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
Posty: 44
Rejestracja: sob sie 31, 2019 8:35 pm

pzygmunt pisze: czw paź 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ć ?
Awatar użytkownika
pzygmunt
Posty: 18333
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontakt:

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
Posty: 44
Rejestracja: sob sie 31, 2019 8:35 pm

pzygmunt pisze: czw paź 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ę.
Awatar użytkownika
klew
Posty: 8289
Rejestracja: czw cze 27, 2019 12:16 pm
Lokalizacja: Wrocław

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 :)
Widzimy się na Supla Offline Party vol. 2 :!:
ODPOWIEDZ

Wróć do „Pomysły i koncepcje”