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ę.
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).
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.
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ą.
Schemat ideowy
Poniższy schemat pokazuje, w jaki sposób połączone są ze sobą poszczególne komponenty w systemie:
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:
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.
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:
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.
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/
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ę.
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).
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.
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ą.
Schemat ideowy
Poniższy schemat pokazuje, w jaki sposób połączone są ze sobą poszczególne komponenty w systemie:
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:
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.
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:
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.
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? Ranking DIY
