mikrocontroller.net

Forum: Projekte & Code Projekt fertiggestellt: Temperatur- und Feuchtigkeitssensor mit ESP8266/BME280 und MQTT-Publishing


Autor: ghmartin77 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

vielleicht kann jemand was mit anfangen:
https://github.com/ghmartin77/ESP8266_BME280

Have fun
ghmartin77

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wie lange läuft der Sensor mit einer CR123A?

PS: für sowas nehme ich gleich ESP8266-12 und einen externen 
USB-Seriell-Wandler + 2 Tasten für Reset und GPIO0.

Gruß aus Berlin
Michael

Autor: ghmartin77 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

zur Lebenszeit des CR123a kann ich leider noch keine Auskunft geben. Der 
Testbetrieb läuft gerade erst seit ~1/2 Monat.
Laut Datenblatt und meinen Messwerten nuckelt sich der Chip ungefähr 
diesen Verbrauch weg:
~20uA im Deep Sleep (das wäre die meiste Zeit). 70-80mA im Betrieb ohne 
Wifi (<1 Sekunde pro Wakeup). 120mA im Betrieb mit Wifi mit sehr kurzen 
Peeks bis zu 400mA (~4-7 Sekunden pro Wakeup mit Datenversand).
Sourcen sind per Standard-Defines so konfiguriert, dass der ESP alle 5 
Minuten aufwacht und misst (<1s) sowie mind. einmal die Stunde resp. bei 
überschreiten einstellbarer Thresholds für Temperatur und 
Luftfeuchtigkeit Daten ins WiFi schickt.

Nur das ESP8266-12er-Board zu nehmen, macht's Löten (für mich als 
Hobbyist) etwas komplex. Wenn man den gemäß Herstellerangaben betreiben 
will, braucht's noch ein paar Kondensatoren und Widerstände und irgendwo 
muss der BME280 auch noch hin. Damit landet man mit entsprechendem 
Aufwand bei einem ähnlich großen Board, wie dem Wemos D1 mini.
Beispiele hier: 
https://www.mikrocontroller-elektronik.de/esp12e-tutorial-einstieg-mit-dem-esp8266-modul/

Aus dem Grunde hab ich gleich das preiswerte D1 genommen und unnötige 
Komponenten entfernt.

Wenn man wirklich noch extremer auf Stromsparen aus ist:
Es gibt ein runtergestripptes ESP-SDK, das den Startup des Chips 
drastisch verkürzt. Zur Übertragung könnte man ESPNow anstatt TCP/IP 
über WiFi nutzen, benötigt dann aber auf Empfangsseite noch ein bissel 
mehr "Magie" (e.g. angepasstes OpenWRT-ROM im WiFi-Router oder 
Zusatz-ESP). Damit kommt man dann in der Wachphase inkl. Datenversand 
auf wenige 100ms anstelle von 4-7 Sekunden. Soviel Zeit und Muße hatte 
ich aber bisher nicht... :)

Viele Grüße
ghmartin77

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Der ESP8266-12 z.B. möchte bei Batteriebetrieb gern 100µ direkt über die 
Betriebsspannung, dann ist man fertig. GPIO/Reset/RX/TX hängen bei mir 
mit kurzen Litzen an einer Buchsenleiste passend für einen FTDI-Adapter, 
Rest/Prog als Minitasten habe ich dort fest dran. Den Adapter gibt es 
nur einmal, getestet wird auch hier auf einem D1 mini oder NodeMCU, was 
gerade rumliegt. Das BME-Modul braucht 4 Drähte zum ESP und seine 
Betriebsspannung.
Ein LH1750 hängt bei mir auch noch am I2C.
Soviel Löterei ist es auch nicht unbedingt.

Versorgung ist hier ein 600mAh LiFePO4, hat aber eher 500mAh.
Die CR123A hat ca. 1000mAh, ich schätze zwischen 4 und 6 Wochen 
Laufzeit, mein Akku will nach 2-3 Wochen geladen werden.

PS: das Rastermaß eines ESP32 Wrover hat mich da gestern mehr genervt...

Gruß aus Berlin
Michael

Autor: honk (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Was soll das bitte für ein "Projekt" sein? Genau diese Kombination (ESP 
+ irgendwelche Sensoren über MQTT) gibt's hundertfach fertig im Netz. 
Und fast alle kamen sie (damals, als das noch aktuell war) zu dem 
Schluss, dass die Lösung mit Batterie und WLAN totaler Mist ist.

Autor: ghmartin77 (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Was soll das bitte für ein "Kommentar" sein? Genau diese Kombination 
(Angebot zum Code-/Arbeitsergebnisteilen
+ irgendwelche rüden Antworten) gibt's hundertfach fertig in diesem 
Forum.
Und fast alle kamen sie (damals wie heute) zu dem
Schluss, dass gegenseitiger Respekt und angemessenes Miteinander total 
wertvoll im zwischenmenschlichen Umgang sind.



Im Ernst:
Wenn's dir nicht gefällt ist das völlig ok. Und ja, die Kombi gibt's 
x-fach. Ich habe Arbeit in Aufbau und Code reingesteckt und am Ende 
läuft's für mich (bisher) zufriedenstellend und damit ist's nach meinem 
Verständnis ein Projekt. Kein Flughafen BER, aber ich sprach ja auch 
nicht von Großprojekt.
Wunder Punkt ist noch die Akkulaufzeit, bei der noch aussteht, ob sie 
akzeptabel wird und das ganze eine blöde Idee ist oder nicht...

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ghmartin77 schrieb:
> vielleicht kann jemand was mit anfangen

Vielleicht Torsten
Beitrag "Entscheidungshilfe für uC bei Gartenbewässerungsprojekt"

Autor: Michael U. (amiga)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

ghmartin77 schrieb:
> Wunder Punkt ist noch die Akkulaufzeit, bei der noch aussteht, ob sie
> akzeptabel wird und das ganze eine blöde Idee ist oder nicht...

Ob es eine blöde Idee ist hängt vom der eigenen Anwendung ab.
Konkretes beispiel: mein Sensor mit dem Akku steht hier auf dem Balkon. 
Das Sensorgehäuse ist nur zusammengesteckt, der Akku in einer 
AA-Batteriehalterung.
Wenn mir FHEM sagt, das die Akkuspannung zu niedrig wird, kostet es 
keine 3 Minuten den zu wechseln und den alten ins Ladegerät zu stecken.
Das ist real für mich kein Aufwand und damit seit Monaten nutzbar.
LiFePO4 im 18560 Format + Batteriehalter liegen hier, pasen dummerweise 
so nicht direkt in das Sensorgehäuse...
Neben dem Sensor steht mein fast 10 Jahre alter Sensor mit ATTiny45, 
RFM02. FOST02 und HP03s, der läuft mit einer CR123A mehr als 2 Jahre. 
Ich wollte eigentlich mal den LH1750 da mit reinpacken, irgendwie hatte 
ich aber nisher keine Lust, mich mit dem uralten ASM-Code 
auseinanderzusetzen, ich müßte nämlich mein damaliges Protokoll 
anpassen, da waren nur 3 Sensorwerte eingeplant... Das wäre an sich auch 
kein Problem, aber dann müßte ich entweder alle 5 Sensoren (4x nur 
Temperatur und Feuchte, 1x nur Temperatur) neu flashen und auch die 
Software der Bridge anpassen. Die Sensordaten sammelt längst ein RFM12 
an einem ESP8266 ein und macht MQTT-Messages draus.

3 China-PIR mit ESP8266 + Akku laufen hier auch, da ist die Akkulaufzeit 
irgendwo bei 3 Monaten. Die schicken bei Auslösung nur ihre Akkuspannung 
per MQTT, den Rest macht FHEM dann.

Die Frage ob man den ganzen Kram überhaupt braucht, ist doch sowieso die 
eigene Entscheidung, wirklcih brauche ich davon eigentlich garnichts...

Gruß aus Berlin
Michael

Autor: PIR-Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael U. schrieb:

> 3 China-PIR mit ESP8266 + Akku laufen hier auch, da ist die Akkulaufzeit
> irgendwo bei 3 Monaten. Die schicken bei Auslösung nur ihre Akkuspannung
> per MQTT, den Rest macht FHEM dann.

Wie viel µW schluckt denn die Schaltung beim Warten auf Bewegung?

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

PIR-Bastler schrieb:
> Michael U. schrieb:
>
>> 3 China-PIR mit ESP8266 + Akku laufen hier auch, da ist die Akkulaufzeit
>> irgendwo bei 3 Monaten. Die schicken bei Auslösung nur ihre Akkuspannung
>> per MQTT, den Rest macht FHEM dann.
>
> Wie viel µW schluckt denn die Schaltung beim Warten auf Bewegung?

Ich habe es bei den Modulen nie nachgemessen...
Der PIR ist mit > 50µA angegeben, zum ESP8266 im PwerOff mit 0,5µA 
angegeben, im DeepSleep mit 10µA. Ausgelöst werden sie relativ selten, 
5-10x pro Tag vielleicht. Haltezeit ist ca. 1:45min, in dieser Zeit also 
60µA + Verbrauch ESP bei der Meldung. Aktiv-Zeit dort ist normalerweise 
merklich unter 1s, feste IP usw.
Jetzt könnten wir ja in etwa die Energiebilanz durchrechnen. ;-)

Ich wollte gerade mal in das Diagramm der Akkuspannungen schauen, aber 
irgendwie mag mich da gerade FHEM mit den SVG-Grafiken nicht so 
richtig...
Die Laufzeiten leigen grob zwischen 6 Wochen und gut 2 Monaten. 
Allerdings hatte ich teilweise auch 400mAh Akkus drin, die tatsächliche 
Kapazität der blauen China-Akkus habe ich nie überprüft.
Die PIR sind alle in guter Reichweite, ein Kabel für externe Speisung 
hätte aber gestört und/oder Aufwand erfordert.
Ich könnte mal die Datenbank abfragen, wie oft in den Zeiträumen 
ausgelöst wurde, ist eine SQLite auf dem RasPi3. Lust habe ich aber 
keine, da jetzt rumzutippen, irgendein Wartungstool dafür zu 
installieren, fand ich schlicht überflüssig...

Gruß aus Berlin
Michael

Autor: PIR-Bastler (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Michael U. schrieb:

> Ich habe es bei den Modulen nie nachgemessen...
> Der PIR ist mit > 50µA angegeben, zum ESP8266 im PwerOff mit 0,5µA
> angegeben, im DeepSleep mit 10µA. Ausgelöst werden sie relativ selten,
> 5-10x pro Tag vielleicht. Haltezeit ist ca. 1:45min, in dieser Zeit also
> 60µA + Verbrauch ESP bei der Meldung. Aktiv-Zeit dort ist normalerweise
> merklich unter 1s, feste IP usw.

Danke für die Beschreibung!

> Jetzt könnten wir ja in etwa die Energiebilanz durchrechnen. ;-)

Lieber nicht ;-)

Umweltfreundlicher ist ein 'digitaler' PIR wie z.B. der AM312/AM612 mit 
15µA@3V wenn das System die meiste Zeit schläft und nur selten sendet.

Apropos senden:
Stört der ESP8266(oder ein Handy) dein PIR-Modul?
Die im PIR-Modul verglichenen Spannungsunterschiede sind ja recht 
gering..

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

PIR-Bastler schrieb:
> Apropos senden:
> Stört der ESP8266(oder ein Handy) dein PIR-Modul?
> Die im PIR-Modul verglichenen Spannungsunterschiede sind ja recht
> gering..

Zumindest die HC-SR501 stört einfach alles...
Beim Testen das Ding zurechtgelegt und man kann ein paar Minuten warten, 
bis er endlich auf Low geht. Deshalb letztlich auch meine gewählte 
Version: der ESP8266 ist per Enable Low von PIR aus. Wenn der PIR 
triggert startet der ESP und macht seinen Kram und geht in DeepSleep. 
Der PIR hält Enable ja für 1:45min auf High.
Re-triggern habe ich auch aus, FHEM startet einen Timer mit 2 min, der 
wird nachgetriggert, wenn noch Bewegung ist und der ESP sich eben wieder 
meldet.
Die Haltezeit kann ich so in FHEM jederzeit anpassen ohne an den 
PIR-Kram zu müssen.

Gruß aus Berlin
Michael

Autor: Dimpfelmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ghmartin77 schrieb:
> Was soll das bitte für ein "Kommentar" sein?

Im Prinzip hat "honk" recht, er hätte sich halt höflicher ausdrücken 
sollen.

ghmartin77 schrieb:
> Wunder Punkt ist noch die Akkulaufzeit, bei der noch aussteht, ob sie
> akzeptabel wird und das ganze eine blöde Idee ist oder nicht...
Irgendwie checkst du es ja selber :-(

Deinen Titel "Projekt fertiggestellt ... "
ist halt eine wenig zu hochgegriffen :-(
Jetzt nicht gleich beleidigt sein : Für mich ist das, wie Spielen mit 
dem Märklin-Baukasten. Wahrscheinlich kennst du es nicht - das war ein 
Metall Baukasten mit jeder Menge M3 Schrauben. Mit dem konnte man 
ebenfalls "große Projekte" realisieren :-)

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael U. schrieb:
> Zumindest die HC-SR501 stört einfach alles...

dazu gab es im ESPEasy Forum auch eine Diskussion. Auch bei meinen 
PIR-RFM69 Funkmodulen hatte ich diese Fehlauslösungen, mit dem 
zusätzlichen C (habe 330 nF genommen) wie in 
https://www.letscontrolit.com/forum/viewtopic.php?f=5&t=671&p=32918&hilit=pir#p13980
und einem Ferritring habe ich das ruhig bekommen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.