Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Detlev Rackow]

@OpenSourceNomad Ok, jetzt mache ich's mal ein bischen schwieriger für dich. Hard Facts mit Praxistauglichkeit :)

Wenn Du bewässern willst, ist nicht die "Voll"-Schwelle interessant. Die interessante Information ist zu wissen, wann der Boden den sogenannten "Welkpunkt" erreicht hat. Das ist das Maß an Austrocknung, bei dem die Wurzeln keine Feuchtigkeit mehr entnehmen können. Bei Sandboden ist dieser Punkt bei etwa 5% volumetrischer Feuchtigkeit erreicht. Diesen Punkt willst Du möglichst dicht erreichen, aber nicht überschreiten. Dann wird gewässert, und das Monitoring beginnt von vorne. Wie willst Du diese Schwelle bei einem Sensor bestimmen der keine verlässliche Steigung und keine bekannten Kalibrierungspunkte hat?

[OpenSourceNomad]

Nennt sich Erfahrung. Rate mal wie die letzten Tausend Jahre Landwirtschaft betrieben wurde ;)

[Detlev Rackow]

Ach so, du willst raten. Dann wirst Du mit dem Chinasensor sicher zufrieden sein. Dafür reicht er völlig.

[OpenSourceNomad]

@Detlev-Rackow said in Wemos D1 mit Batterie:

Ach so, du willst raten.

Bis jetzt wachsen und gedeihen meine Sachen prächtig. Landwirtschaft ist keine Rocket Science, vorallem nicht wenn man keine große Monokulturen züchtet. Solche Sensoren sind halt nicht mehr als nette Spielereien für den Heimgebrauch

[Detlev Rackow]

@OpenSourceNomad

Truebner SMT100, Watermark SS und andere höherwertige Sensoren werden gerade in der Landwirtschaft eingesetzt.

Man kann mit Sensoren basteln und spielen, oder damit regeln. Wenn man damit regeln will, dann braucht man eine Ablesegenauigkeit. Das bietet mir ein Truebner oder Watermark.

[Beliar_666]

Ich kapere jetzt mal dieses etwas ältere Thema, denn man muss nicht immer für etwas schon vorhandenes eine neuen Thread öffnen, denke ich.
Ich versuche auch grad eine "Wetterstation" mittels D1 mini, ein paar Sensoren per Akku und Solar zu betreiben. Der D1 wird aktuell alle 30 min. aus dem Schlaf geholt und hat dann 6 Sek. Zeit die Daten zu übermitteln. Das klappt soweit auch alles recht gut.
Kofiguration Software: ESPEasy Mega
Konfiguration Hardware: Wemos D1 mini, BME280(mehr Sensoren sollen folgen), Solarpanel 5V 400mA, 1xSony Konion5a 18650 und einen Laderegler TP 4056. Die Akkuspannung überwache ich an A0. Nun komme ich mit dem Akku auf maximal 24h bis er leer bzw. unter 3,3V fällt.

Nun sehe ich in Grafana mit jedem Datenupload einen Spannungsabfall von 0,01 bis 0,02V. Das scheint mir etwas viel, vor allem wenn ich dann lese:
@einstein67 sagte in Wemos D1 mit Batterie:

Ich hab einen WemosD1 mit einem BME280 (3,3V Typ) und als Versorgung einen 18650 Akku im Einsatz.

Bei einer Deepsleeptime von 300 Sekunden läuft das Ding ungefähr ein Monat.

Also nicht besonders gut, aber für mich ausreichend.

Ohne Deepsleep ist nach knapp 1,5 Tagen der Akku leer ...

Liegt das jetzt an dem Laderegler, das der zuviel Strom dauerhaft verbrät? In der Zuleitung vom Solarpanel hängt noch eine Diode zum Rückflussschutz.

Bei 30 min Deepsleep sollte der Akku doch eigentlich wesentlich länger halten, oder nicht?

[klassisch]

@beliar_666 Meine Meinung: Wifi und Batterie passen nicht zusammen.
Wifi und Netz geht gut. Schau Dir mal die Shelly-Produkte an. Die ganzen netzbetriebenen Geräten sind super. Das ganze batteriebetriebene Zeug ist meiner Meinung nach nicht konkurrenzfähig. Da machen die mit einem riesen Aufwand und allerneuester Technik einen teurenBewegungsmelder, der sich im Vergleich mit einem viel billigeren aqara Zigbee Bewegungsmelder nicht sehen lassen kann. Nicht mal im Vergliech zu einem billigen 433MHz Teil mit uralt-Technik. Braucht man nur, wenn man keinen ioBroker hat und im Shelly Universum bleiben will.
Mit viel Programmieren geht wohl was. Im HM-Forum hat der user fsommer1968 einen T-/H- Sensor gebaut, der mit einer 18650 irgendwas zwischen einem halben Jahr und einem Jahr arbeitet.

[JLeg]

@beliar_666 sagte in Wemos D1 mit Batterie:

Bei 30 min Deepsleep sollte der Akku doch eigentlich wesentlich länger halten, oder nicht?

schonmal geprüft, ob der D1 tatsächlich in den Deepsleep geht? Sieht imo nicht so aus... (am besten in den Pausen mal anpingen - dürfte nicht gehen...)

[Beliar_666]

@jleg
Also der ist nicht erreichbar in den Schlafzeiten, weder das Webinterface noch per Ping. Der schläft definitiv in der Zeit.
Ich befürchte es liegt tatsächlich am Lademodul. Ich muss das mal nur mit Akku testen, wie lange es dann hält.

@klassisch Das Wifi und Batterie generell eine schlechtere Möglichkeit sind ist hinlänglich bekannt. Das ist aber hier nicht das Thema. Und Wifisensoren haben auch nichts damit zu tun ob man IoBroker hat oder nicht. Da wo mein Sensor hin kommt habe ich keine Zigbeeabdeckung, aber eben ein WLan Signal. Und nein auch 433Mhz kommt nicht in Frage, da würde ich mir eher noch mit LoRa etwas basteln, das ist zwar teurer, aber dafür ist die Reichweite anständig. Und Batteriehungrig ist LoRa auch nicht.
Aber hier geht es um einen Wemos D1 und WLan, und darum wie man die Akkudauer verlängern kann. Denn 24h sind definitiv weit weniger als eben möglich.

[disaster123]

Hallo,

ist denn der Wemos D1 die beste Wahl oder lieber NodeMCU? Ich würde den gerne mit einer oder zwei cr123a Batterien betreiben und einem Ultraschall Sensor. Statt wifi würde ich gerne zigbee oder zwave verwenden um Strom zu sparen. Geht das? Es reicht mir wenn er alle 12 Stunden aufwacht.

[OpenSourceNomad]

@klassisch said in Wemos D1 mit Batterie:

Meine Meinung: Wifi und Batterie passen nicht zusammen.

@beliar_666 said in Wemos D1 mit Batterie:

Das Wifi und Batterie generell eine schlechtere Möglichkeit sind ist hinlänglich bekannt.

@disaster123 said in Wemos D1 mit Batterie:

Statt wifi würde ich gerne

Vielleicht (oder wahrscheinlich) ist es nicht allen bekannt aber die wlan hardware des esp lässt sich nicht nur für ein (energiehungriges) klassisches AP wlan verwenden.

Interessant ist das vor allem weil es mit "esp-now" eine Möglichkeit gibt ad-hoc und mit minimalen Energieaufwand zu kommunizieren.

Und um mal eine Hausnummer zu haben was es für einen Unterschied machen kann:

• esp-now:
  aufwachen, sensor auslesen, Sensordaten via esp-now senden und schlafen gehen
  Gesamt: <500ms

• AP wlan (wpa2, dhcp)
  aufwachen, sensor auslesen, wifi ap suchen, wifi ap verbinden (handshake etc.), dhcp request, ip assignment, Sensordaten an mqtt broker senden und schlafen gehen
  Gesamt typischerweise nicht unter 3 Sekunden zu schafen (braucht aber gerne auch mal 5 oder 8 Sekunden).

Sprich es ist Möglich den Stromverbrauch im einem wake cycle um mindestens Faktor 5, wenn nicht gar Faktor 10 oder mehr zu mindern :warning:

Riesen Vorteil von diesem Verfahren ist natürlich das es rein software basierend ist und keinerlei zusätzliche Hardware gebraucht wird.

Für esphome gibt es dazu einen funktionierenden PR (docs dazu hier).

Und hier noch ein Video zum Thema:

• An Efficient WiFi Button For Home Automation Using ESP-NOW | ~68 Years From 2xAA Batteries

[Beliar_666]

@opensourcenomad sagte in Wemos D1 mit Batterie:

AP wlan (wpa2, dhcp)
aufwachen, sensor auslesen, wifi ap suchen, wifi ap verbinden (handshake etc.), dhcp request, ip assignment, Sensordaten an mqtt broker senden und schlafen gehen
Gesamt typischerweise nicht unter 3 Sekunden zu schafen (braucht aber gerne auch mal 5 oder 8 Sekunden).

Das ganze verringert sich aber relativ stark wenn man eine Feste IP vergibt. Hinzu kommt auch noch die Geschichte mit dem Fast Connect. Ich habe im Moment eine Waketime von 2 Sekunden, klar ist das noch weit mehr als 500ms, ich woillte lediglich sagen, das man auch beim AP Wlan noch einiges sparen kann im Gegensatz zu deiner Aussage. Das mit ESP-now muss ich mir mal anschauen. Obleich ich jetzt schon eher zu TiNo im 866MHz bereich tendiere. Allein die Grösse der Platine und die Verwendung einer Knopfzelle macht TiNo interessanter.

[klassisch]

Wenn ich mich recht erinnere was ESP-now eine Verbindung von ESPs untereinander und nicht direkt zum WLAN.

[OpenSourceNomad]

@beliar_666 said in Wemos D1 mit Batterie:

Ich habe im Moment eine Waketime von 2 Sekunden, klar ist das noch weit mehr als 500ms,

Zwei Sekunden sind ja schon ganz nett. Aber eben immer noch Faktor 4 mehr als die maximal zu erwartenden 500ms mit esp-now (das setup im verlinkte Video kommt übrigens mit 280ms aus). Größter (und nicht optimierbarer) overhead bei AP wlan bleiben die Verschlüsselung sowie der TCP/IP stack.

Es kann eben den kleinen aber feinen Unterschied (50-75% niederiger Verbrauch) machen einen komplett autarken node zu betreiben (esp, kleines Solarpanel + Batterie):sunny::battery:. Ggf. kann man auch einfach die Batterie kleiner bemessen oder ein alte schon schwächelnde aus den letzten 10 Handygenerationen die in der Schublade alt werden verwenden. Da ist dann nicht nur was gespart sondern auch vor allem auch Müll vermieden :do_not_litter:.

Netter Nebeneffekt ist übrigens die Reichweite von esp-now. In meinen Test hatte ich nach über 300 Meter Entfernung noch Empfang (mein AP wlan hatte sich da schon längst verabschiedet).

[OpenSourceNomad]

@klassisch esp-now ist nicht zwangsläufig auf esp's limitiert (siehe z.B. linux-espnow).
Außerdem ist es auch möglich einen vorhanden esp (welcher dauerbestromt wird) zusätzlich als esp-now receiver zu nutzen um alles in's heimische WLAN zu bridgen.

[klassisch]

@opensourcenomad Ja, braucht halt ein Gateway - ESP.
Mal was anderes: Hast Du schon Dutchmans ESPHome Adapter getestet?

[OpenSourceNomad]

@klassisch said in Wemos D1 mit Batterie:

@opensourcenomad Ja, braucht halt ein Gateway - ESP.

Wie gesagt reicht ein esp der bereits installiert ist und sowieso schon etwas anderes macht. Es braucht eben keinen extra/eigenen esp nur um als Gateway zu fungieren.

@klassisch said in Wemos D1 mit Batterie:

Mal was anderes: Hast Du schon Dutchmans ESPHome Adapter getestet?

Nope, dafür bräuchte ich wohl erst mal iobroker :joy:

[klassisch]

@opensourcenomad sagte in Wemos D1 mit Batterie:

Nope, dafür bräuchte ich wohl erst mal iobroker :joy:

Na dann wird es höchste Zeit ....

[OpenSourceNomad]

@klassisch said in Wemos D1 mit Batterie:

Na dann wird es höchste Zeit ....

glaube dafür bin ich jetzt schon zu verwöhnt ;)

[disaster123]

@opensourcenomad Nachteil bleibt aber die geringe Reichweite oder? Bei zigbee kann man ja locker 100m Brücken