Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

ESP8266 działający przez lata na zasilaniu bateryjnym

ghost666 16 Mar 2018 21:55 7860 11
  • ESP8266 działający przez lata na zasilaniu bateryjnym
    Poniższy projekt to stacja pogodowa oparta na module z układem ESP8266. Nie byłoby w niej nic szczególnego, co wyróżnia ją na tle innych tego rodzaju konstrukcji, gdyby nie optymalizacja systemu pod kątem minimalizacji poboru prądu. Wykorzystany mikrokontroler nie jest zbyt energooszczędny, więc średnio sprawdza się w aplikacjach zasilanych bateryjnie - ESP8266 z włączonym interfejsem WiFi pobiera średnio około 70 mA, co oznacza, że baterie w takiej stacji pogodowej trzeba by dosyć często wymieniać.

    Autor tego projektu chciał uniknąć konieczności częstego wymieniania baterii w stacji pogodowej, dlatego też oprócz wspominanego układu ESP8266 zastosował ATtiny85, który pozwolił zmniejszyć pobór prądu - ten skromny AVR realizuje większość pomiarów i łączy się, poprzez ESP8266, z siecią bezprzewodową tylko co jakiś czas (około godziny), aby przesłać dane do serwera. Dzięki temu średni pobór prądu w układzie można było bardzo ograniczyć.

    Założenia projektowe:

    * Praca na jednym zestawie baterii przez co najmniej dwa lata.
    * Pomiar co dwie minuty następujących wartości:
    - Temperatura
    - Wilgotność
    - Natężenie światła
    * Łączenie się z siecią Wi-Fi i serwerem co godzinę, aby przesłać dane. Jeśli serwer jest niedostępny, to dane są zapisywane w buforze i przesyłane przy kolejnej próbie połączenia.
    * Serwer danych, przechowujący zebrane przez układ dane w basie danych InfluxDB.
    * Interfejs użytkownika oparty o Grafanę.

    ESP8266 działający przez lata na zasilaniu bateryjnym
    Pierwszy prototyp

    Oprogramowanie testowane było na testowym urządzeniu, złożonym na płytce uniwersalnej i płytce stykowej. Do programowania ATtiny85 wykorzystano klon programator USBTinyISP i konwerter RS232 na 3,3 V. Oba elementy pokazane są na zdjęciu.

    Projektowanie

    Pierwszym pomysłem, było utrzymywanie modułu ESP w stanie głębokiego uśpienia, gdy moduł nie jest potrzebny do komunikacji. Po wybudzeniu, bez włączonego interfejsu radiowego, ESP8266 pobiera około 16 mA. Niestety wadą tego rozwiązania jest fakt, że po uruchomieniu, aby połączyć się z siecią, układ potrzebuje około trzech sekund. To strasznie dużo dla systemu zasilanego z baterii.





    Autor testował różne rozwiązania, mające skrócić czas łączenia się z siecią, na przykład poprzez nadanie statycznego numeru IP. Udało się skrócić czas łączenia do pół sekundy, jednakże czasami - około jednego na dziesięć przypadków - zdarzało się, że łączenie zajmowało 1,5 sekundy. Autorowi nie udało się dociec, co jest tego przyczyną - najpewniej to wynik kolizji w sieci, ponieważ układ zachowywał się tak częściej w dzień, a rzadziej w nocy.

    Większością zadań w układzie zajmuje się ATtiny85. Mikrokontroler ten uruchamia sensory, zbiera z nich dane poprzez I²C, wybudza ESP8266 i wykorzystuje go do przesłania danych do serwera.

    Obliczenia

    Zanim prace projektowe będą mogły pójść dalej, konieczne jest wykonanie pewnych obliczeń dotyczących zasilania. Zawarte są one w poniższej tabeli (arkusz Excela z tymi wyliczeniami pobrać można ze strony autora).

    ESP8266 działający przez lata na zasilaniu bateryjnym


    Jak wynika z powyższych obliczeń, dwie alkaliczne baterie AA - mające około 2000 mAh łącznie - powinny umożliwić sensorowi działanie przez cztery lata w tym optymistycznym scenariuszu. Realnie czas będzie krótszy; jak szacuje autor około dwóch lat. Wartość ta potwierdzona zostanie eksperymentalnie.

    Przykład działania systemu

    Na poniższym zrzucie ekranu widać przykładowe dane prezentowane przez Grafanę. Pokazują one przebieg mierzonych wartości w ciągu jednego dnia.

    ESP8266 działający przez lata na zasilaniu bateryjnym


    Potrzebne materiały

    Autor zamówił wszystkie potrzebne do konstrukcji układu elementy na AliExpress. Konieczne są:

    * Moduł ESP8266 12E.
    * Płytka z TSL2561.
    * Płytka z SI7021.
    * Mikrokontroler ATtiny85.

    Dodatkowo potrzebna jest płytka uniwersalna, która pozwoli na połączenie tych modułów ze sobą.

    ESP8266 działający przez lata na zasilaniu bateryjnymESP8266 działający przez lata na zasilaniu bateryjnymESP8266 działający przez lata na zasilaniu bateryjnymESP8266 działający przez lata na zasilaniu bateryjnym


    Schemat ideowy

    Poniższy schemat pokazuje, w jaki sposób połączone są ze sobą poszczególne komponenty w systemie:

    ESP8266 działający przez lata na zasilaniu bateryjnym


    Moduł z ESP i mikrokontroler ATtiny85 podłączone są do tych samych linii interfejsu I²C. Na schemacie nie ma rezystorów podciągających na liniach SCL i SDA, ponieważ takowe znajdują się na płytkach z sensorami.

    Sensory zasilane są poprzez pin PB4 w ATtiny. Dzięki temu można odłączać je, gdy mikrokontroler jest uśpiony - daje to dodatkowe oszczędności prądu.

    Wszystkie pomiary są zapamiętywane przez mikrokontroler AVR. W momencie, gdy chce on wybudzić ESP, musi ściągnąć do masy linię PB1 na kilka milisekund, co powoduje start modułu ESP8266.

    Na płytce znajdują się dwa złącza do programowania:
    -jedno dla ESP8266, które programowane jest poprzez UART. Wystarczy zdjąć zworkę PGM protect, ściągnąć PGM do masy i podłączyć do pinów TX i RX odpowiedni konwerter na UART 3,3 V. Po zakończonym programowaniu przestajemy ściągać PGM do masy i zakładamy zworkę;
    -drugie złącze służy do programowania ATtiny poprzez interfejs SPI. Piny Reset, MOSI, MISO, SCK oraz masa łączone są do programatora, w tym przypadku TinyUSBISP.

    Cykl pracy programu

    1. Mikrokontroler ATtiny jest uśpiony. Budzi się co sekundę, by sprawdzić, czy musi wykonać pomiar; jeśli nie, to wraca do stanu uśpienia.
    2. Co dwie minuty głębokiego uśpienia system uruchamia się i podaje zasilanie na sensory.
    3. Poprzez interfejs I²C mikrokontroler, jako master, sczytuje dane z sensorów.
    4. Po zakończeniu pomiarów i zapisaniu danych, ATtiny wyłącza zasilanie sensorów i przechodzi w stan uśpienia.
    5. Co około godzinę (30 pomiarów) mikrokontroler wybudza ESP8266 i konfiguruje swój interfejs I²C do pracy jako slave. Czeka teraz na reakcje ESP.
    6. Po uruchomieniu się mikrokontroler ESP8266 pobiera dane, wraz z pewnymi statystykami z AVRa poprzez I²C.
    7. ESP8266 łączy się z serwerem napisanym w Pythonie i przesyła zgrane dane.
    8. Po poprawnym przesłaniu danych na serwer ESP8266 informuje ATtiny85, że wysyłanie danych zakończyło się sukcesem i można je bezpiecznie wykasować.
    9. ESP8266 przechodzi w stan uśpienia.
    10. ATtiny zakończyło swój cykl, więc wchodzi w stan uśpienia i powyższa sekwencja zaczyna się od nowa.

    Firmware dla ATtiny85

    Kod programu, napisany w Arduino, znaleźć można na GitHubie autora projektu (link na samym dole).

    W głównej pętli programu zawarto maszynę stanów kontrolującą, co robi obecnie układ - śpi, mierzy, budzi ESP czy wysyła dane. W momencie, gdy dokona się pomiar, zostanie on zapisany do RAMu, a jeśli nie będzie to możliwe, bo będzie on np. zapełniony, to skasowany zostanie najstarszy rekord.

    Ważne pliki:[/v]

    Setup.h: Tutaj znajduje się główna konfiguracja programu. Zmienna deviceID identyfikuje dokładnie urządzenie. Tutaj zapisano też, jak często wykonywane są pomiary i jak często AVR budzi moduł ESP, by przesłać dane poprzez sieć Wi-Fi.
    Power.h: Ten plik zawiera metody do włączania i wyłączania zasilania sensorów, wybudzania ESP oraz usypiania układu ESP w tan głębokiego uśpienia na jedną sekundę.
    Storage.h: To klasa abstrakcji, pozwalająca na przechowywanie pomiarów w pamięci RAM. Wykorzystuje strukturę SensorData, która przekazywana jest do tej klasy. Klasa ta posiada także szereg metod, między innymi podawanie danych bajt po bajcie, tak aby umożliwić wysyłanie ich poprzez I²C.
    Sensor.h: Biblioteka do obsługi sensorów: TSL2541 do mierzenia jasności słońca oraz SI7021 do pomiaru temperatury i wilgotności.
    SlaveI2C.h: Biblioteka do obsługi ATtiny85 w trybie Slave na I²C, gdy ESP jest masterem. Biblioteka ta jest odpowiedzialna za przesyłanie danych z pamięci do ESP8266. Podczas tej transmisji używane są następujące komendy:

    'B' - ESP domaga się statystyk pracy układu. Przesyłane są one w postaci 9 bajtów w formacie AABBCCDEF, gdzie:

    AA (uint16) to ilość bajtów pomiarów, jakie przygotowane są do wysłania.
    BB (uint16) to częstotliwość wybudzania ESP w sekundach.
    CC (uint16) to częstotliwość pomiarów w sekundach.
    D (uint8) to rozmiar struktury SensorData w bajtach.
    E (uint8) to numer urządzenia od 0 do 9, musi być unikalny.
    F (uint8) to liczba logicznych (nie fizycznych) sensorów - jest ona potrzebna, by serwer danych wiedział, na ile pól danych ma się przygotować dla każdego pomiaru.

    'D' - ESP domaga się surowych danych pomiarowych, wysyłamy je bajt po bajcie. ESP wie, ile bajtów musi odczytać, ponieważ informacja ta zawarta jest w statystykach.

    'A' - Dane zostały z powodzeniem przekazane do bazy danych na serwerze, można opróżnić bufor danych.

    'Z' - ESP informuje, że usypia się, co oznacza, że ATtiny może rozpocząć kolejny cykl działania.

    Firmware dla ESP8266

    Kod napisany w Arduino dla tego układu także dostępny jest na GitHubie.

    Program działający na ESP jest bardzo prosty. Układ wczytuje dane sieci Wi-Fi z EEPROMu i łączy się z Acces Pointem wykorzystując do tego statyczne IP, aby wszystko działało jak najszybciej. Po podłączeniu do sieci bezprzewodowej, układ odczytuje statysyki z ATtiny, a następnie pobiera dane z układu.

    Pobrane dane wysyłane są jako pakiety TCP do serwera z bazą danych.

    Po zakończeniu transmisji układ informuje AVRa o powodzeniu operacji i usypia się.

    [u]Ważne pliki:



    MyWifi.h: pin GPIO14 ESP jest wewnętrznie podciągnięty do zasilania, ale jeżeli podczas uruchamiania będzie on w stanie niskim, to układ wejdzie w stan tzw. WiFiManagera. W tym stanie ESP8266 konfiguruje się jako AP i pozwala, po połączeniu, skonfigurować użytkownikowi następujące parametry:

    * Statyczny adres IP,
    * Maska podsieci,
    * Adres bramki,
    * Zdalne IP serwera,
    * Port, na którym serwer nasłuchuje pakietów.

    Wszystkie te dane zapisywane są na wewnętrznym EEPROMie, skąd układ zaczytuje je każdorazowo, startując w normalnym trybie pracy.

    MasterI2C.h: Biblioteka ta zajmuje się obsługą interfejsu I²C. Pobiera ona statystyki i dane pomiarowe z AVRa i wysyła je po Wi-Fi do serwera. Układ ten w ogóle w żaden sposób nie czyta danych pomiarowych, jedynie przekazuje je dalej.

    Serwer bazodanowy

    Aplikacja serwerowa napisana została w Pythonie. Źródła serwera także do znalezienia są na GitHubie autora.

    Działanie serwera jest bardzo proste. Po prostu nasłuchuje on komunikacji TCP na pewnym konkretnym porcie. W momencie, gdy trafi tam jakiś pakiet, program uruchamia nowy wątek, który zajmuje się obsługą odebranych danych. Pakiety danych są parsowane, a następnie wrzucane do bazy danych InfluxDB, wraz z nazwą i czasem (timestampem) do późniejszej obróbki, analizy czy prezentacji.

    Ważne pliki

    main.py: Tutaj znajduje się konfiguracja na jakim porcie TCP serwer ma nasłuchiwać. Tutaj też znajdują się dane do logowania do serwera z bazą danych InfluxDB.

    Program najpierw łączy się z bazą danych, następnie dla każdego urządzenia, identyfikowanego po deviceID, uruchamiany jest osobny parser, ponieważ każde z urządzeń może mieć inaczej skonfigurowane sensory czy czasy pomiędzy pomiarami. Dodatkowo, dzięki temu aplikacja lepiej działa w systemie wielowątkowym. Finalnie uruchamiany jest serwer TCP, który rozpoczyna nasłuch i odbieranie nadchodzących pakietów.

    influx.py: W momencie, gdy zadeklarowana zostanie klasa zapisana w tym pliku, nawiązywane jest połączenie z bazą danych InfluxDB. Klasa ta ma metodę writeData, która służy do zapisu pomiarów w bazie danych. Metoda ta wykorzystywana jest przez klasę sensorParser.

    server.py: Łączy się z portem TCP i nasłuchuje w nieskończonej pętli. Po otrzymaniu pakietu, opierając się na deviceID, uruchamia odpowiedni obiekt sensorParser i przekazuje mu dane.

    generalParser.py: To ogólny parser dla nadchodzących danych. Rozkłada on pakiet na poszczególne części i analizuje dane, takie jak:

    * Device ID,
    * Czas pomiędzy pomiarami ATtiny,
    * Jak często wybudza się ESP,
    * Ile sensorów jest w układzie.

    Następnie zaczyna analizować dane pomiarowe i przekazuje je do przeciążonej metody handleNexMeasurement. Metoda ta z kolei korzysta z prostych metod pomocniczych - getFloat, getUint, getByte w celu interpretacji danych.

    sensorParse.py: Głównym celem tego pliku jest przeciążanie metody handleNextMeasurement w generalParser.py. W metodzie tej zawarto wszystkie detale analizy danych dla poszczególnych deviceID, więc to tutaj do pomiarów przypisywane są nazwy, zanim wpisane zostaną one do bazy danych. Zawartość tego pliku należy edytować, jeżeli chcemy zmienić zestaw sensorów w układzie.

    Pomiary realnego poboru prądu

    ESP8266 jest naprawdę bardzo energochłonnym układem. Dlatego też warto sprawdzić, ile realnie prądu pochłania ten układ w momencie, gdy nadaje pakiety danych. Do tego celu autor wykorzystał swój logger do pomiaru prądu i napięcia. Rezultaty przedstawione są na poniższym wykresie:

    ESP8266 działający przez lata na zasilaniu bateryjnym


    ESP wybudzane jest na około 0,7 s i pobiera wtedy średnio 78 mA.

    Kolejnym jest pomiary poboru prądu przez ATtiny podczas wykonywania pomiarów. Prąd ten jest tak mały, że konieczna była zmiana opornika pomiarowego spiętego w INA219 z 0,1 Ω na 10 Ω, czyli zwiększenie czułości (transkonduktancji) układu stukrotnie.

    ESP8266 działający przez lata na zasilaniu bateryjnym


    Pomiar pokazuje, że układ zbiera dane przez około 180 ms i pobiera w tym czasie średnio 1,35 mA. Pobór prądu jest tak niski, dzięki redukcji zegara układu z 8 MHz do 1 MHz. Przy wyższej częstotliwości pobór wynosił ponad 10 mA.

    Modyfikacje wprowadzone do układu do pomiaru prądu:

    ESP8266 działający przez lata na zasilaniu bateryjnym


    Podczas uśpienia układ zużywa około 23,5 µA - cały układ: ESP i ATtiny. To prąd prosto z baterii, bez przetwornicy DC/DC, która mogłaby jeszcze bardziej zmniejszyć pobierany z ogniw prąd.

    Po zebraniu wszystkich powyższych pomiarów można było podsumować pobór prądu i oszacować, na ile starczyć powinna bateria w systemie. Obliczenia pokazana są w tabeli poniżej. Okazuje się, że są całkiem zbliżone do tych początkowych.

    ESP8266 działający przez lata na zasilaniu bateryjnym


    Dalsze plany

    Kolejnym krokiem autora konstrukcji ma być instalacja przetwornicy DC/DC w systemie, która ma pomóc jeszcze bardziej zwiększyć wydajność energetyczną systemu.

    Źródła:
    https://github.com/x821938/UltraLowPower_WeatherStation
    https://www.cron.dk/esp8266-on-batteries-for-years-part-1/
    https://www.cron.dk/esp8266-on-batteries-for-years-part-2/
    https://www.cron.dk/esp8266-on-batteries-for-years-part-3/
    https://www.cron.dk/esp8266-on-batteries-for-years-part-4/
    https://www.cron.dk/esp8266-on-batteries-for-years-part-5/


    Fajne!
  • #2 17 Mar 2018 16:37
    pier
    Poziom 23  

    Cytat:
    Pierwszym pomysłem, było utrzymywanie modułu ESP w stanie głębokiego uśpienia, gdy moduł nie jest potrzebny do komunikacji. Po wybudzeniu, bez włączonego interfejsu radiowego, ESP8266 pobiera około 16 mA. Niestety wadą tego rozwiązania jest fakt, że po uruchomieniu, aby połączyć się z siecią, układ potrzebuje około trzech sekund. To strasznie dużo dla systemu zasilanego z baterii.

    Autor testował różne rozwiązania, mające skrócić czas łączenia się z siecią, na przykład poprzez nadanie statycznego numeru IP. Udało się skrócić czas łączenia do pół sekundy, jednakże czasami - około jednego na dziesięć przypadków - zdarzało się, że łączenie zajmowało 1,5 sekundy. Autorowi nie udało się dociec, co jest tego przyczyną - najpewniej to wynik kolizji w sieci, ponieważ układ zachowywał się tak częściej w dzień, a rzadziej w nocy.


    No więc po co Autor zastosował dodatkowy procesor? Nie żadnej wzmianki o tym że po zastosowaniu ATtiny85 ESP szybciej łączy się z siecią.
    Moim zdaniem tak sprawny procesor jak ESP8266 spokojnie poradzi sobie ze wszystkimi zadaniami bez Attiny.


    A i jeszcze jedno:
    Cytat:
    To prąd prosto z baterii, bez przetwornicy DC/DC, która mogłaby jeszcze bardziej zmniejszyć pobierany z ogniw prąd.


    To czyli że po zastosowaniu przetwornicy pobór prądu spadnie? A sama przetwornica nic nie potrzebuje?

  • #3 17 Mar 2018 18:32
    3029369
    Użytkownik usunął konto  
  • #4 17 Mar 2018 22:30
    Frog_Qmak
    Poziom 25  

    Może chodzi o to, że zastosuje się przetwornicę, pozwalającą "wyciągnąć" maksimum z baterii, kiedy będzie ona zbyt słaba (spadki napięcia podczas działania) do zapewnienia normalnej pracy układu? Jakaś prosta przetwornica typu chińskich ładowarek USB startujących poniżej 1V + duży kondensator, całość uruchamiana gdy układ wykryje, że sama bateria już "niedomaga"?

  • #5 18 Mar 2018 00:01
    krisRaba
    Poziom 25  

    Patrząc na płytkę z ESP raczej chodzi o zastosowanie przetwornicy step-down w miejsce stabilizatora liniowego. Są dostępne takie z bardzo małym prądem Iq i wtedy rzeczywiście zaobserwowalibyśmy spadek prądu. Choć przy takim zasilaniu przydałby się buck/boost z niskim Iq.. ale tylko do ESP i innych prądożernych rzeczy. Przy malutkich prądach czuwania attiny możliwe że bardziej się go opłaca zasilać właśnie przez LDO.
    A może dostrzegli jeszcze, że obniżenie napięcia zasilania attiny jeszcze bardziej zmniejsza zużycie prądu i w ogólnym bilansie, uwzględniając sprawność, wyszliby na plus? ;)

    Swoją drogą tytuł naciągany, bo to nie ESP pracuje lata na zasilaniu bateryjnym, tylko attiny :P To tak jakby napisać, że zbudowałem układ z komputerem SBC czy nawet PC, działający przez lata na małym akumulatorze, bo włączam jego zasilanie co pół roku na 2 minuty ;)

  • #6 18 Mar 2018 11:34
    Marek_Ertew
    Poziom 15  

    Podobne wyniki można uzyskać na samym ESP8266, budząc go co 2 minuty (wspomniane w oryginalnym artykule) a wifi odpalając jedynie co godzinę. W ten sposób prąd pracy będzie większy ale spoczynkowy mniejszy.

    Jedyny plus zastosowania dwóch procesorów możliwość implementacji watchdog'a. ESP w momencie szukania sieci wifi potrafi się zawiesić, szczególnie gdy wskazany accesspoint jest niedostępny. W tej sytuacji ESP pobiera prąd rzędu dziesiątek mA aż do czasu zadziałania zabezpieczenia akumulatora lub wyczerpania się baterii.

    Ostatnia optymalizacja o jakiej warto pomyśleć to inne źródło zasilania - akumulator + panel fotowoltaiczny. Ale to już notka dla przyszłych konstruktorów. Autor wybrał takie rozwiązanie i jeśli działa raczej nie będzie chciał go zmieniać.

  • #7 18 Mar 2018 12:46
    pier
    Poziom 23  

    Marek_Ertew napisał:

    ESP w momencie szukania sieci wifi potrafi się zawiesić, szczególnie gdy wskazany accesspoint jest niedostępny.

    O właśnie pisałem o tym nie raz. ESP w ogóle nie radzi sobie z sytuacją kiedy jego accespoint jest niedostępny. Program zawiesza się wtedy i ESP drenuje akumulator do momentu pojawienia się sieci lub końca zasilania.
    Nie wiem tylko czy jest to wina samego ESP czy też programu, bibliotek.

  • #9 18 Mar 2018 21:03
    krzbor
    Poziom 16  

    Też szukam rozwiązania do mierzenia temperatury i wysyłania danych poprzez ESP przy zasilaniu bateryjnym. Uważam, że ESP8266 i Attiny(seria niskonapięciowa) to idealne połączenie. Nie rozumiem jednak, dlaczego autor nie wykorzystał CH_PD do sterowania (napisałem to na jego stronie, ale nic nie odpisał). Użycie CH_PD ma kilka zalet - jeszcze niższy pobór prądu przez ESP (grubo poniżej 1uA) a dodatkowo Attiny może "wyłączyć" ESP. Moja idea jest następująca:
    1. Attiny okresowo się wybudza i mierzy temperaturę (ewentualnie też napięcie zasilania).
    2. W EEPROM zachowuje wyniki - trzeba zrobić bufor cykliczny, aby nie "wykończyć" komórek.
    3. Attiny wybudza ESP i przesyła dane.
    4. ESP pracuje na stałym IP (aby nie tracić czasu na DHCP)
    5. ESP wysyła dane i informuje Attiny o tym fakcie.
    6. Jeśli Attiny stwierdzi, że czeka ponad 1s na odpowiedź, wyłącza ESP (CH_PD).

    Jeśli chodzi o punkt 3, to Attiny może okresowo wysyłać zgromadzone dane lub wysyłać dane gdy wartość temperatury zmieni się o określoną wartość.
    Myślałem o wykorzystaniu Attiny 2313V i komunikację przez UART.

  • #10 25 Mar 2018 21:04
    AIIoT
    Poziom 8  

    pier napisał:
    Marek_Ertew napisał:

    ESP w momencie szukania sieci wifi potrafi się zawiesić, szczególnie gdy wskazany accesspoint jest niedostępny.

    O właśnie pisałem o tym nie raz. ESP w ogóle nie radzi sobie z sytuacją kiedy jego accespoint jest niedostępny. Program zawiesza się wtedy i ESP drenuje akumulator do momentu pojawienia się sieci lub końca zasilania.
    Nie wiem tylko czy jest to wina samego ESP czy też programu, bibliotek.


    Ale jak ma się nie zawieszać jak większość programów/przykładów korzysta z funkcjo while
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Ja w swoich programach wrzucam łączenie siecią do funkcji z wykorzystaniem millis, po połączeniu dopiero odblokowuje funkcje które wymagają wifi. Do tego napisałem funkcje która potrafi łączyć się z kilkoma zapisanymi sieciami i w przypadku problemu z połączeniem (max 3 próby co 10 sekund jedna) moduł z wifi próbuje połączyć się z inną siecią o ile jest ona dostępna, oczywiście nie łącze się z ssid który nie jest nie wyświetla się w funkcji WiFi.scanNetworks().

    można też sprawdzić czy sieć jest już niedostępna funkcją WiFi.status() i wykonać jakąś operacje np. ponowne łączenie czy restart np. taką funkcją;
    Kod: csharp
    Zaloguj się, aby zobaczyć kod

    Nie spotkałem się z wieszaniem się modułu w tej sytuacji, fak faktem ESP8266 potrafi się zawiesić w taki sposób ze nawet programowy watchdog nie przywróci go do funkcjonowania w monecie którego nie jestem w stanie przewidzieć np. po kilku dniach i też rozważam dodawanie sprzętowego watchdoga do swoich projektów.

  • #11 25 Mar 2018 23:51
    _jta_
    Specjalista elektronik

    Moim zdaniem tak sprawny procesor jak ESP8266 spokojnie poradzi sobie ze wszystkimi zadaniami bez Attiny.

    Po pierwsze, zużyje na to kilka razy więcej energii, szybciej rozładuje baterię. Po drugie, ponoć potrafi się zawiesić i wtedy rozładuje baterię w ciągu niecałej doby.

    Jeśli ten ATtiny zużywa 23.5uA w stanie uśpienia, to będzie to ze 20% pojemności baterii (1Ah) rocznie; jeśli autorowi udało się uzyskać pracę przez 2 lata, to jest to ładny wynik, i gdyby chciało się go poprawić, to wypada rozważyć np. poszukanie bardziej energooszczędnego uC - albo łączność w większych odstępach czasu.

  • #12 08 Kwi 2018 12:41
    dktr
    Poziom 18  

    Nigdy nie zawiesił mi się żaden ESP, ani podczas pracy ani podczas łączenia z siecią.

    Ja sobie sprawdzam czy łączenie nie trwa za długo i w razie co esp.reset();

    Code:

    int rtr=0;
    while ( WiFi.status() != WL_CONNECTED ) {
      delay ( 500 );
      Serial.print ( "." );
      rtr++;
      if (rtr>10) {....}
    }