ESP32 im Batteriebetrieb

Einleitung

Irgendwann entsteht der Wunsch, den ESP vom Steckbrett zu befreien und ihn sinnvolle Tätigkeiten im Heimnetzwerk erledigen zu lassen. Dabei stellt sich die Frage nach der Stromversorgung. In vielen Fällen lassen sich Geräte nur im Batteriebetrieb sinnvoll versorgen.

Ein ESP32 gönnt sich bei eingeschaltetem Radio-IF ca. 100mA auf der 3,3V-Leitung. Bei einer Batteriekapazität von 1000mAh wären die Batrerien damit 2x täglich zu wechseln. Das ist natürlich völlig inakzeptabel. Batteriestandzeiten von >= 1 Jahr sollten angestrebt werden.

Der ESP32 kennt verschiedene Stromsparmodi. Für Sensoren oder Melder, die in größeren Zeitabständen Daten zu übertragen haben, ist der Deep-Sleep-Modus eine geeignete Wahl.
Ein Großteil der internen Komponenten wird dabei spannungslos geschaltet. Lediglich ein Teil der RTC-Einheit bleibt in Betrieb. Das genügt, um den Chip zeit- oder ereignisgesteuert aufzuwecken.
Aktiv bleiben der CoProzessor-Timer, mit dem sich ULP-Prozessor in definierbaren Zeitintervallen starten lässt, sowie die RTC-RAM-Blöcke, in denen der ULP-Programmcode und Daten des Hauptprogramms die Tiefschlafphasen überdauern.
Die Angaben zum Stromverbrauch differieren zwischen 6 und 10µA. Lässt man andere Faktoren außer Acht wären mit o.g. 1000mAh-Batterie Standzeiten von >10 Jahren möglich (theoretisch !).
Dies soll nur die mögliche Spanne zwischen 10 Stunden(Vollbeschäftigung) und 10 Jahren(tut garnix) zeigen. Dazwischen gilt es, ein vernünftiges Maß zu finden und HW-/SW-Desing darauf zu optimieren.

Allerdings kann ein ESP nicht per Radio-IF aus dem Tiefschlaf geweckt werden. Geräte, die ständig empfangsbereit sein müssen, lassen sich mit begrenztem Batteriebudget nicht realisieren.

Ein Wort zur Hardware vornweg. Stromsparende Schaltungen lassen sich nicht mit NodeMCU und anderen Entwicklungsboards bauen. Der schaltungstechnische Overhead, der später nichts zur Funktion beiträgt, zieht nur unnötig Strom. Breakoutboards mit minimaler Außenbeschaltung oder WROOM-Module pur sollten es schon sein.

Software-Design (Deep-Sleep)

Der obige Vergleich zeigt, dass die erreichbare Batteriestandzeit erheblich von der Laufzeit des Hauptkerns incl. Datenübertragung abhängt.
Als Beispiel soll ein einfacher Temperatursensor mit dem DS18B20 dienen. Messung und Datenübertragung erfolgen in 5min-Intervallen. Die Kommunikation auf dem One-Wire-Bus und Bereitstelung der Daten übernimmt der Co-Prozessor.
Betrachtet wird die erforderliche Batteriekapazität bei einer Laufzeit von 1 Jahr = 8760h und 100.000 Messzyklen (100kCycles). Die Stromaufnahme wurde über in Reihe geschaltete Shunt in der 3,3V-Versorgung des ESP ermittelt.

Ein Betriebszyklus lässt sich in vier Phasen einteilen. Diese sollten zur Optimierung getrennt betrachtet werden.


Deep-Sleep

In dieser Phase werden die RTC-Mem-Blöcke und der Timer des CoProzessors mit Spannung versorgt. Der ULP-Prozessor hat sich selbst über einen HALT im letzten Zyklus zur Ruhe begeben. Messen lässt sich die Stromaufnahme über einen 10kΩ Shunt. Während der Initialisierungsphase wird der Widerstand überbrückt. Ein Wert von 10mV entspricht 1µA. Die erwartete Messgröße von 10µA lässt sich so mit einem vernünftigen Voltmeter hinreichend genau bestimmen.
Messungen an einigen Exemplaren haben die Herstellerangaben bestätigt. Stromaufnahmen von 6-8µA sind realistisch.
Damit liegt der Jahresverbrauch dieser Phase bei ca. 70mAh (230mWh).

Es lohnt sich, diesen Wert in der eigenen Schaltung nachzumessen. Designfehler in Hard- oder Software, die nicht auf den ersten Blick erkennbar sind, können zu deutlich höheren Werten führen.

Beispiel: Zur Vermeidung von UART-Logout während des Bootprozesses kann GPIO15 über 10kΩ nach Masse gezogen werden. Dies spart Zeit. Dieser Pin muss dann allerdings im Hauptprogramm vor dem DeepSleep hochohmig geschaltet werden. Auch andere Ports, die mit eigener HW belegt sind, können unerwartete Ableitströme verursachen.

    //allgem. Stromsparmaßnahmen
    rtc_gpio_isolate(GPIO_NUM_12);
    rtc_gpio_isolate(GPIO_NUM_15); 
Ein zusätzlicher, überbrückter 10kΩ-Shunt in Musterexemplaren ist kein Luxus. Nach Designänderungen sollte der Ruhestrom geprüft werden.


ULP-Programm

(optional)

Im untersuchten Beispiel wird die aktive Phase durch den zeitgesteuerten Start des ULP-Programms eingeleitet. Der Programmcode wurde in der Initialisierungsphase einmalig in den RTC-SLOW-MEM geladen. Solange Spannung anliegt und das System fehlerfrei arbeitet, bleiben die Daten in diesem Speicherbereich erhalten.

Per OWP-Protokoll wird der DS18B20 zu einer Temperaturmessung veranlasst. Zur Bereitstellung der Daten benötigt er ca. 700ms. Auslesen der Daten und CRC-Prüfung erledigt wieder der ULP-Prozessor.

Der Vorgang dauert ca. 710ms. Die Stromaufnahme des ESP beträgt währenddessen 1,5mA. Nach 100kCycles liegt der Jahresverbrauch bei ca. 30mAh (100mWh).
Der Strom auf der Datenleitung des Sensors spielt keine signifikante Rolle. Der DB18B20 selbst gönnt sich während des Messvorgangs zusätzlich etwa 0,5mA auf der 3,3V-Leitung. In allen anderen Phasen ist er äußerst genügsam.

ULP Runtime Kanal A(gelb) zeigt den Stromverlauf, gemessen über einem 100Ω-Shunt. Kanal B(blau) wird über einen Debug-Port zur Abgrenzung der Phasen gesteuert.
Der WAKE-Befehl ist in diesem Beispiel auskommentiert, sodass der Chip sofort wieder in den Tiefschlaf fällt. Mit dem Spannungsabfall über dem Shunt würde die nächste Phase nicht funktionieren.
Viel ist dem Oszillogramm nicht zu entnehmen. Es zeigt lediglich eine konstante Stromaufnahme über die gesamte Phase. Der ULP-Prozessor arbeitet während >90% der Zeit den WAIT-Befehl ab. Dem Bild lässt sich entnehmen, dass damit keine Leistungsreduzierung verbunden ist.

1,5mA bei 3.3V entspricht einer Leistungsaufnahme von 5mW. Das verdient durchaus die Bezeichnung "Low-Power". Den Prefix "Ultra" haben aber vermutlich Marketing-Stategen dazugedichtet. Ein Dauerbetrieb des CoProzessors würde im Jahresbudget mit 13Ah / 43Wh zu Buche schlagen.

Die ULP-Phase ist optional. Je nach Anwendungsfall kann das Aufwecken des Hauptsystems auch aus zahlreichen anderen Quellen erfolgen.


Boot-Prozess

Programmcode und Daten werden während des Flashens in einen externen Flash-ROM geschrieben. Der ESP-Chip selbst besitzt nur einen kleinen ROM-Bereich, in dem der Bootloader untergebracht wird. Nach einem Reset müssen Code und Daten des Hauptsystems erst einmal in die internen RAM-Bereiche (IRAM/DRAM) geleaden werden. Der Vorgang ist vergleichbar mit dem Booten eines PC von einer Festplatte und dem Nachladen von Anwenderprogrammen.

Um das Booten selbst muss man sich nicht kümmern. Toolchain und Flashprozess haben dafür gesorgt, dass alles an passender Stelle landet und der Bootprozess nach einem Reset automatisch abläuft.

Allerdings kostet dieser Vorgang Zeit, in der sich das ESP-Modul mit etwa 30mA aus der Batterie bedient. Da IRAM und DRAM während der Tiefschlafphase nicht mit Spannung versorgt wurden, ist der Inhalt verloren und muss in jedem Zyklus neu geladen werden.

Der Vorgang lässt sich durch Ändern von Systemvariablen in der SDK-Configuration des Projektes erheblich beeinflussen.
Die Dauer hängt natürlich auch von der Größe des zu ladenden Datenblocks ab. Im Folgenden verwende ich ein Programm aus den IDF-Examples (Wifi-Stationmode). Unter Verwendung der Voreinstellungen dauert das Booten 266ms bei einer durchschnittlichen Stromaufnahme von 32mA. Das ergibt bei 100kCycles einen Bedarf von 236mAh (780mWh). Ein recht hoher Wert, in Anbetracht der Tatsache, dass während dieser Zeit keine nützliche Arbeit durch den ESP verrichtet werden kann. Aber wie gesagt, es gibt Schrauben, an denen gedreht werden kann.

Der größte Gewinn steckt in der Option zur Datenvalidierung nach einem DeepSleep, zu finden in der Abteilung Bootloader config. Mit Auswahl dieser Option verkürzt sich die Bootzeit auf 42ms (!) bei 27,5mA.
skip

Der Datenaustausch zwischen externem Flash und ESP-Chip erfolgt seriell per SPI-Interface. Espressif lässt den Modulherstellern die Wahl, ob die Anbindung über 2 oder 4 Leitungen erfolgt. Letzendlich kauft man immer ein Überraschungspaket, denn von außen sieht man dem Modul nicht an, was sich unter der Metallkappe verbirgt.
Die Auswahl wieviele Adress-/Datenleitungen das System nutzen soll, wird wieder in der SDK-Configuration getroffen. In der Abteilung Serial flasher config lässt sich die Breite des Busses umstellen. Per Default ist dort DIO gewählt.

Welcher Flash-Chip nun aber verbaut ist, lässt sich, wenn überhaupt nur sehr umständlich ermitteln.

esptool.py flash_id

Der kürzere Weg ist, es einfach auszuprobieren. Entweder funktioniet es, oder man schaltet wieder zurück. Nach Umstellung auf QIO landet man im Beispiel bei einer Ladezeit von 36ms mit durchschnittlich 26mA.

In einer weiteren Option lässt sich der SPI-Takt ändern. Die Erhöhung von 40 auf 80MHz verringert zwar die Ladezeit auf 29ms, erhöht aber auch den Strombedarf auf durchschnittlich 30mA. Das bringt unter dem Strich wenig, erhöht aber das Risko, dass man sich außerhalb der Chip-Spezifikation bewegt und das System unter veränderten Umgebungsbedingungen instabil wird.
flashcfg

Unterm Strich benötigt der Bootprozess nach Optimierung 26mAh (86mWh) bei 100kCycles.

boot_opt Das Oszillogramm zeigt die Stromaufname nach Optimierung bei 40MHz SPI-Takt. Die Bootphase wird durch den Low-Pegel des B-Kanals markiert. Die Stromaufnahme wurde über einen 1Ω-Shunt gemessen und über diesen Zeitram gemittelt.


Hauptprogramm

Nach dem Bootprozess startet das Hauptprogramm. Als Beispiel muss wieder das Wifi-Station-Example herhalten. Kleine Änderung: Das Programm wir hier zum Abschluss in den DeepSleep geschickt.

boot_opt Markiert wird diese Phase durch den High-Pegel des B-Kanals. Zu Beginn der Phase liegt die Stromaufnahme bei etwa 50mA. Es dauert cirka 40ms bis das WLAN-IF hochgefahren ist. Dann steigt die Stromaufnahme auf 100mA. Während der Tx-Bursts fließen 250mA. Das Oszillogramm zeigt die Verbindungsaufnahme zur Fritzbox bis hin zur Zuweisung der IP-Adresse. Die Verbindungsaufnahme zum Server und Datenübermittlung sind hier nicht enthalten und müssten auf der X-Achse rechts noch addiert werden. Der Protokolloverhead dauert 1060ms bei einer durchschnittlichen Stromaufnahme vom 80mA. Dieser Wert stammt aus der Mittelwertberechnung des Oszis (nicht nachgeprüft, scheint aber nach grobem Überschlag glaubhaft).

Das ergibt 2355mAh (7.8Wh) bei 100kCycles und sieht damit für unsere 1000mAh-Batterie nicht mehr so freundlich aus. Und das wohlgemerkt nur für den Protokolloverhead. Optimierngsmöglichkeiten wurden nicht weiter untersucht.

Espressif hat für seine Chips ein verbindungsloses Wifi-Protokoll mit der Bezeichnung ESP-NOW entwickelt. Damit lässt sich eine PeerToPeer-Kommunikation zwischen zwei ESP-Modulen (auch ESP8266) aufbauen, bei der ausschließlich Datenpakete mit bis zu 250Bytes gesendet werden. Der Overhead zur Verbindungsaufnahme entfällt. Beide Geräte müssen lediglich im gleichen WLAN-Kanal arbeiten. Die Zustellung der Datenpakete erfolgt über MAC-Adressen. IP-Adressen kennt dieses Protokoll nicht.

boot_opt Das Oszillogramm zeigt mit gleicher Auflösung den Vergleich zum obigen Bild. Hier wird ein Datenpaket eines ESP-Witterungs-Sensors (BME280+DS18B20) an den ESP-Gateway, der als zentrale Stelle im ESP-Zoo agiert, gesendet (1.Tx-Peak). Der Gateway antwortet mit einem Datenpaket, was der Sensor mit einem Response quittiert (2.Tx-Peak). Damit sind die Daten ausgetauscht und der Sensor geht wieder in den Tiefschlaf. Das Ganze dauert im Beispiel 126ms und zieht im Mittel 67mA. Damit liegt der Jahresbedarf bei nur noch 234mAh (770mWh). Somit ein klares Votum für das ESP-Now-Protokoll.
Ob der Einsatz sinnvoll ist, hängt vom Anwendungsfall ab. Bei Meldern, die bspw. Kontakte überwachen, die nur selten betätigt werden, sieht die Leistugnsbilanz völlig anders aus.


Die Stromspitzen des Senders lassen sich durch Reduzierung der Sendeleistung dämpfen. In der SDK Configuration kann der Initialwert unter Component config/PHY vorgegeben werden. Die Sendeleistung kann von +20dBm (default) bis auf +10dBm reduziert werden.

boot_opt boot_opt boot_opt Beispiel - linker Peak: Übertragung eines ESP-Now Datenpaketes (120 Datenbytes) mit 20/14/10dBm

Dies bezieht sich nur auf den Initialwert nach dem Booten. Im Hauptprogramm lässt sich die Sendeleistung jederzeit im Bereich 10.0dBm .. 20.5dBm anpassen.

esp_wifi_set_max_tx_power(uint8_t power) //0.25dBm steps [40..82]

Der ESP32 kann nebenbei im Sniffer-Betrieb arbeiten. Es lassen sich neben dem Inhalt der Datenpakete auch Parameter wie die Rx-Feldstärke auswerten. Die Feststation könnte ihrem batteriebetriebenen Gegenüber mitteilen, ob mit dem nächsten Paket die Sendeleistung erhöht oder gesenkt werden soll.
In der Gesamt-Leistungsbilanz wird das vermutl. keine bedeutende Rolle spielen. Es lassen sich aber evtl. Spannungseinbrüche verhindern, die den Prozessor ins Nirvana schicken bzw. einen Brownout-Reset auslösen und damit könnte sich die Batteriestandzeit erhöhen.


Apropos Brownout: In der SDK-Configuration kann unter Component config/ESP32-specific bestimmt werden, ob die Betriebsspannung überwacht und bei Unterschreiten ein Reset ausgelöst wird.
brownout
Durchaus sinnvoll, um nach Resetauswertung entsprechend reagieren zu können. Andererseits ärgerlich, wenn die Batterie noch lange laufen könnte.
Ggf. ist es besser, die Batteriespannung per ADC-Messung zu überwachen und bei Unterschreitung eines Grenzwertes zu reagieren.

Batterieauswahl

(In Arbeit))

Der ESP32 und Bauteile in der Peripherie stellen gewisse Ansprüche an die Spannungsversorgung. Für seine WROOM-Modul empfiehlt Espressif einen Spannungsbereich von 3.0V bis 3.6V. Mit Überspannungen sollte nur experimentieren wer zuviel von den Teilen hat. Nach unten sind aber durchaus Spielräume offen.

Bei mir läuft seit einigen Jahren ein geschlossenes ESPNOW-Netzwerk unter dem Begriff "Heimautomation". Die Kommunikation mit allen ESP-Sensoren und -Aktoren regelt ein zentraler ESP-Gateway. Die Daten aus dem Netz leitet er an einen Raspberry weiter, der sich um die intelligenteren Dinge wie MQTT oder Node-Red kümmert.
Die Aktoren im Netz werden über 50Hz versorgt, da sie ständig erreichbar sein müssen (Heizungs- und Pumpensteuerung, schaltbare Steckdosen). Die andere Spezies sind die Sensoren, die über Haus und Garten verteilt sind. Der Aufwand, diese mit Netzspannung zu versorgen wäre zu hoch.
Dies soll kein Beitrag über das Netzwerk werden. Das befindet sich ohnehin ständig im Umbau. Einige Experimente mit Batteriebetrieb habe ich aber schon hinter mir. Nur.... zu der Weisheit letzter Schluss bin ich noch nicht gelangt.

Die Urvariante basierte auf dem ESP8266. Die Sensormodule wurden mit 2x 1,5V (AAA) ausreichend lang versorgt. Bis dahin bestand kein Grund über andere Lösungen nachzudenken.
Das änderte sich mit dem Einsatz der ESP32, die anscheinend deutlich giftiger auf kurzzeitige Unterspannungen reagieren. Also mussten andere Lösungen her.


3.6V Primary Lithium-Thionyl Chloride (Li-SOCl2)

Die technischen Daten der Zellen LS14500 scheinen optimal zu sein. Die Nennspannung von 3.6V passt zur oberen Spannungsgrenze. Meine Exemplare (ca. 10Stück von unterschiedlichen Lieferanten) haben auch im Neuzustand diese Grenze nicht überschritten. Die Leerlaufspannung lag bei Anlieferung zwischen 3.5 .. 3.6V. Ob das daran lag, dass die Teile überlagert waren oder aus Klone-Produktion stammen, lässt sich nicht klären.
Die Klemmspannung wird in meinen Schaltungen bei aktivem WLan-IF, also bei einer Belastung von 100mA gemessen. Dabei zeigt sich relativ schnell ein Abfall in einen Bereich um 3.3V bei Zimmertemperatur. Die Spannung bleibt dann über einen längeren Zeitraum oberhalb 3.0V stabil.
Allerdings ist eine starke Temperaturabhängigkeit zu verzeichnen. Batterien im Außenbereich, die im Sommer 3.3V haben, fallen im Winter auf unter 2.9V und zeigen im nächsten Sommer wieder 3.2V.

Fazit:
Mit diesen Batterien lässt sich der ESP32 problemlos und vor allem direkt versorgen. Bei meinen Experimeten gab es bisher nur einen ungeklärten, vorzeitigen Ausfall. Einige Zellen sind schon auf dem zweiten Board verbaut, da sie langlebiger sind als so manches HW-Design. Das macht es aber auch schwer, ein objektives Bild zur ermitteln. Der subjektive Gesamteindruck ist aber positiv.
Auf der Negativseite steht der Preis. Die Teile kosten mehr als ein WROOM! Außerdem sind sie nicht im lokalen Einzelhandel erhältlich, sodass ggf. noch Versandgebühren dazukommen. Und auf Vorrat möchte man diese Luxusteile auch nicht kaufen. Also gilt es weiter zu suchen.

dht22a dht22b dht22c Links: Pegelsensor für Regenwasserzisterne
Rechts: Temperatur & Luftfeuchtigkeit DHT22



1.5V Alkaline - Direktversorgung

Alkaline Batterien sind von der Verfügbarkeit her optimal. Da sie auch in zahlreichen anderen Geräten zum Einsatz kommen, sind sie meist ohnehin vorhanden.
Batterien der Größe LR03 haben samt Batteriehalter erträgliche Ausmaße. Paarweise eingesetzt starten sie im Neuzustand bei 3.2V, sinken aber relativ schnell unter 3.0V.
Ein Testaufbau mit dem Klimasensor BME280 erreichte knapp 40000 Messzyklen nach etwa 5 Monaten. Schluss war bei einer Batteriespannung von 2.5V, gemessen bei einer Last von 100mA.
Das ist noch lange vor dem Lebensende der Batterie. Ursache sind vermutlich Spannungseinbrüche während der Tx-Bursts. Mit einem Stütz-Elko von 1000µF nahm die Schaltung ihren Betrieb ersteinmal wieder auf.
Bei 2.4V bewegt man sich aber ohnehin in einem Bereich, den Espressif als kritisch ansieht. Nicht umsonst beträgt die minimal einstellbare Brownout-Spannung 2.43V


1.5V Alkaline mit StepUp-Regler

Im Bastelvorrat fand sich noch ein StepUp-Regler U1V11F3. Er setzt einen Eingangsspannungsbereich von 0.5V..5.5V auf 3.3V um, liefert ausreichend Strom für den ESP32 und scheint daher geeignet, die Experimente mit 2x 1.5V (AAA) weiterzuführen.

Der Hersteller gibt einen Wirkungsgrad von 70-90% an. Das gilt jedoch nur unter Lastbedingung. Im Tiefschlafmodus des ESP32 (6µA) zieht die Schaltung 120µA aus der Batterie. Ein viel zu hoher Wert für einen Batterie-Dauerbetrieb. Aus diesem Grund entstand nachfolgende Schaltung. Die Auswahl der Bauelemente erfolgte nach Verfügbarkeit aus Restbeständen vorheriger Projekte.

bme280stepup.pdf
   Ansicht / Download

Folgende Idee steckt hinter dieser Schaltung:
Im DeepSleep ist GPIO33/RTC_GPIO8 low. Damit sind T2 und T1 gesperrt. Die Spannungsversorgung der Schaltung erfolgt über D2. Da die Batterie nicht belastet wird, hat sie in dieser Zeit eine relativ hohe Leerlaufspannung. Dem ESP32 reichen in dieser Phase 1.5V um die aktiven RTC-Bereiche zu versorgen.
Die aktive Phase beginn durch timergesteuertes Starten des ULP-Prozessors. Mit den ersten Befehlen wird RTC_GPIO8 nach oben gezogen, steuert T2 und T1 durch, der StepUp-Regler startet und der ESP32 incl. Peripherie wird über D3 versorgt. Den kurzen, relativ hohen Anlaufstrom soll C4 abfangen, um schwache Batterien nicht vorzeitig in die Knie zu zwingen.
Vor dem DeepSleep zieht das Hauptprogramm den Port RTC_GPIO8 wieder nach unten. Der ESP benötigt dann noch einige Millisekunden bis er sich zur Ruhe begibt. Diese Zeit überbrücken C3/R6, indem sie T1 offen halten.
Mit dabei ist wie in allen meinen Batterieschaltungen der Spannungsteiler R4/R5, über den die Batteriespannung gemessen wird.

Dieses Prinzip funktioniert bei Verwendung des ULP-Prozessors als WakeUp-Quelle. Denkbar wäre auch ein Wakeup durch exerne Quellen, wobei der Wandler einige ms vor dem SOC hochgetastet werden müsste.

boot_opt boot_opt Hier der Spannungsverlauf auf der Batterieseite (Kanal A) und am ESP32 (Kanal B). In den ersten 700ms der aktiven Phase arbeitet der ULP-Prozessor. Links ohne Stützelko / Rechts mit 1000µ.


Nachteil dieser Schaltung: Beim Einlegen schwacher Batterien startet die Schaltung nicht selbstständig, da die Spannung nur hochtastet wird, wenn der ESP32 aus dem DeepSleep kommt und die direkte Batteriespannung ggf. zu niedrig ist. Für diesen Fall ist Jumper J2 vorgesehen, mit dem der Regler kurzzeitig in den Dauerbetrieb geschaltet wird.
Bedingt durch die Wandlerverluste steigt die Leistungsaufnahme in der aktiven Phase um 30-40%.

Die Schaltung funktioniert mit Eingangsspannungen >1.5V. Batterien, die in Schaltungen ohne StepUp-Regler, nicht mehr funktionierten, laufen in dieser Variante problemlos weiter. Für Langzeitbetrachtungen ist es noch zu früh. Zwei Muster sind jetzt seit 5 Monaten in Betrieb. Die Batteriespannungen liegen nach 50.000 Messungen bei 2.45 .. 2.6V.

bme280b bme280a bme280c Klimasensor BME280: Temperatur, Luftfeuchtigkeit, Luftdruck
& Temperatur DS18B20 für Vergleichsmessung


3V Lithium Battery (CR123)

Auf jeden Fall eine Überlegung wert !

nach oben