Kilka DS18b20 na jednym pinie.

User avatar
Duch__
Posts: 506
Joined: Wed Aug 24, 2016 7:26 pm
Location: Opole

Sat Jan 12, 2019 8:57 pm

Aktualnie na budowie: 8x SRW-01, 1x ROW-02, SUPLA BUTTON V2.0, 16 x DS na ESP (GUI), Sonoff S20 jak kontroler CWU, Ping IP Socket.

Przydatne linki:
viewtopic.php?f=9&t=4160
search.php?keywords=
SpeedBit
Posts: 8
Joined: Wed Aug 29, 2018 8:56 pm

Sun Jan 13, 2019 7:24 pm

PioKar wrote:
Sat Jan 12, 2019 8:00 pm
#define SRPC_QUEUE_SIZE 2
#define SRPC_QUEUE_MIN_ALLOC_COUNT 2
- zmień cyferki 2 na większe :-)
Tylko Na jakie 4, 8, ?

Szkoda że tematu nikt nie pociągnął.
Może ktoś z "Olimpu" się wypowie.
Czy to jest warte przeprogramowania moich płytek?
Ja bardzo nie chciałbym dostać info z serwisu że zawaliłem bazę bo sobie coś zacząłem generować...
Wolę najpierw się upewnić.
Przyjmowanie danych przez bazę to jedno, a wysyłanie z devica to drugie.
Jeśli będzie dużo userow i mało danych to ilościowo będzie tak jak by było mało i dużo danych.
Na pracę samej chmury/ bazy żaden z użytkownikow nie ma wpływu.
Natomiast problem po stronie devica dotyczy ewidentnego gubienia danych (ramek) jeśli poprzednie nie zostały wysłane. Pół biedy jeśli to termometr (chociaż, jeśli ktoś zrobi sobie termostat to może się zdziwić czasami) ale jesli w danej chwili wystąpi kilka innych zdarzeń, które trzeba pilnie wysłać, a one zginą zamiast wejść do bazy i np. uruchomić jakieś zdarzenie to może być niewesolo...
Ale co ja tam wiem...ja tylko wyszukalem problem i zaproponowałem tymczasowe rozwiązanie. Pewnie okaże się, że niekiedy nie da się zwiększyć kolejki bo braknie pamięci. Ja testowałem na esp12f. Tam mam pole do popisu.
Chętnie wyslucham opinii autora/autorów softu, który naprawdę zrobił kawał dobrej roboty! Szacunek!
SpeedBit
Posts: 8
Joined: Wed Aug 29, 2018 8:56 pm

Sun Jan 13, 2019 7:48 pm

Jeszcze dopiszę dla jasności...
Nie musi nikt bazy zawalac danymi.
Wystarczy, że raz na jakiś czas przyjdą więcej niż dwa zdarzenia jednocześnie i te ponad dwa znikną i nikt się nigdy o nich nie dowie.
Jest to niebezpieczne z punktu widzenia sterowania. Mam na myśli możliwość zagubienia danych.
Zakładając hipoteczne, że w jednej chwili zawieje wiatr, trzasnie kilkoma oknami a nigdy się nie dowiemy, że ktoś nam wszedł do domu.
Taki scenariusz wymyśliłem, pewnie mogłem lepszy, ale celowo unikalem termometrow.
Powiem szczerze, że na razie nie mam pomysłu na rozwiązanie tego problemu innego niż zwiększenie początkowego rozmiaru kolejki.
Jeśli na coś wpadnę, to sprawdzę i dam znać. Obiecuję.
Pozdrawiam
Sławek
User avatar
pzygmunt
Posts: 6870
Joined: Tue Jan 19, 2016 9:26 am
Location: Paczków
Contact:

Sun Jan 13, 2019 9:49 pm

Przeżyj się temu dobrze jeszcze raz. Kolejka dla srpc dla wywołań przychodzących od razu jest zwalniana. W praktyce nie zdadzą się aby zapełniła > 1.
Dla wywołań wychodzących od razu przenoszona jest do bufora wychodzącego i to on jest istotny. Szansa na to, że zapełnisz kolejkę jest tylko wtedy gdy sieć nie odbierze danych z bufora lub nie wywołujesz iterate.

W praniu wyszło, że wystarcza tam 1, a jest 2. Jednakże jak Ci to nie wystarcza to możesz sobie zwiększyć. Serwer ma inne wartości.
SpeedBit
Posts: 8
Joined: Wed Aug 29, 2018 8:56 pm

Sun Jan 13, 2019 11:19 pm

Dziękuję za konkretną odpowiedź.
Przyznaję, że nie znam całości kodu, bo przecież go nie pisałem.
Dziękuję też za potwierdzenie, że taka możliwość może wystąpić.
Ja używałem esp12f, router tplink plus sieć światłowód 50 Mb. Sieć praktycznie nieobciążona. Na esp wepchnalem początkowo sporo, ale ma koniec testowałem tylko w konfiguracji 1 czujnik no plus 4 ds18
Czyli niezbyt wiele - 5 sygnałów. Z czego tak naprawdę pracowały tylko dsy, do tego wsadzone do złącza 2.54 obok siebie.
Zaobserwowałem efekt o którym kolega na początku wspomina.
No to skorzystałem z loga i sledzilem (wypisywalem)co się dzieje z danymi. Po dojściu do kolejki wyraźnie mogłem zauważyć, że te 2 miejsca w kolejce pokrywają się z opisem problemu. Po zwiększeniu problem zniknął. Testuje od paru dni, od wczoraj ciągle i nie ma żadnego na razie problemu.
Tak więc dziękuję za odpowiedź, informacje o szczegółach, polecam się na przyszłość
Pozdrawiam
Sławek
P.S Obiecuję w wolnej chwili spojrzeć bliżej na temat.
SpeedBit
Posts: 8
Joined: Wed Aug 29, 2018 8:56 pm

Sun Jan 13, 2019 11:50 pm

Jak zwykle ciekawe myśli przychodzą po chwili.
Testy były przeprowadzane na devicach które miały 1, góra dwa aktywne czujniki.
Jak np. Sonoff. A kto tylko dotknął tematu włożeniu większej ilości czujników do jednego devica mógł spotkać się właśnie z taką niewydolnością kolejki.
Moim zdaniem bezpieczna długość kolejki powinna być przynajmniej taką jak ilość czujników. (Dałoby się to pewnie ładnie zautomatyzowac w funkcjach addxxx klasy głównej.) Oczywiście im większa tym my większą pewność dotarcia danych na serwer. Ale pewnie wiele rozwiązań nie udźwignie dużych kolejek bo może braknie pamięci. W takich przypadkach albo dopuszczamy ryzyko gubienia ramek albo trzeba zmniejszyć ilość czujników na devicu :-)
Pozdrawiam
Sławek
User avatar
pzygmunt
Posts: 6870
Joined: Tue Jan 19, 2016 9:26 am
Location: Paczków
Contact:

Mon Jan 14, 2019 5:46 am

Wprowadzę globalnie makro które pozwoli z poziomu build.sh modyfikować ten parametr
SpeedBit
Posts: 8
Joined: Wed Aug 29, 2018 8:56 pm

Mon Jan 14, 2019 7:00 am

A jak ktoś zapomni zmodyfikować?
A gdyby tak w każdym addxxx rodzaju czujnika robić inkrementacje zmiennej pomocniczej chwilowej i w begin jakoś spowodować new kolejki z tym parametrem?
Pozdrawiam
Sławek
P.S. Nie znam dokładnie struktury program więc mogę się mylić.
klew
Posts: 125
Joined: Thu Jun 27, 2019 12:16 pm

Sat Sep 21, 2019 8:07 am

Problem z biblioteką na Arduino IDE jest taki, że jest to napisane pod kątem używania na Arduino Mega, które ma 8 kB pamięci RAM. 3 kB zjada program na starcie.
Jeden element w kolejce allokuje 1 kB. Kolejki są dwie. Do tego dochodzi problem fragmentacji pamięci.
Do tej pory bawiłem się na przykładzie, gdzie było załadowane 6 kanałów, do tego dołożyłem 2 liczniki impulsów, a wczoraj przyszły mi dodatkowe DHT22. Po dodaniu trzech DHT22 wszystko zaczęło się sypać. Nawet rejestracja urządzenia w chmurze czasem nie dawała rady (błędy w allokacji pamięci na kolejce).
Kolejkę wychodzącą jest bardzo łatwo przepełnić, gdy ma się kilka termometrów. Ich odczyty potrafią się zmieniać przy każdym odczycie, więc supla-dev wysyła dane do serwera. Metoda iterate i liczenie czasu (10 s dla termometrów) po jakim mają być zrobione odczyty działa tak, że wszystkie termometry są czytane i wysyłane w jednym wykonaniu metody iterate. W praktyce częso widziałem próbę allokacji 4 elementów na kolejkę wychodzącą i wszystko padało ;). Dlatego zwiększanie kolejki na Arduino Mega nic nie daje, bo tam nie ma pamięci na większą kolejkę z tak dużymi elementami.
Jak na razie udało mi się to uruchomić aby działało stabilnie, ale te kolejki są do przepisania, bo te kilka kB RAM-u to wyzwanie ;)
User avatar
pzygmunt
Posts: 6870
Joined: Tue Jan 19, 2016 9:26 am
Location: Paczków
Contact:

Sat Sep 21, 2019 8:31 am

Spostrzeżenia bardzo prawidłowe. To jest do przeskoczenia ale wymaga poświęcenia chwili czasu.
Post Reply