Hallo, ich würde gerne von diversen Pflanzen den Feuchtigkeitsgehalt der Erde messen und diesen per WLAN weiter melden. Mit diesen Daten könnten dann Alarme oder Steuerungen aktiviert werden. Aber zuerst geht es nur um die Feuchtigkeitsmessung - vermutlich mit kapazitivem Sensor - und der Datenweiterleitung übr WLAN mittels ESP8266 oder ESP32. Hauptaugenmerk soll auf einer möglichst langen Batterielaufzeit liegen. Bestenfalls soll eine kleine Batterie für min. ein Jahr ausreichen. Natürlich kann man das durch die Länge und Anzahl der Messvorgänge beeinflussen. Daher reduzieren wir das am Besten auf einen Messvorgang, um das zu vereinfachen. Wäre es Stromsparender, die gesamte Arbeit (Messung und WLAN-Versand) durch einen ESP8266 oder ESP32 zu erledigen? Oder sollte man das auf einen ATmega + ESPxxxx aufteilen? Ggf. auch Etwas anderes als einen ATmega? Stand Jemand schon mal vor dem gleichen Problem und kann dazu Hinweise geben, wie es gemacht werden sollte, wenn die Schaltung möglichst wenig mA verbrauchen soll? Grüße Artur
Löse Dich von dem Bastelkrams! 1. WLAN und Stromparen geht nicht. Ein Jahr mit einer Batterie und WLAN ist illusorisch. Es sei denn, Du nimmst eine fette Laternenbatterie. Wenn Du Strom sparen willst, nimmst Du IEEE 802.15.4 bzw etwas darauf aufsetzendes wie Zigbee, Thread, 6LowPan etc. Damit kommt das Jahr in Reichweite. Das ist auch die Technologie, die z.B. bei den Philips Hue und anderen Lampen verwendet wird. 2. AVR ist nicht die ideale Plattform, wenn es um Stromsparen geht. Das ist alte 5V-Technik. Du willst mit der Betriebsspannung möchlichst weit herunter, weil diese quadratisch in die Verlustleistung eingeht. Heißt: Halbe Spannung -> viertel Leistung. Ja, ich weiß, es gibt auch einige AVRs, die das auch können. Andere können das aber besser. 3. Die ganzen IEEE 802.15.4 Chips haben einen frei programmierbaren Applikationsprozessor, so dass ein extra Prozessor unnötig und kontraproduktiv ist. Meine Vorschläge: 1. TI mit der CC25** oder CC26** Serie. 2. SiLabs, z.B. sowas hier https://www.silabs.com/documents/public/data-sheets/mgm13s-datasheet.pdf 3. NordicSemi https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52840 Da siehst Du, dass die Leute nicht mit mA, sondern auch mit µA rechnen. Ja, ich weiß, ist alles Neuland für Dich, aber da musst Du halt durch. fchk
:
Bearbeitet durch User
Nimm doch als Grundlage einen emonTH, und da einfach den Feuchtigkeitssensor dran. Auf der anderen Seite einen Raspberry mit einem RaspyRFM Modul oder einen USB Stick mit RFM69.
Frank K. schrieb: > 2. AVR ist nicht die ideale Plattform, wenn es um Stromsparen geht. Das > ist alte 5V-Technik. Theorie und Praxis: Ein AT328 @ 5 Volt Arduino *) geht im Schlafmodus auf wenige µA herunter. Wenn das Ding 10µA nimmt, sind das knapp 90 mAh pro Jahr, die tun nicht weh. Natürlich kann mit anderen Controllern weniger erreicht werden, das Ideal bringt aber nichts ein, weil die Selbstentladung der Versorgung höher liegt. *) http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/ > WLAN und Stromparen geht nicht. Das ist wirklich eine Rechenaufgabe, weil der Aufbau der Verbindung aus dem Schlaf heraus deutlich länger dauert als die eigentliche Datenübertragung.
Manfred schrieb: > Wenn das Ding 10µA nimmt, sind das knapp 90 mAh > pro Jahr, die tun nicht weh. Ich meine, dass die Stromaufnahme tatsächlich sogar nur um 1µA sei. Wohingegen ESP8266 und ESP32 mehr als 10µA (viele haben um 25µA gemessen) aufnimmt. Dann sollte man noch bedenken, dass es ESP8266 nur einen ADC Eingang hat. Ich würde einen AVR Mikrocontroller verwenden (der hat viele analoge Eingänge) und daran einen ESP8266 mit AT-Firmware, der in den Pausen ganz Stromlos geschaltet wird. Der AVR hängt direkt an der Batterie, der ESP8266 bekommen einen Spannungsregler, welcher vom AVR ein/aus geschaltet wird.
Hiermit bist du sofort fertig (BT) https://www.mobilegeeks.de/test/xiaomi-flower-care-smart-sensor-im-test-gruener-daumen-dank-technik/
Was du auch bedenken solltest: Die ESP Chips brauchen zum Aufwachen sehr viel länger, als ein einfacher AVR (egal ob mit oder ohne WLAN), und verbrauchen dabei entsprechend viel Strom. Das Aufwach-Intervall ist beim ESP8266 maximal 70 Minuten.
Es müssen, wahrscheinlich, doch auch nicht jede Stunde die Messwerte übermittelt werden. Einmal am Tag und wenn Schwelle unter oder überschritten wurde könnte doch reichen und spart massig Energie ein. Viel größere sorgen würde mir die Langzeitstabilität des Sensors im Boden machen. Ist aber auch nur so ein Gefühl, keine Erfahrung. Viel Erfolg mit dem Projekt
Frank K. schrieb: > 2. AVR ist nicht die ideale Plattform, wenn es um Stromsparen geht. Das > ist alte 5V-Technik. Du willst mit der Betriebsspannung möchlichst weit > herunter, weil diese quadratisch in die Verlustleistung eingeht. Du vergisst die Taktfrequenz als ganz entscheidenden Hebel für die Stromaufnahme und die geht linear ein. Was meinst du mit "5V-Technik", wenn der AVR z.B. mit 2V läuft?
Wolfgang schrieb: > Frank K. schrieb: >> 2. AVR ist nicht die ideale Plattform, wenn es um Stromsparen geht. Das >> ist alte 5V-Technik. Du willst mit der Betriebsspannung möchlichst weit >> herunter, weil diese quadratisch in die Verlustleistung eingeht. > > Du vergisst die Taktfrequenz als ganz entscheidenden Hebel für die > Stromaufnahme und die geht linear ein. Sicher. Ein höherer Takt heißt aber auch, dass der Prozessor Beim Erledigen einer definierten Aufgabe schneller seinen Ruhezustand erreicht. Die korrekte Antwort heißt "Wie viel mJ braucht eine bestimmte Aufgabe?" Dazu gibt es zahlreiche Papers, z.B.: https://www.silabs.com/documents/public/application-notes/an0027.pdf Viele EnergyMicro (jetzt SiLabs) Boards haben Hardware zur Verbrauchsmessung mit drauf. Damit kann man schon einiges an Erkenntnissen selber gewinnen. Und genau deswegen wäre das für die aktuelle Fragestellung eine geeignetere Plattform. > Was meinst du mit "5V-Technik", wenn der AVR z.B. mit 2V läuft? Den Halbleiterprozess. Wobei auch das ein komplexes Thema ist. Viele Leute hier verteidigen den AVR, weil sie einfach nichts anderes kennen. Sicher kommt man damit auch recht weit - keine Frage. Für Profis wie meinereiner (ich mach Elektronik- und Embedded Software Entwicklung seit 35 Jahren und seit 25 Jahren im Hauptberuf) ist diese Architektur aber inzwischen uninteressant, weil es besseres gibt. Und auch für die Problemstellung des Fragestellers gibt es geeigneteres, insbesondere bessere Funktechnik. Muss ihm halt nur mal jemand sagen. fchk
flowerpower schrieb: > Hiermit bist du sofort fertig (BT) > > https://www.mobilegeeks.de/test/xiaomi-flower-care-smart-sensor-im-test-gruener-daumen-dank-technik/ Und schon bist du abhängig von irgendeiner China-Cloud. Wenn du das Cerät nicht befreien kannst würd ich es nicht kaufen.
Was man versuchen könnte wäre ein ESP32 im Deepsleep der nur den ULP Prozessor laufen hat. Der verbraucht recht wenig Strom und kann den ADC sowie 8 KB Ram nutzen. Wenn der voll ist kann man ja das WiFi aufwecken und die Daten gebündelt senden. Hab hier ein paar Zahlen dazu gefunden: https://www.elektronikpraxis.vogel.de/ultra-low-power-management-des-esp32-fuer-wifi-iot-module-nutzen-a-738971/ Hauptvorteil: Sehr günstig und WiFi. PS: Dieses ESP32 Board hat alles nötige (ldo + battery managment) drauf und behauptet was von 20 uA: https://www.crowdsupply.com/unexpected-maker/tinypico#details-top
Thomas schrieb: > und behauptet was von 20 uA Ich würde es nachmessen. Denn beim Punkt Stromaufnahme hat Espressif jahrelang gelogen, dann später extrem beschönigt (alle Angaben im DB des ESP8266 beziehen sich auf 3,3V 25°C, aber den minimalen (nicht maximalen) Ruhestrom geben sie für dazu optimal passende Extrem-Bedingungen an). Seriöse Hersteller geben den maximalen Ruhestrom unter normalen Bedingungen an - nur so nebenbei bemerkt. Dazu kommt, dass die Hersteller/Händler von Modulen die kleinsten Zahlen (aus dem ältesten preliminary draft Datenblatt) für den nackten Chip einfach für ihr ganzes Board übernommen haben. Als ob die Bauteile um den Chip herum keine Ruhestromaufnahme hätten. Nun geht es hier nicht um den ESP8266 sondern um den ESP32, den es im übrigens in vielen Varianten gibt. Aber ich erwarte nicht, dass diese Welt plötzlich ehrlich geworden ist.
Ich denke schon dass man dem Hersteller von diesem TinyPico glauben kann dass er den Stromverbrauch richtig gemessen hat. Aber selber messen muss man sowieso...
Kolja L. schrieb: > Viel größere sorgen würde mir die Langzeitstabilität des Sensors im > Boden machen. Das! Ich würde erstmal versuchen überhaupt einen zuverlässigen Feuchtesensor zu bauen bzw zu ermitteln wie so etwas überhaupt beschaffen sein muß damit er zuverlässig funktioniert (Hint: das kapazitive Gedöns das den Leuten immer als erstes durch den Kopf schwirrt hat noch nie bei irgendwem zuverlässig über längeren Zeitraum funktioniert), dann erst wenn dieses Problem gelöst ist würde ich anfangen zu planen wie man das ganze Gebilde dann mit Batterie und Funk ausstatten kann.
Angehängte Dateien:
-
20190215_152130.jpg
210 KB -
20190215_152900.jpg
220 KB -
Screenshot_2019-09-07-12-42-08.png
340 KB
Frank K. schrieb: > WLAN und Stromparen geht nicht. Unter bestimmten Voraussetzungen geht es sehr wohl. Senden nur dann, wenn sich die Daten ändern (außer der stündlich Alivemeldung mit Batteriestatus, hier kann auch der Messwert mit übertragen werden). Stromsparender Co Mikrokontroller, der den ESP 8266 an und weg schaltet und die Messungen durchführt. In meinen Fall ein MSP430G2553. Die Sensoren sind seit März in Betrieb und habe seit dieser Zeit über je 5600 IP/UDP Telegramme (Beispiel siehe Screenshot) versendet. Die Batteriespannung liegt noch bei 3383mV. Zwei Lithiumprimärzellen LS14500 mit je 2600mAh bei 3,6V Ich habe 10 Sensoren im Dauereinsatz. Ich gespannt wie lange die Batterien noch durchhalten.
Wenn man Energie sparen will, muss man einfach nur abschalten! Klingt etwas komisch ist aber so. Also genau überlegen, ab man Messwerte im µS-Bereich braucht, oder ob es reicht alle 1/4 Stunde nachzusehen. Es gibt mittlerweile einen Low-Energy Funker, der zwar ursprünglich für geringe Datenvolumen gedacht ist, aber auf einen gelegentlichen Feuchtewert, trifft das wohl zu. Grundsätzlich ist alles, was auch nur im Entferntesten mit Funk zu tun hat, energiehungrig. Lass alles, was sich Anzeige schimpft außen vor. Bist Du mehr der Augenmensch, so spendiere Deinem Design wenigstens einen "Guck-Taster", der eine Unterbrechung auslöst und einen Zeiter, der dem Jammer möglichst bald ein Ende bereitet. Schon im Design darauf achten, dass man bei allem, was da ist, den Stecker ziehen kann. Gibt es keinen effektiven Disable, so muss halt ein FET einspringen, der den Saft abdreht. Eine CPU mit sleep modes, die auch den Namen verdienen, nutzen. Letzere auch sinnvoll implementieren. Hier ist das Problem dass man oft Fehler, in diesem Bereich, nicht bemerkt. "Es geht ja" - wenn nur die Batterie länger halten würde. In diesem Zusammenhang werden auch gerne die Zieh-Hochs vergessen und die Ein-/Ausgänge, die (gerade) nicht gebraucht werden. Also wie im ersten Satz gesagt: Abschalten was geht und nicht versuchen irgendwelche Geschwindigkeitsrekorde zu brechen.
:
Bearbeitet durch User
Sebastian S. schrieb: > Grundsätzlich ist alles, was auch nur im Entferntesten mit Funk zu tun > hat, energiehungrig. Grundsätzlich ist hauptsächlich der Empfang energiehungrig. Der Sender kann meist ausgeschaltet sein und einen Empfänger braucht man für viele Dinge nicht. WLAN ist da etwas großzügig mit bidirektionaler Kommunikation, alleine schon durch den Protokolloverhead. Was spricht gegen einfachere Sender, die z.B. per MQTT-SN die Daten über einen zentralen Gateway ins WLAN schicken?
Bernd K. schrieb: > Ich würde erstmal versuchen überhaupt einen zuverlässigen Feuchtesensor > zu bauen bzw zu ermitteln wie so etwas überhaupt beschaffen sein muß > damit er zuverlässig funktioniert Das Thema wurde doch schon öfter diskutiert, z.B. Druckmessung per Tensiometer Beitrag "Re: Schaltplankontrolle - Tomatenbewässerung"
Wolfgang schrieb: > Bernd K. schrieb: >> Ich würde erstmal versuchen überhaupt einen zuverlässigen Feuchtesensor >> zu bauen bzw zu ermitteln wie so etwas überhaupt beschaffen sein muß >> damit er zuverlässig funktioniert > > Das Thema wurde doch schon öfter diskutiert, z.B. Druckmessung per > Tensiometer > Beitrag "Re: Schaltplankontrolle - Tomatenbewässerung" Korrekt. Ich wollte mit dem Zaunpfahl genau in diese Richtung winken.
Wolfgang schrieb: > Grundsätzlich ist hauptsächlich der Empfang energiehungrig. Daher ist es wichtig Aktoren und Sensoren zu trennen! Bei Sensoren, z.B. Einbruchs.- und Klimasensoren, wird nur gesendet wenn sich etwas ändert. Empfangen wird nur unmittelbar nach dem Senden um die Empfangsbestätigung abzuwarten und auszuwerten um gegebenenfalls mit einer Wiederholung der nicht quittierten Meldung zu reagieren. Der TxRx Modul ist die meiste Zeit inaktiv. Anders das Gegenüber, welches immer empfangsbereiten sein muss. Reine Sensormodule lassen sich leicht mit Batterien betreiben. Das Gegenüber, z.B. ein Raspberry, hängt meisten an der Netzversorgung und ist meist für mehrere Sensoren zuständig. Anders sieht es mit Aktoren, z.B. Sirenen und Netzversorgungszwischensteckern aus. Hier müssen die Empfänger ständig aktiv sein. Aber hier brauchen die anzusteuernden Komponenten ebenfalls viel Strom, müssen aber meist nicht mit Batterien betrieben werden. Sebastian S. schrieb: > Eine CPU mit sleep modes, die auch den Namen verdienen, nutzen. Letzere > auch sinnvoll implementieren. Hier ist das Problem dass man oft Fehler, > in diesem Bereich, nicht bemerkt. "Es geht ja" - wenn nur die Batterie > länger halten würde. Daher ist es wichtig, dass der MC nicht nur im Sleep Modus sehr sparsam ist, sondern auch im Betrieb um Überwachungsfunktioen durchführen zu können. Der MC lässt sich meist über die Sensoren, wie z.B. Reedkontakte und Bewegungssensoren, mittels Interrupt aus dem Schlaf holen. Sebastian S. schrieb: > In diesem Zusammenhang werden auch gerne die Zieh-Hochs vergessen und > die Ein-/Ausgänge, die (gerade) nicht gebraucht werden. Das ist ein sehr wichtiger Punkt beim Energisparen. Die internen Pullups des MSP430G haben etwa 47k Ohm, können aber nicht weggeschaltet werden, sonst könnte der MC nicht jederzeit aufgeweckt werden oder es sind, im Ruhezustand, geschlossene Reedkontakte im Spiel. Hier hilft es nur die internen Pullups abzuschalten und externe Pullups mit z.B. 1M Ohm zu verwenden sonst würden alleine die Pullups mehr Strom als der schlafende MC benötigen. Da diese Signale nicht sehr schnell sein müssen, kann mit einem Kondensator ein Tiefpass geschaltet werden. Aber Achtung ein kleiner Widerstand in Serie zum Kontakt verhindert eine kurzschlussartige Entladung dieses Kondensators beim Schließen des Reedkontaktes. Der Kontakt wird es mit höherer Lebensdauer danke.
Wolfgang schrieb: > Grundsätzlich ist hauptsächlich der Empfang energiehungrig. Nur bei völlig "dummen" Protokollen. Eigentlich gemeint ist: bei Protokollen, bei deren Entwurf diese Problematik nicht berücksichtigt wurde. Allerdings: die cleveren Protokolle erfordern wiederum, dass der "Empfänger" auch senden kann und zusätzliche, dass er eine halbwegs zuverlässige Zeitbasis besitzt, die leider energetisch auch nicht für lau zu bekommen ist. Ist aber immer noch sehr viel billiger als "Dauerlauschen". Schon Module wie der RFM12 haben vor vielen Jahren diese Anforderungen erfüllt...
Thomas schrieb: > https://www.mobilegeeks.de/test/xiaomi-flower-care-smart-sensor-im-test-gruener-daumen-dank-technik/ > > Und schon bist du abhängig von irgendeiner China-Cloud. Wenn du das > Cerät nicht befreien kannst würd ich es nicht kaufen. Die Dinger verwenden BLE und wie man ohne App die Dinger auslesen kann wurde auch schon analysiert. Hab das hier zum Testen mit einem ESP32 Board am laufen. Das kann dann per BLE die Sensoren abfragen und die Ergebnisse per WLAN weiter senden. https://github.com/sidddy/flora
temp schrieb: > Die Dinger verwenden BLE und wie man ohne App die Dinger auslesen kann > wurde auch schon analysiert. Hab das hier zum Testen mit einem ESP32 > Board am laufen. Das kann dann per BLE die Sensoren abfragen und die > Ergebnisse per WLAN weiter senden. > https://github.com/sidddy/flora Unter den Umständen klingen die Teile dann natürlich Top!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.