Links zu ebay oder Amazon sind Werbelinks. Wenn Sie auf der Zielseite etwas kaufen, bekommen wir vom betreffenden Anbieter Provision. Es entstehen für Sie keine Nachteile beim Kauf oder Preis.
Auf den Vorschlag in einem anderen Thread hin, habe ich mal was hierhin kopiert. Für alle Bastler soll es um die Technik gehen. Für Anwendungen haben wir z.B. auch --> Link oder --> Link.
Solarcomputer hat geschrieben:Speziell der ESP32 benötigt recht viel Strom (durch seine 2 CPU Kerne), dieser liegt bei ca 100 mA. Das Powermangement zusammen mit WLAN oder Bluetooth ist sehr komplex und meist unzureichend in der Praxis umzusetzen.
Elmi79 hat geschrieben:So, ich habe mal nachgemessen: bei aktiviertem WLAN zieht der ESP32 knapp 50 mA, wenn eine Verbindung hergestellt ist oder Daten gesendet werden, macht das keinen Unterschied. Wenn WLAN aus ist, liegt der Verbrauch bei etwa 20 mA, das alles ohne dass der Code bisher großartig auf Energiesparen optimiert wäre.
Mit Light Sleep kommt man noch einiges runter ohne das RAM zu verlieren.
Wirklich dubios: im Deep-Sleep-Modus gehen noch knapp 10 mA in den ESP32 rein, das ist definitiv zu viel und wird aktuell noch untersucht.
Das sollte viel weniger sein. Beim ESP32 muß ich es noch testen. Einen ESP8266 (D1mini) habe ich gerade in Arbeit. Der geht beim DeepSleep auf 0,22mA runter. Selbst mit einem DHT12 und dem onboard USB Chip. Das hat mich überrascht.
Das Problem für Batteriegeräte ist aber, daß das WLAN bei mir 4sek braucht, um eine Verbindung aufzubauen und ein mqtt Publish abzusetzen. Da in der Zeit der hohe Strom fließt, ist das für Batteriegeräte nicht sinnvoll. Für Geräte an der Womobatterie ist es (mit Solar) kein Problem.
So, dann darf ich meine Lösung mal vorstellen. Benötigt wird lediglich ein ESP32 (im Schaltplan nicht mit dargestellt) mit ein wenig Zusatzbeschaltung:
Links oben ist der zu überwachende Akku eingezeichnet. Dessen aktuelle Spannung wird über einen Spannungsteiler (R2 mit 20 kOhm) auf den VN-Eingang des ESP32 gelegt. Achtung: vor Inbetriebnahme den Trimmer ganz nach unten auf GND drehen und erst bei vollem Akku langsam nach oben regeln; wenn an ESP_VN 2,9 V anliegen, ist die Einstellung perfekt. Dreht man zu schnell hoch oder fängt man in einer zu hohen Stellung von R2 an, kann das schnell das Ende des ESP32 sein, da der am VN-Eingang maximal 3.3V verträgt.
Die Akkuspannung wird anschließend über einen Spannungsregler auf die Versorgungsspannung von 3.3V für den ESP32 heruntergeregelt. Hier habe ich eine Lösung mit integriertem Laderegler für einen LiIon-Akku gewählt, damit der ESP32 auch dann noch eine Zeit lang Daten aufzeichnet, wenn der überwachte Akku komplett leer ist. Nachteil dieses Pufferakkus: der von mir verwendete Laderegler ist gleichzeitig auch die Ursache für eine relativ hohe Grundlast von 10mA, selbst wenn der ESP32 im Tiefschlafmodus ist. Der Strom wird wohl für die Spannungsregelung und Ladeerhaltung des Pufferakkus verwendet.
Unten im Schaltplan findet sich noch ein DHT22 Temperatursensor, der an Masse, Spannung und den D13-Eingang des ESP32 angeschlossen wird. Für nur wenige Euro Mehrkosten liefert dieser die aktuelle Spannung und Luftfeuchtigkeit am Einbauort der Überwachungselektronik. Zusammen mit der unten noch beschriebenen Aufzeichnungsfunktion bietet dieser interessante Einblicke in das Klima im Wohnwagen.
Gleich daneben findet sich noch das optionale OLED-Display. Hier wird ein Display auf Basis des SSD1309-Controllers erwartet, welcher per I2C angesprochen wird und im Netz problemlos günstig zu bekommen ist. Wichtig: es ist darauf zu achten, dass dieser mit 3.3V läuft, einige Varianten benötigen 5V und würden damit eine zusätzliche Spannungsversorgung erfordern. Verbunden werden hier neben Spannung und Masse noch SDA vom Display mit D21 am ESP32 und SCL mit D22.
Der mit dem ESP32-Pin D34 verbundene Taster S1 bietet Zugriff auf verschiedene Funktionen: - ist der ESP32 ausgeschaltet (Deep Sleep), so wird er mit Druck auf S1 gestartet - ist das WLAN an, so wird es mit Betätigung des Tasters ausgeschaltet - ist das WLAN aus, so kann es hiermit eingeschaltet werden - sind Display und WLAN ausgeschaltet, so können Sie hierüber eingeschaltet werden Wie sich Display und ESP32 ausschalten lassen, wird unten im Abschnitt über die Software beschrieben. Abhängig vom verwendeten Board kann es nötig sein, den 10k-Ohm Pull-Down-Widerstand R1 einzubauen.
Die LED1 am ESP32-Ausgang D4 ist optional, mir dient sie dazu, zu signalisieren, ob WLAN eingeschaltet ist oder nicht. Ob diese Anzeige wirklich nötig ist, wird die Praxis zeigen. Das Stromsparpotenzial ist mit knapp 4 mA aber eher gering, gleichzeitig verlöre man aber eine einfache Kontrollmöglichkeit, die schnell auskunft über den Zustand des Controllers gibt (z.B. ob dieser überhaupt gestartet ist).
Für die Software suche ich mir aktuell noch einen geeigneten Ablageort, ich werde diesen hier bekannt geben, so bald ich was passendes gefunden habe.
Grundsätzlich startet die Software mit aktiviertem WLAN und Display. Funkt der Anwender nicht dazwischen wird das Display nach knapp einer Woche automatisch ausgeschaltet, das WLAN folgt nach einigen Tagen. So wird sichergestellt, dass beide nicht endlos Strom ziehen, wenn der Wohnwagen am Ende des Urlaubs abgestellt wird und man vergessen hat, beide zu deaktivieren.
Die aktuelle Akkuspannung (und damit der Ladestand), Luftfeuchte und Temperatur werden etwa alle 30 Sekunden automatisch gemessen und akkumuliert. Der sich ergebende Durchschnittswert wird alle fünf Minuten fest im integrierten Flash gespeichert. Hier kommt das SPIFFS zum Einsatz, ein für Flash-Operationen optimiertes Dateisystem, welches mit einem cleveren Schreibmechanismus Wert auf eine lange Flash-Lebensdauer legt.
Verbindet man sich auf das WLAN des ESP32, so kann man diese Daten mittels eines ganz gewöhnlichen Webbrowsers unter der Adresse
abrufen. Angezeigt werden die aktuellen Werte für Akku (in %), Temperatur (in Grad Celsius), Luftfeuchte (in %) sowie die Dauer, die der Controller bereits am Stück läuft. Zusätzlich werden die gespeicherten Daten noch in Form dreier Graphen angezeigt: jeweils für einen Zeitraum von ein paar Tagen, den letzten Monaten sowie den letzten 2,5 Jahren. Selbstverständlich gehen diese Daten nicht verloren, wenn die Spannung komplett ausfällt. Allerdings ist dieser Ausfall in der Aufzeichnung auch nicht zu erkennen, da keine Echtzeituhr vorhanden ist (deswegen auch der zusätzliche Pufferakku in meinem Aufbau, damit kann ich dann wenigstens eindeutig erkennen, wenn der überwachte Akku mal komplett leer geworden ist).
Oben bei der Anzeige der aktuellen Daten gibt es auch noch die Möglichkeit, den Controller direkt zu beeinflussen. Das geschieht über die dort angebotenen Links: - "WLAN aus" - schaltet das WLAN aus, Einschalten ist anschließend nur noch über den Taster S1 möglich - "Display ein "/"Display aus" - schaltet das optionale OLED-Display ein oder aus, sind sowohl WLAN als auch Display aus, so können beide auch über den Taster S1 eingeschaltet werden - "ESP32 aus" - schickt den Controller für ein Jahr in den Tiefschlaf, in diesem Zustand wird nur noch minimal wenig Strom verbraucht, es werden aber auch keine Daten mehr aufgezeichnet; starten Lässt sich der ESP32 dann wieder über den Taster S1. Der "Deep Sleep"-Modus wir hier verwendet, da es eigentlich keine Ausschaltfunktion gibt. In diesem Zustand benötigt der ESP32 aber so wenig Strom, dass ein 30Ah-Moverakku auch nach 6 Jahren noch nicht leer wäre.
Ist das Display eingeschaltet, so zeigt dieses den aktuellen Akkuladestand in % sowie die Temperatur am DHT22-Sensor an. Zwei rückwärts laufende Fortschrittsbalken am oberen Displayrand geben Auskunft darüber, wie lange es noch dauert, bis Display und WLAN automatisch ausgeschaltet werden. Ein kleines WiFi-Symbol zeigt an, ob WLAN aktuell eingeschaltet ist.
Am ESP32 selber sind noch jede Menge Pins frei, die sich für allerlei nützliches verwenden lassen. So plane ich aktuell gerade eine Füllstandsüberwachung für den Frischwassertank (hier bin ich mir nur noch nicht sicher, mit welchem Sensor ich diesen überwache. Optimal wäre ein Ultraschall-Abstandsssensor, nur kann ich den nicht wasserdicht verpacken). Interessant erscheint mir auch das IoT-Leaf ESP32-Board von --> Link , das ist für ein LoRaWan-Modul vorbereitet, mit welchem man dann alle Daten über The Things Network remote und ohne Mobilfunkkosten abfragen könnte. Leider verkauft der Hersteller das Board nur an Firmenkunden und bei den üblichen verdächtigen Händlern habe ich es noch nicht entdeckt.
Aktuell läuft das Ganze bei mir zu Hause im Probebetrieb, mit der kommenden Campingsaison wird das System dann "live" gehen.
Elmi79 am 27 Jan 2020 11:47:22
OK, dann darf ich mal noch die Software zur Verfügung stellen: --> Link
Die besteht aktuell aus zwei Dateien: - "data.h" enthält alle Webseitendaten und Bilder - LiFePO4.ino enthält den Code
Vorgesehen ist die Software zur Verwendung mit der Arduino-IDE für ESP32. Diese ist auf "3MB und SPIFFS" (für das SPIFFS-Dateisystem, in dem die Messdaten gespeichert werden) und "80MHz" (spart Strom und ist für die gewünschte Aufgabe mehr als ausreichend) zu konfigurieren.
Ganz oben in LiFePO4.ino sind einige Definitionen zu finden. Diese müssen jedoch nur geändert werden, wenn der eigene Hardwareaufbau abweicht oder sich die Software anders verhalten soll:
#define BATTERY_SENSOR_ANALOG_PIN 39 - legt fest, an welchem Pin die Akkuspannung gemessen wird #define LED_PIN 4 - der Ausganspin für die WLAN-Kontroll-LED #define WIFI_BUTTON 34 - Einganspin für den Schalter S1, was hier noch "WIFI_BUTTON" heißt, kann tatsächlich WLAN, Display und ESP32 schalten
#define MAX_LEVEL 3600 // 2.9V -> 14.4V -> 100% #define MIN_LEVEL 2200 // 1.95V -> 9.5V -> <10% Hier wird der Wertebereich für die Umrechnung von Akkuspannungen in Prozentwerte festgelegt, diese Werte sollten für einen 12V LiFePO4-Akku passen
#define SAMPLE_FACTOR 20 - hier kann für Testzwecke eine 1 eingetragen werden, dann laufen sämtliche Funktionen der Software 20 mal so schnell #define DATA_SIZE 888 - Anzahl der Samples pro gespeicherter Datenreihe und gleichzeitig die Breite eines angezeigten Datengraphen #define DSP_TIMEOUT 2000 - Timeout in 5-Minuten-Schritten für das Display #define WLAN_TIMEOUT 3500 - Timeout in 5-Minuten-Schritten, nach denen das WLAN ausgeschaltet wird #define WLAN_ID "Campy" - SSID unter der das WLAN-Netz sichtbar ist #define WLAN_PWD "" - Passwort für das WLAN-Netz, hier sollte unbedingt ein Wert eingetragen werden, da einem sonst böswillige Campingplatznachbarn den ESP32 ausschalten können
In der Funktion setup() werden der DHT22 und das Display initialisiert sowie die möglichwerweise schon vorhandenen Messreihen geladen. Weiterhin wird ein 5-Minuten-Timer aufgezogen, welcher dann über die Funktione onTimer() die bis dahin akkumulierten Messwerte speichert und auf dem Flash sichert. D.h. wenn die Spannung wirklich mal komplett ausfällt, gehen im ungünstigsten Fall die Daten von 5 Minuten verloren - bei einer Messreihe über bis zu 2,5 Jahre sicher zu verschmerzen. Als nächstes wird über den Aufruf der Funktion toggleWifi() das WLAN initialisiert und gestartet sowie der Webserver über die IP 192.168.1.1 an dieses Netz angebunden.
Der Code soll hier jetzt nicht in epischer Tiefe beschrieben werden, Anleitungen zum Erzeugen eines WLAN-APs, Aufsetzen eines Webservers, Ansteuern eines SSD1309-Displays und Auslesen des DSP22 gibt es im Netz zu Hauf. Erwähnenswert ist vielleicht noch die Methode, mit der die Graphen erzeugt werden: Um den ESP32 nicht sinnlos mit der Erzeugung von Bitmaps zu belasten, wird hier (jeweils in drawGraph(), drawGraphL() und drawGraphXL()) ein SVG-File dynamisch erzeugt - um das Zeichnen kümmert sich dann der Client, der in der Regel mehr Rechenleistung zur Verfügung hat.
Und wer Fragen zu dem doch nicht ganz kleinen Code hat: einfach fragen!
Anzeige vom Forum
rkopka am 27 Jan 2020 12:14:05
Elmi79 hat geschrieben:Dessen aktuelle Spannung wird über einen Spannungsteiler (R2 mit 20 kOhm) auf den VN-Eingang des ESP32 gelegt. Achtung: vor Inbetriebnahme den Trimmer ganz nach unten auf GND drehen und erst bei vollem Akku langsam nach oben regeln; wenn an ESP_VN 2,9 V anliegen, ist die Einstellung perfekt.
Ich mach das meist etwas anders. Ich rechne mir den Spannungsteiler für eine zu erwartende maximale Spannung aus z.B. 15V -> 3V und lege dann noch eine ZD (3,3V) parallel zum ESP Eingang. Damit sollte man sicher sein. Die Spannungsmessung wird dann kalibriert. Die soll ja beim ESP32 nicht so toll sein, gerade an den Grenzwerten.
Unten im Schaltplan findet sich noch ein DHT22 Temperatursensor, der an Masse, Spannung und den D13-Eingang des ESP32 angeschlossen wird. Für nur wenige Euro Mehrkosten liefert dieser die aktuelle Spannung und Luftfeuchtigkeit am Einbauort der Überwachungselektronik.
Man sollte nicht aus Versehen den DHT11 oder 12 nehmen. Der hat eine viel schlechtere Werteauflösung und -bereich.
OLED-Display. ...Wichtig: es ist darauf zu achten, dass dieser mit 3.3V läuft, einige Varianten benötigen 5V und würden damit eine zusätzliche Spannungsversorgung erfordern.
Die ESP32 Module haben eigentlich immer auch einen Regler USB 5V Ein zu 3,3V drauf. Dann könnte man einfach 5V als Hauptspannung nehmen und über den internen Regler gehen.
Abhängig vom verwendeten Board kann es nötig sein, den 10k-Ohm Pull-Down-Widerstand R1 einzubauen.
Eine Reihe der nur Eingangspins können keine internen PullUps.
Die LED1 am ESP32-Ausgang D4 ist optional, mir dient sie dazu, zu signalisieren, ob WLAN eingeschaltet ist oder nicht. Ob diese Anzeige wirklich nötig ist, wird die Praxis zeigen. Das Stromsparpotenzial ist mit knapp 4 mA aber eher gering, gleichzeitig verlöre man aber eine einfache Kontrollmöglichkeit
Ich würde sie auch drin lassen. Notfalls kann man sie ja auch nur im größeren Abstand kurz aufblitzen lassen.
Für die Software suche ich mir aktuell noch einen geeigneten Ablageort, ich werde diesen hier bekannt geben, so bald ich was passendes gefunden habe.
Ich machs gerade mit Github. Allerdings muß ich vermutlich neue Projekte anlegen, wenn die privaten öffentlich werden sollen, da in der History sonst evt. Testeinstellungen auftauchen, die nicht öffentlich sein sollen. Da muß ich nochmal nachlesen.
Allerdings ist dieser Ausfall in der Aufzeichnung auch nicht zu erkennen, da keine Echtzeituhr vorhanden ist (deswegen auch der zusätzliche Pufferakku in meinem Aufbau, damit kann ich dann wenigstens eindeutig erkennen, wenn der überwachte Akku mal komplett leer geworden ist).
Eine Möglichkeit für die Erkennung, nicht für die Information, wie lang die Unterbrechung war, ist es, immer eine Zeit mitzuspeichern millis() oder time(). Dann erkennt man, wenn die wieder auf 0 zurückgesetzt ist. Oder zumindest eine bestimmte Kennung bei PowerUp abzulegen.
RK
rkopka am 27 Jan 2020 12:34:44
Elmi79 hat geschrieben:OK, dann darf ich mal noch die Software zur Verfügung stellen: --> Link
Interessant. Ich hatte mich damals für canvas entschieden für meine Wasserwaage. Aber svg scheint auch so seine Vorteile zu haben.
RK
rkopka am 27 Jan 2020 12:58:48
Elmi79 hat geschrieben:Unten im Schaltplan findet sich noch ein DHT22 Temperatursensor, der an Masse, Spannung und den D13-Eingang des ESP32 angeschlossen wird.
Hatte ich vergessen: man muß aufpassen, daß der Sensor etwas Abstand vom ESP32 hat, der ja wohl in einem Gehäuse ist. Ich habe einen anderen Sensor direkt im Gehäuse nur mit einer kleinen Öffnung und habe laut dem fast immer eine Sauna im Womo :-(.
RK
Elmi79 am 27 Jan 2020 14:10:21
rkopka hat geschrieben:Hatte ich vergessen: man muß aufpassen, daß der Sensor etwas Abstand vom ESP32 hat, der ja wohl in einem Gehäuse ist. Ich habe einen anderen Sensor direkt im Gehäuse nur mit einer kleinen Öffnung und habe laut dem fast immer eine Sauna im Womo :-(.
Die Temperatur ist in meinem Fall kein Problem, da das Gehäuse sowieso offen ist (eine Messung in einem geschlossenen Gehäuse würde ja auch keinen Sinn machen, da sie nix über das Klima in der Kiste mit dem überwachten Akku und Laderegler aussagt). Allerdings ist mir aufgefallen, dass ein DHT22, der direkt neben dem ESP32 eingelötet ist, nach der Initialisierung mehrere Messzyklen benötigt, bis er überhaupt was liefert. Ist der DHT22 an eine lange Leitung angeschlossen, klappt sofort die erste Messung.
Keine Ahnung, woran das liegt, aber ich würde irgend eine Störeinstrahlung vom ESP32 vermuten...eventuell das WLAN?
Solarcomputer am 28 Jan 2020 19:16:48
rkopka hat geschrieben:Ich mach das meist etwas anders. Ich rechne mir den Spannungsteiler für eine zu erwartende maximale Spannung aus z.B. 15V -> 3V und lege dann noch eine ZD (3,3V) parallel zum ESP Eingang. Damit sollte man sicher sein. Die Spannungsmessung wird dann kalibriert. Die soll ja beim ESP32 nicht so toll sein, gerade an den Grenzwerten.
Wozu ein Poti überhaupt? Zuvor sollte doch der ADC einen interessanten Spannungsbereich abbilden, damit die Auflösung genauer wird. Bei einem Bereich 0 bis 15V sind das bei etwa 9-bit 0,029V... vielleicht ausreichend. Jedoch sollte dann mindestens ein 1-Punkt Abgleich in der Software vorgesehen werden, damit man zB 14600 mV genauer trifft.
Auf jeden Fall sollte ein fester Vorwiderstand vor das Pott gesetzt werden, damit es zu keiner Fehlbedienung kommt. Dieser Vorwiderstand begrenzt den maximalen Strom und schränkt den Bereich besser ein. Eine Z-Diode ZD... ist als Schutz hier recht ungeeignet, da sie den ADC Bereich zu weit einschränkt: die Z-Dioden Kurve zieht bereits bei deutlich unter 3.3V Strom aus dem Spannungsteiler. Damit ist das Ergebnis schnell sehr nicht-linear im oberen Bereich. Hier müsste man auf 5,1 V ausweichen, aber dann macht es auch keinen Sinn mehr als Schutz. Besser ist es den Strom weiter zu begrenzen, indem man nach dem Spannungsteiler einen Serienwiderstand zum ADC Pin einfügt. Das bewirkt, dass die übliche Schutzschaltung am PIN dann die Überspannung gut abbauen kann, ohne den ESP32 dabei zu zerstören. Hier sind irgendwas von 1K bis 10K sehr nützlich. Damit dann der ADC Eingangswiderstand während der Wandlung nicht das Ergebnis verfälscht, schaltet man noch einen Kondensator an das Pin, zB 100nF. Das hilft auch das Rauschen von der Batterieseite zu dämpfen.
Man sollte nicht aus Versehen den DHT11 oder 12 nehmen. Der hat eine viel schlechtere Werteauflösung und -bereich.
Nun, ich war mal in der Schweiz bei einem bekannten Hersteller für Temperatur und Feuchtesensoren tätig... daher traue ich diesen DHT-Sensoren überhaupt nicht. Besser den SHT21... oder SHT3x einsetzen, diese sind wesentlich genauer und stabiler. Wozu einen solche Aufwand treiben und dann ein unzuverlässiges Ergebnis präsentieren?
Eine Möglichkeit für die Erkennung, nicht für die Information, wie lang die Unterbrechung war, ist es, immer eine Zeit mitzuspeichern millis() oder time(). Dann erkennt man, wenn die wieder auf 0 zurückgesetzt ist. Oder zumindest eine bestimmte Kennung bei PowerUp abzulegen.
Ohne Zeitstempel und vernünftiger Verwaltung ist die Zuordnung der Messwerte unzuverlässig... dann hat man schöne Kurven, denen man dann leider nicht trauen kann. Daher unbedingt einen Zeitstempel vorsehen. Hier hat sich Unixtime oft bewährt, ist dann auch unabhängig von der Zeitzone, Sommer/Winterzeit. Die Zeit müsste sich über Browser einstellen lassen (müsste doch mittels Script auch automatisch gehen), diese sollte dann auch bei der Verbindung "gestellt" werden.
Das Projekt liegt ja unter dem Namen LiFePO4 auf Github. Bei den Lithium Akkus ist die Spannungsmessung allerdings noch weniger Aussagekräftig als bei Bleiakkus.
☀️Kai
rkopka am 28 Jan 2020 19:59:35
Solarcomputer hat geschrieben:Eine Z-Diode ZD... ist als Schutz hier recht ungeeignet, da sie den ADC Bereich zu weit einschränkt: die Z-Dioden Kurve zieht bereits bei deutlich unter 3.3V Strom aus dem Spannungsteiler. Damit ist das Ergebnis schnell sehr nicht-linear im oberen Bereich. Hier müsste man auf 5,1 V ausweichen,
Oder man legt den ADC auf 1,1V max.,Teiler auf 1,1V, und schützt mit 3,3V.
Besser den SHT21... oder SHT3x einsetzen, diese sind wesentlich genauer und stabiler. Wozu einen solche Aufwand treiben und dann ein unzuverlässiges Ergebnis präsentieren?
Ich hab den Si7021.
Ohne Zeitstempel und vernünftiger Verwaltung ist die Zuordnung der Messwerte unzuverlässig... dann hat man schöne Kurven, denen man dann leider nicht trauen kann. Daher unbedingt einen Zeitstempel vorsehen. Hier hat sich Unixtime oft bewährt, ist dann auch unabhängig von der Zeitzone, Sommer/Winterzeit.
Das nutzt nur nichts, wenn der Strom ausfällt oder man in den SeepSleep geht, dann ist sie erst wieder weg. Wobei es oft schon reicht, zu wissen, wo eine Unterbrechung ist.
Die Zeit müsste sich über Browser einstellen lassen (müsste doch mittels Script auch automatisch gehen), diese sollte dann auch bei der Verbindung "gestellt" werden.
Ein Javascript am Anfang der Seite holt die Browserzeit und sendet sie (z.B. mit einem POST) an eine Seite am Gerät, die das auswertet.
rkopka hat geschrieben:Oder man legt den ADC auf 1,1V max.,Teiler auf 1,1V, und schützt mit 3,3V.
... dann lies dich mal hier durch: --> Link Mein Resume davon ist entweder einen externen ADC verwenden oder ein analoges Frontend bauen, was den interessanten Messbereich so anpasst, dass auch mit diesem ADC noch was anzufangen ist.
Das nutzt nur nichts, wenn der Strom ausfällt oder man in den SeepSleep geht, dann ist sie erst wieder weg. Wobei es oft schon reicht, zu wissen, wo eine Unterbrechung ist.
"Oft" reicht dann eben nicht. Es gibt viele Fallstricke dabei, damit habe ich bei meinen Projekten teilweise sehr viel Zeit investieren müssen.
Ein Javascript am Anfang der Seite holt die Browserzeit und sendet sie (z.B. mit einem POST) an eine Seite am Gerät, die das auswertet.
Genau das meinte ich. Der ESP32 kein "sudo" Linux cmd verstehen.... das meintest du wohl mit "etwa". Weiterhin müsste beim Setzen der Uhrzeit aufgepasst werden, um z. B. eine Zeitkorrektur im Log festzuhalten (damit zeitliche Zusammenhang im Log nachvollziehbar wird).
Ich habe letztes Jahr den ESP32 zusammen mit einem HMI Display (kleiner Touchscreen 2,4") zusammengebaut. Die Idee war dabei den ESP32 als Gateway zwischen Batteriecomputer (BlueBattery Bluetooth BLE) und WLAN / Internet zu nutzen. Somit könnte der ESP32 dann an einem WLAN Hotspot sich anmelden (Smartphone, Router etc.) und seine Informationen via HTML Server bereitstellen. Zudem die Daten bei einer bestehenden Internetverbindung dann an einen Cloud-Service senden. Zusätzlich ist noch ein WLAN-AP Mode eingebaut, um eine Basiskonfiguration und Firmware-Update zu ermöglichen. Die Sicherheit wird über WPA2 hergestellt, ein individueller Access-Token (automatisch generiert) wird als QR-Code-Link auf dem Display bei Bedarf dargestellt. So sieht BlueHMI dann aus: --> Link
Als Nachfolgeversion plane ich gerade eine integrierte Version, die das Modul ESP-WROOM-32 aufnimmt. Bei den üblichen China Dev-Boards brechen gerne die USB Buchsen ab und die Boards sind nicht mit ext/int Antenne mit gleichem Footprint/Mount zu bekommen, die Handverkabelung der Komponenten entfällt. Das ESP-WROOM-32 Modul ist sehr günstig und kann wahlweise mit integrierter oder externen Antenne bestückt werden. Ferner sind auf der Platine:
- DC/DC Adapter um von 12V effizient auf 5V (Display) und 3V3 zu kommen - wahlweise DC-Buchse / Klemmleiste für den Stromanschluss - Break-Out Anschluss USB Serial-TTL Adapter
Beim embedded Web-Server stehe ich etwas auf Kriegsfuß, das erstellen der HTML-Pages und einbauen ins Programm ist recht umständlich, schlecht zu debuggen. Ferner ist eine Anbindung an einen Cloud Service / Dashboard oft mit hohen Kosten (teilweise Servicemiete) oder viel Know-How (vom Benutzer) verbunden. Hier suche ich also noch wie es am besten gehen könnte. Vielleicht wäre das als Open-Source mittels Github lebendig zu halten.
☀️Kai
rkopka am 29 Jan 2020 12:08:40
Solarcomputer hat geschrieben:Mein Resume davon ist entweder einen externen ADC verwenden oder ein analoges Frontend bauen, was den interessanten Messbereich so anpasst, dass auch mit diesem ADC noch was anzufangen ist.
Mit Kalibrierung im interessanten Bereich geht vermutlich noch etwas. Aber wenn hohe Auflösung nötig ist, kommt man schnell an die Genzen. Bei meinen Überlegungen Richtung Batteriecomputer war das hauptsächlich bei der Strommessung, weil die Dynamik da doch recht hoch ist. Es gibt ja schöne ADCs mit viel mehr Auflösung.
Das nutzt nur nichts, wenn der Strom ausfällt oder man in den SeepSleep geht, dann ist sie erst wieder weg. Wobei es oft schon reicht, zu wissen, wo eine Unterbrechung ist.
"Oft" reicht dann eben nicht. Es gibt viele Fallstricke dabei, damit habe ich bei meinen Projekten teilweise sehr viel Zeit investieren müssen.
Alternativ einfach ein kleines Uhrenmodul mit integrierter Knopfzelle anhängen. Gibts für ein paar Euro, meist über I2C angesprochen. Teilweise sogar noch mit etwas gebuffertem RAM.
Genau das meinte ich. Der ESP32 kein "sudo" Linux cmd verstehen.... das meintest du wohl mit "etwa". Weiterhin müsste beim Setzen der Uhrzeit aufgepasst werden, um z. B. eine Zeitkorrektur im Log festzuhalten (damit zeitliche Zusammenhang im Log nachvollziehbar wird).
Ja. Der Logeintrag sollte sein. Allein schon um festzustellen, wie genau die Uhr ist und um die Zeitsprünge einzuordnen. Bei einem ESP32 habe ich einfach die time() genommen, die nachgestellt wird. Dabei sehe ich bisher, daß alle 10h 60sek erreicht werden (dann stellt er bei mir nach). Mein Kommentar "Linux" soll klarstellen, daß das nur ein Muster ist. PHP hat man ja normal auch nicht am ESP32. Das muß man halt in C/C++ schreiben. Der Code ist aus einem Embedded System mit einem ARM und Linux herausgenommen. Unter Linux gibts noch einiges mehr eben zu Zeitzone und HW Uhr stellen.
Beim embedded Web-Server stehe ich etwas auf Kriegsfuß, das erstellen der HTML-Pages und einbauen ins Programm ist recht umständlich, schlecht zu debuggen.
Debuggen kann man sehr simpel einfach mit Ausgaben ins html. Dazu die serielle am ESP32. Bisher habe ich nur sehr einfache Sachen, da geht HTML direkt zu codieren. Alternativ auch mit einem WYSIWYG HTML Editor (z.B. Seamonkey). Javascripts (Canvas) teste ich erstmal am PC mit den HTML Seiten entweder direkt am PC oder auf einem RaspberryPI mit Apache2. Javascript kann man am Firefox recht schön debuggen.
Ferner ist eine Anbindung an einen Cloud Service / Dashboard oft mit hohen Kosten (teilweise Servicemiete) oder viel Know-How (vom Benutzer) verbunden. Hier suche ich also noch wie es am besten gehen könnte. Vielleicht wäre das als Open-Source mittels Github lebendig zu halten.
Cloud Funktionen will ich mit meinem (eingeschränkten) Server beim Webhoster machen. Da kostet selbst die ziemlich umfangreiche Version nicht allzuviel. Dafür ist es kein echter Server, was die Nutzung von Python... einschränkt.
--> Link sieht auch interessant aus. Allerdings kapier ich den umfangreichen Code noch nicht. Außerdem finde ich keine Infos zur tatsächlichen GUI oder wie und wo die Sensoren angeschlossen werden.
RK
Solarcomputer am 29 Jan 2020 14:32:32
rkopka hat geschrieben: Bisher habe ich nur sehr einfache Sachen, da geht HTML direkt zu codieren. Alternativ auch mit einem WYSIWYG HTML Editor (z.B. Seamonkey). Javascripts (Canvas) teste ich erstmal am PC mit den HTML Seiten entweder direkt am PC oder auf einem RaspberryPI mit Apache2. Javascript kann man am Firefox recht schön debuggen.
Nun, der Datei Upload vom Client (Smartphone) über WLAN / HMTL zum ESP32-Server und von dort aus via UART (mit Baudrate Umschaltung und Bugs im ESP32) zum HMI Display war blöde zu Debuggen. Die Daten "gestreamt" werden mussten, der Upload mit 2MB zu groß zum Zwischenspeichern ist. Es sollte noch ein Fortschrittsblanken im Client angezeigt werden, der den tatsächlichen Upload am UART Monitoren kann. Dabei sind immer Buffer in den einzelnen Stacks und das zeitliche Verhalten dabei flüssig und funktional zu halten, war dann nicht so simple mit einem Tool zu debuggen... so zumindest meine Erfahrung. Ich meine damit, solange man in einer Domäne in der Implementierung bleiben kann ist es überschaubar und und relativ leicht.
--> Link sieht auch interessant aus. Allerdings kapier ich den umfangreichen Code noch nicht. Außerdem finde ich keine Infos zur tatsächlichen GUI oder wie und wo die Sensoren angeschlossen werden.
... das Projekt ist zuletzt Aug/2018 bedient worden. Ich dachte eher an so etwas wie PVoutput.org
☀️Kai
rkopka am 29 Jan 2020 15:02:06
Solarcomputer hat geschrieben:Die Daten "gestreamt" werden mussten, der Upload mit 2MB zu groß zum Zwischenspeichern ist.
SDcard ? Es gibt ja sogar schon Module (Franzis verkauft welche) mit eingebautem uSD Steckplatz.
... das Projekt ist zuletzt Aug/2018 bedient worden. Ich dachte eher an so etwas wie PVoutput.org
Wobei man da natürlich unterscheiden muß, ob es eine öffentliche Seite sein soll, eine private oder einfach nur die Oberfläche im Womo. Je nachdem steigen die Schwierigkeiten (Security). Da ich nur was bauen will, das primär für mich ist, muß ich mir weniger Sorgen um eine schöne Oberfläche und daß jeder DAU es benutzen kann machen und nur eingeschränkt zur Security. Ebenso sind die Datenmengen nur sehr klein. Da ist der Stromverbrauch viel eher ein Problem. Zum Glück gibts Solarzellen :-).
Vielleicht überspringe ich mal einiges und stelle einen simplen Temperatursensor und Spannungsüberwacher mit UMTS Router ins Womo. Einfach mal nur für ein kleines Erfolgserlebnis :P .
RK
Solarcomputer am 29 Jan 2020 19:49:02
rkopka hat geschrieben:SDcard ? Es gibt ja sogar schon Module (Franzis verkauft welche) mit eingebautem uSD Steckplatz.
Der Kartensteckplatz ist ja bereits vorhanden, nur hat das eben den Nachteil, dass eine Karte dazu zwingend erforderlich ist. Zudem ist das sequenzielle Laden dann "noch" langsamer (Ladezeiten sind sowieso nervig) und das dann auf ein SDcard Buffering umstellen ist noch komplizierter (und damit Fehleranfälliger).
Ich wollte das System letztlich ja auch so bauen, dass es auch andere benutzen können. Es sind bereits einige Dutzend von diesen Displays mit dem ESP in verschieden Wohnmobilen so unterwegs. Jetzt überlege ich eben wie das sinnvoll und nutzbar mit Web Server / Internet / Cloud erweitert werden kann. Bislang dient der WLAN-AP nur zum Firmware Update, im normalen Betrieb habe ich WLAN abgeschaltet (Strom sparen). Der ESP32 ist eben die stromsparendere Alternative zu einem Raspi für solche Zwecke.
rkopka am 31 Jan 2020 15:04:17
rkopka hat geschrieben:Die Spannungsmessung wird dann kalibriert. Die soll ja beim ESP32 nicht so toll sein, gerade an den Grenzwerten.
Das habe ich jetzt mal getestet. Dazu habe ich einfach 15 Faktoren über 15V Meßbereich benutzt, die ich manuell hingetrimmt habe. Geht besser, aber immer noch nicht gut. Schon 0,2V über den ganzen Bereich ist kaum zu erreichen (1,5% vom Maximalwert). Für die Batterie nicht toll, außer man legt da noch mehr Korrekturpunkte hin. Ich muß mal schauen, ob das mit einer Kurve besser angenähert werden kann, wenn ich (mit meinen Mitteln) eine einfache und bequeme Möglichkeit finde, genug Werte für die Bestimmung der Kurve aufzunehmen. Ob sich das aber lohnt ? Vermutlich ist ein externen ADC die bessere Wahl, wenn es genauer sein soll. Bisher nutze ich den ADC nur in einer Strommessung, bei der die Genauigkeit egal ist, weil nur bestimmte Strombereiche erkannt werden sollen. Da sind 10% Abweichung kein Problem.
RK
Elmi79 am 31 Jan 2020 17:10:59
Es ist halt immer die Frage, welche Anforderungen tatsächlich gestellt werden. Für mich kommt es primär auf die Akkuüberwachung an, hier ist der ESP32 ausreichend genau (wenn er mal 10% anzeigt und vielleicht trotzdem noch 13% Ladestand hat, ist das für mich vollkommen in Ordnung). Die Temperatur/Feuchtigkeitsfunktion ist für mich eigentlich nur ein Nebenprodukt, weil ohne großen finanziellen oder zeitlichen Mehraufwand realisierbar - die fällt quasi nebenbei ab. Der DHT22 mag nicht perfekt sein, aber ebenfalls ausreichend genau. ich habe den hier schon bei ein paar anderen Sensoren im Einsatz und da tut er, was er soll - mit einer erwartbaren und akzeptablen Genauigkeit. Ich brauch einfach keine Hundertstelgrad und runde selbst die Messwerte des DHT22 auf ganze Gradwerte.
Was wirklich gar nicht geplant war und trotzdem einfach zu realisieren ist, ist die Füllstandsüberwachung für den Frischwassertank - da habe ich inzwischen einen passenden, wasserdichten Ultraschallsensor gefunden :-)
rkopka am 02 Feb 2020 00:54:45
rkopka hat geschrieben:Das Problem für Batteriegeräte ist aber, daß das WLAN bei mir 4sek braucht, um eine Verbindung aufzubauen und ein mqtt Publish abzusetzen. Da in der Zeit der hohe Strom fließt, ist das für Batteriegeräte nicht sinnvoll.
Inzwischen habe ich das ESP-NOW entdeckt. Kurze Pakete (250 Bytes) sehr schnell zwischen ESP Boards übertragen ohne langes Einloggen. Einen Temperaturlogger mit einem ESP8266 habe ich zumindest auf 300ms Einschaltzeit runterbekommen, mit ESP32 könnte es noch schneller gehen. Damit komme ich rechnerisch mit 2Ah/3V auf 1Jahr Betrieb mit einer Messung alle 15min. Das ist schon brauchbar. Damit kann man in vielen Fällen auf die 433MHz Module verzichten, obwohl damit sicher noch kürzere Zeiten erreichbar sind und auch mehr Prozessoren funktionieren.
Es ist zwar schwer beim Googlen nicht drauf zu stoßen, aber zur Sicherheit: --> Link . Die Seite bietet eine Menge Beispiele zu den klassischen Anwendungen.
RK
rkopka am 02 Feb 2020 14:14:13
rkopka hat geschrieben:Einen Temperaturlogger mit einem ESP8266 habe ich zumindest auf 300ms Einschaltzeit runterbekommen, mit ESP32 könnte es noch schneller gehen.
Der eigentliche Transfer geht schneller. Leider braucht er 270ms zum Hochlauf bis die erste (eigene) Programmzeile ausgeführt wird. Der Strom dabei ist zwar nicht so hoch, aber doch nennenswert. Pro Übertragung meiner Rechnung nach das gleich wie beim ESP8266.
Übrigens sehe ich auch die 10mA beim DeepSleep. Das kommt wohl von der Peripherie am Modul. Ich muß mal die unterschiedlichen bei mir Testen, ob eines besser ist. Ich hab auch ein reines ESP32 Modul ohne Peripherie bestellt. Ansonsten sollen diese --> Link besser sein und haben auch einen LiPo Anschluß, 10uA angeblich
Ich hab auch 6-7mA bei einem typischen DCDC Wandler gemessen (12V->5V, keine Last). Bei dem ganzen Stromsparen ist das nicht so toll. Gibts da was besseres ? Ein Standard Linearregler wäre auch nicht schlechter.
RK
Solarcomputer am 02 Feb 2020 21:14:51
Es gibt extra DC/DC Wandler mit optimierten Standby. Dann schaltet man die Betriebsart per GPO Pin um. Es gibt auch automatisch umschaltende. Jedoch keine fertig aus China aufgebauten und zuverlässige.
Beim ADC korrigieren, kannst du das individuell so machen, dass du deine Messkurve mal in Excel anschaust. Sollte sich das mit „Trend“ (Polynome, Exponential, etc) fitten lassen, kannst du die resultierende Formel verwenden. Allerdings bleibt das dann eine individuelle Trimmung. Zudem solltest du mehrere Messkurve aufzeichnen, such mal kalt, warm... soweit ich mich erinnere ist das Ergebnis recht rauschend, hängt wohl am internen Betriebsmodus. Da bliebe dann viele Werte (zB 1024) in einem Burst messen und dabei filtern. Eventuell noch die Temperatur dabei in die Rechnung aufnehmen. Das ganze lohnt nur, wenn man daran Spaß hat, ansonsten externen ADC nehmen.
Als Sensor-Nodes eignet sich statt WLAN Bluetooth zu nehmen. Dort wird eine Messung dann mittels Notification vom Sensor geschickt. Dabei wird das Zeitfenster, in denen Sensor und Empfänger sich verstehen auf eine sehr kurze genaue Zeit definiert. Daher ist es auch wesentlich stromsparender. Die aktive Zeit ist dann wenige Millisekunden. Typische Bluetooth Chips können daher als Sensor Node mit einer Knopfzelle 1 Jahr betrieben werden. Das ließe sich dann mit dem ESP32 nutzen.
☀️Kai
rkopka am 02 Feb 2020 22:33:52
Solarcomputer hat geschrieben:Das ganze lohnt nur, wenn man daran Spaß hat, ansonsten externen ADC nehmen.
Das ist wohl die bessere Lösung. Zumal die Chips nicht besonders teuer sind und zumindest für den Bastler bei Einzelstücken der Preis auch nicht so wichtig ist. Allerdings bekommt man viele der Chips nur noch als SMD. Ich hab schon ein paar auf Adapterplatinen verlötet zum Rumspielen.
Typische Bluetooth Chips können daher als Sensor Node mit einer Knopfzelle 1 Jahr betrieben werden. Das ließe sich dann mit dem ESP32 nutzen.
Was wären das für Typen ?
RK
rkopka am 03 Feb 2020 11:12:32
rkopka hat geschrieben:Vielleicht überspringe ich mal einiges und stelle einen simplen Temperatursensor und Spannungsüberwacher mit UMTS Router ins Womo. Einfach mal nur für ein kleines Erfolgserlebnis :P .
Das habe ich jetzt gemacht. Ich bin noch über den WD des ESP32 gestolpert. Wenn WIFI einmal an war und dann länger abgeschaltet wird, kommt wohl ein interner WD am Wifi Kern zum Zug.
Als nächstes eine grafische Darstellung der Werte. Das System (ESP32 + LTE Router) braucht etwa 75mA. Wie man am hohen RSSI Wert sieht, steht der Router direkt neben dem ESP.
Und das ist der hochprofessionelle, "raumfahrttaugliche" Aufbau:
RK
rkopka am 06 Feb 2020 09:20:20
rkopka hat geschrieben:Als nächstes eine grafische Darstellung der Werte.
Hier mein erster Versuch mit der D3 Lib. Vieles ist noch rudimentär, aber die Tendenz ist zu erkennen.
Rot ist Licht (keine Dimension, 40 ist das Maximum des Sensors), grün Batteriespannung, blau die Temperatur.
RK
Solarcomputer am 06 Feb 2020 15:45:28
Zum Verständnis: D3 ist eine Library, mit deren Hilfe diese schöne Grafik erstellt werden kann. Das bedeutet allerdings, dass der Browser Zugriff auf diese Library braucht. Normalerweise holt sich der Browsers dynamisch diese Lib aus dem Internet, also im HTML File steht dann: <script src="https://d3js.org/d3.v5.min.js"></script>
Wird jetzt das Smartphone mit dem ESP über WLAN (WLAN-AP) verbunden, so kann eine solche Library ggf. nicht aus dem Internet geladen werden (sofern hier eben nicht ein Router mit Internetverbindung eingebunden ist). Das macht es eben nicht so leicht, wenn man vom ESP aus einem embedded System ohne Internet eine komplexe Web-Page aufbauen möchte. Es müssten die Ressourcen entsprechend "local" oder aus einem "Cache" vorgehalten werden. Wenn allerdings nur geplant ist die Daten an einen Internet-Server zu senden und das Abrufen immer über das Internet erfolgt, müsste das gehen.
☀️Kai
rkopka am 06 Feb 2020 16:09:18
Solarcomputer hat geschrieben:Wird jetzt das Smartphone mit dem ESP über WLAN (WLAN-AP) verbunden, so kann eine solche Library ggf. nicht aus dem Internet geladen werden ... Es müssten die Ressourcen entsprechend "local" oder aus einem "Cache" vorgehalten werden.
Die Library kann man eben auch lokal als File ablegen und von dort laden. Die kleine Version der Lib braucht 243KB, was auch am ESP noch gehen müßte. Alternativ legt man sie auf eine SDCard. Allerdings habe ich das Bild nicht direkt vom ESP sondern generiere es am externen Server, der die Daten speichert. Aus irgendeinem Grund nimmt er mir dort die lokale Lib nicht, aber das ist in dem Fall nicht so schlimm.
RK
rkopka am 09 Feb 2020 15:11:30
Nach langem Kampf wird es jetzt so angezeigt, wie ich das will. Es gibt eine Zoomfunktion, die fast die meiste Zeit gekostet hat. Man findet zwar Unmengen an Beispielen, aber meistens nicht unbedingt so, wie man das will. Außerdem gibt es verschiedene D3 Versionen, die nur begrenzt kompatibel sind und wo gerade beim Zoom einiges geändert wurde. Am einfachsten ist es, wenn man ein sehr genau passendes Beispiel findet und die Anzeige einfach hält. Sonst muß man die ganzen Elemente, Optionen, Attribute... durchsuchen. Außerdem habe ich noch so meine Probleme mit Javascript bei asynchronen Funktionen und einigen der objektorientierten Strukturen.
Das Licht wird jetzt logarithmisch dargestellt, was vermutlich etwas sinnvollere Anzeigen ergibt. Interessant ist, daß der Akku derzeit schon mit den ersten Sonnenstrahlen wieder voll ist. Der Strom für die Überwachung macht sich kaum bemerkbar. Eigentlich will ich noch mehr Werte erfassen. Die aber auch noch in die eine Grafik zu integrieren ist nicht ideal. Zumindest die Außentemperatur soll noch kommen, während die Luftfeuchte weniger interessant ist.
RK
rkopka am 27 Feb 2020 16:54:57
Inzwischen gibt es einen Außensensor, der auch dargestellt wird. Da die Einheit für den Funkempfang dauernd aktiv sein muß, ist der Stromverbrauch noch etwas gestiegen.
Interessant finde ich, daß die Temperaturen nicht stark abweichen und die Luftfeuchte im Inneren nur sehr gering schwankt im Gegensatz zu außen.
Für den Funksensor habe ich verschiedene Techniken ausprobiert. 433MHz Funk wäre mir am liebsten gewesen. Allerdings ist da nach ersten erfolgreichen Tests irgendwas passiert und ich habe nur noch eine lächerliche Reichweite. Dann habe ich RF24 Module benutzt. Die gehen recht gut. Allerdings habe ich wohl schlechte Exemplare, da der Ruhestrom nicht unter 1mA statt der versprochenen 20uA sinkt. Also habe ich mal das ESPNOW System dafür versucht. Mit einem ESP8266 Modul mit USB etc. brauche ich zwar auch noch etwa 300uA im DeepSleep, aber für den ersten Test muß es reichen. Eher stört, daß das Modul fast 500ms braucht, vieles davon für den PowerUp und die Funk Einrichtung. Aber immer noch weniger als bei richtigem WLAN. Daher sende ich nur alle 5min (später 10min). Einfacher wäre ein fertiger Funksender von einem Funkthermometer. Allerdings habe ich da noch keinen erfolgreichen Empfang geschafft.
RK
Elmi79 am 21 Jun 2020 15:47:29
Na der Thread ist ja lustig ausgeufert :-)
Mein Akkuwächter ist inzwischen auch in Betrieb - inklusive eines kleinen Display, das mir Akkustand und Innentemperatur anzeigt. Die Temperatur wird dabei über einen DHT22 erfasst - was mich gleich auf eine weitere Idee bringt (Ressourcen sind dafür ja noch genügend vorhanden beim ESP32):
Der DHT22 erfasst neben der Temperatur im Innenraum auch die Luftfeuchte. Jetzt ist meine Idee, einen zweiten DHT22 anzuschließen, der außerhalb des Wohnwagens angebracht ist und dann - wann immer der Akkustand über 90% ist und die Luftfeuchtigkeit außen unter der im inneren liegt - den Lüfter im Dach anschaltet, damit der für einen Luftaustausch sorgt, der trockenere Luft ins Innere befördert.
Mein Problem: wie bringe ich den äußeren DHT22 an, so dass der zwar die Außenluftfeuchte misst, aber bei Regen oder während der Fahrt auf nasser Straße selber nicht nass wird? Es müsste wohl irgendwas mit einem Rohr sein, aber wo ich das befestige, ist mir noch komplett schleierhaft...
Elmi79 am 21 Jun 2020 15:52:01
rkopka hat geschrieben:Einfacher wäre ein fertiger Funksender von einem Funkthermometer. Allerdings habe ich da noch keinen erfolgreichen Empfang geschafft.
Für die Außentemperatur habe ich eine andere Lösung gefunden: Dort steht eine kleine Box (ebenfalls ein ESP32) die per Solar und Akku betrieben wird. Die Temperatur wird dabei per Bluetooth übermittelt - direkt im Namen des Bluetooth-Gerätes, der Empfänger muss sich also noch nicht mal mit dem Außensensor verbinden sondern nur von Zeit zu Zeit alle vorhandenen Bluetooth-Geräte im Umkreis ermitteln und dann das Gerät ausfiltern, welches ins erwartete Namenschema passt.
rkopka am 21 Jun 2020 16:05:58
Elmi79 hat geschrieben:Jetzt ist meine Idee, einen zweiten DHT22 anzuschließen, der außerhalb des Wohnwagens angebracht ist und dann - wann immer der Akkustand über 90% ist und die Luftfeuchtigkeit außen unter der im inneren liegt - den Lüfter im Dach anschaltet, damit der für einen Luftaustausch sorgt, der trockenere Luft ins Innere befördert.
Kommt sicher drauf an, wo man steht. Mit Personen im Inneren kann das auch deutlich anders aussehen. Mein abgestelltes Womo hatte die letzten Monate etwa 1x pro Woche für ein paar Stunden maximal 3% weniger Luftfeuchte außen. Also nicht sehr lohnend.
Elmi79 hat geschrieben:Mein Problem: wie bringe ich den äußeren DHT22 an, so dass der zwar die Außenluftfeuchte misst, aber bei Regen oder während der Fahrt auf nasser Straße selber nicht nass wird? Es müsste wohl irgendwas mit einem Rohr sein, aber wo ich das befestige, ist mir noch komplett schleierhaft...
Ich hab meinen Sensor im Gaskasten (ja da gibt es Einschränkungen, aber das kann man anderswo diskutieren). Durch die großen Öffnungen nach außen ist das sehr nah am Außenzustand. Sonst würde ich bei mir unter dem Womo hinter den Abwassertank gehen. Da wird durch die Räder nichts hingespritzt, es ist weit oberhalb der Straße und auch gegen alles von vorne geschützt.
Mein Testsystem läuft jetzt 118 Tage durch. Einmal mußte ich den Akku des Temperatursensors tauschen.
Elmi79 hat geschrieben:Für die Außentemperatur habe ich eine andere Lösung gefunden: Dort steht eine kleine Box (ebenfalls ein ESP32) die per Solar und Akku betrieben wird.
Unter dem Auto oder innen ist es mit Solar schlecht. Und ein ESP32 ist beim Stromverbrauch nicht ideal. DeepSleep geht, aber wenn man öfter aufwacht, ist er immer einige Zeit aktiv und braucht Strom. Oder man mißt mit einem anderen uC (AVR...) und schaltet den ESP nur zur Übertragung ein. Ist aber irgendwie blöd.
Die Temperatur wird dabei per Bluetooth übermittelt - direkt im Namen des Bluetooth-Gerätes,
Bei BT habe ich bisher nicht viel mehr als ein paar Beispiele ausprobiert. Aber bringt das viel gegenüber ESPNOW (wenn man 2 ESPs hat) ? 433MHz wäre gut, weil schnell und wenig Strom. Muß ich wiedereinmal probieren.
RK
Elmi79 am 21 Jun 2020 16:43:41
rkopka hat geschrieben:Kommt sicher drauf an, wo man steht. Mit Personen im Inneren kann das auch deutlich anders aussehen. Mein abgestelltes Womo hatte die letzten Monate etwa 1x pro Woche für ein paar Stunden maximal 3% weniger Luftfeuchte außen. Also nicht sehr lohnend.
Ich denke, das könnte sich im Winter richtig lohnen, speziell wenn auf einige nasse Tage Sonnenschein folgt - ich würde vermuten, dass die Feuchtigkeit dann genau so langsam von innen nach außen geht, wie sie vorher hineingekommen ist, da könnte es sich lohnen, ein wenig nachzuhelfen.
rkopka hat geschrieben:Unter dem Auto oder innen ist es mit Solar schlecht. Und ein ESP32 ist beim Stromverbrauch nicht ideal. DeepSleep geht, aber wenn man öfter aufwacht, ist er immer einige Zeit aktiv und braucht Strom. Oder man mißt mit einem anderen uC (AVR...) und schaltet den ESP nur zur Übertragung ein. Ist aber irgendwie blöd.
Japp, der Anwendungsfall ist bei mir ein wenig anders, dieser Bluetooth-Außensensor wird nur während des Urlaubs draußen auf den Tisch gestellt und ist den Rest des Jahres aus. Für die maximal drei Wochen am Stück reicht der 6Ah-Akku mit Solarunterstützung locker.
rkopka am 21 Jun 2020 18:34:06
Elmi79 hat geschrieben:Ich denke, das könnte sich im Winter richtig lohnen, speziell wenn auf einige nasse Tage Sonnenschein folgt - ich würde vermuten, dass die Feuchtigkeit dann genau so langsam von innen nach außen geht, wie sie vorher hineingekommen ist, da könnte es sich lohnen, ein wenig nachzuhelfen.
Wenn man unterwegs ist und Feuchte reinbringt, wohl schon. Ansonsten kommt die Feuchte ja gar nicht erst rein (nach meinen Messungen). Bei mir wars immer zwischen 40 und 50%. Steigerungen bei Regenwetter kaum mehr als +5% und -5% wenn die Sonne stark lachte und das erst nach Stunden, auch wenn draußen 90% waren.
rkopka hat geschrieben:Japp, der Anwendungsfall ist bei mir ein wenig anders, dieser Bluetooth-Außensensor wird nur während des Urlaubs draußen auf den Tisch gestellt und ist den Rest des Jahres aus. Für die maximal drei Wochen am Stück reicht der 6Ah-Akku mit Solarunterstützung locker.
Mein ESPNOW mit 5min DeepSleep kam mit 4x AA 2000mAh bei 1600mAh Verbrauch 3,5 Monate aus. Für einen ESP8266 mit WLAN Verbindung habe ich bei 2600mAh(LiFe) 2 Monate bei 10min. Messung errechnet. Das ist für eine Teichtemperaturmessung (wir haben dort einen Router), wo ich mir die Solarzellen gern sparen würde, damit es nicht so leicht beschädigt wird. Dort 1h Messung und 7,5 Monate, also genug für die Sommersaison.
Ich hab für den letztgenannten Zweck mit der Antenne experimentiert. Die Reichweite ist für die Erweiterungen sehr an der Grenze. Nach einem YT Video habe ich einfach einen Draht an die Platinenantenne gelötet und stückweise abgeschnitten, bis ich den besten Empfang hatte. Damit kann ich am Basteltisch >20dB gewinnen. Draußen immer noch bis zu 10dB.
RK
Elmi79 am 21 Jun 2020 19:22:16
rkopka hat geschrieben:Mein ESPNOW mit 5min DeepSleep kam mit 4x AA 2000mAh bei 1600mAh Verbrauch 3,5 Monate aus. Für einen ESP8266 mit WLAN Verbindung habe ich bei 2600mAh(LiFe) 2 Monate bei 10min.
Der ist bei mir nicht im DeepSleep-Modus. Der ist ständig aktiv mit einer 3-sekündigen Pause im Main-Loop. Schließlich soll er ja ständig die Temperatur messen und per Bluetooth nach außen zur Verfügung stellen. Zum Stromsparen läuft er nur auf 80 MHz (das Minimum, mit dem Bluetooth noch geht).
In DeepSleep geht er nur, wenn die Akkuspannung sinkt. Das gibt der solarzelle die Möglichkeit, für ein paar Stunden nur den Akku zu landen ohne den ESP versorgen zu müssen - in der Zeit gibt's natürlich auch keine Temperaturmessung.
rkopka am 11 Apr 2021 21:52:44
Für die Bastler gibts im aktuellen MAKE einen Artikel über eine Motorsteuerung einer SAT Antenne mit WEB Interface, Lagesensoren und Kompaß. Also die Billigvariante einer automatischen Antenne. Das eigentliche Einstellen geht noch manuell.
RK
uk1408 am 12 Apr 2021 12:02:10
Hallo Bastler, wenn wir nicht gerade unterwegs sind, steht unser WoMo in einem einsamen Carport ohne alles. Damit zumindest die Starterbatterie geladen bleibt habe ich ihr ein 50 Watt Soalarpanel spendiert. Und damit ich weiß wie es der Technik geht habe ich vor einiger Zeit auch mal was gebastelt. Das läuft jetzt im 3. Winter problemlos. Mein Ziel war - wie auch in den anderen Beiträgen geschrieben - Spannung, Temperatur und Luftfeuchte zu überwachen und zu dokumentieren. Daraus hat sich dies entwickelt: Ein ESP8266 (ESP 12E) steuert das alles. Ein ADS 1115 misst die Spannung, 3 Eingänge sind noch übrig. Ist deutlich genauer und m.E. nach auch einfacher als den analogen Eingang zu nehmen. Ein BME280 misst Feuchte und Temperatur, mit den DHTxx war ich nicht so recht zufrieden. Ein OLED 1,3 " informiert am Gerät über die Daten. Ein SIM800L überträgt die Daten regelmäßig zu (m)einem Server von dem ich sie dann via Browser abrufen kann. Da das GSM-Modul auch die ungefähren geographischen Koordinaten kennt werden die auch noch mit übermittelt, da weiß ich dann auch noch wo das WoMo gerade steht. Der ESP misst zyklisch, speichert die Werte und geht in den Tiefschlaf. Nach x Messungen wird zusätzlich das GSM-Modul über einem FET eingeschaltet, es bucht sich ein und die Daten gehen zum Server. Dann fällt alles wieder in den Tiefschlaf. Nur das OLED zeigt die letzten aktuellen Daten. Immer wenn der ESP neu bootet besteht die Möglichkeit, das WLAN des ESP zu aktivieren und alle wichtigen Parameter über eine HTML-Seite einzustellen. Darüber hinaus kann auch mit einer SMS die Adresse des Servers für die Daten geändert werden. Damit keine Kosten anfallen habe ich eine kostenlose GSM-Karte (netzclub) genommen, klappt einwandfrei ohne größere Nebenwirkungen. Bei diesem Projekt hat sich einfach eines zum anderen ergeben und es läuft jetzt wieder seit dem Abstellen des WoMo irgendwann im Oktober letzten Jahres (gespeichert werden immer ca. 4 Wochen).
Elmi79 am 12 Apr 2021 17:13:32
Ich habe mir was ganz ähnliches auf Basis eines ESP32 gebaut: Die Akkuspannung des Moverakkus wird per Analogeingang des ESP überwacht (da dessen ADCs ein wenig ungenau sind, werden die immer über ein paar Minuten aufsummiert). Feuchtigkeit und Temperatur innen und außen werden mit 2x DHT22 gemessen (die waren mir genau genug) und alles für max. 1,5 Jahre aufgezeichnet.
In den Tiefschlaf schicke ich den ESP nicht, aber mit ausgeschaltetem WLAN und deaktivertem SSD1306 Display schafft der es im Leben nicht, den mit 100 W Solar betriebenen 30-Ah-Akku leerzusaugen. Und für den Fall, dass ich nach einem Urlaub wirklich mal vergesse, Display und WLAN auszuschalten, gehen die nach spätestens einer Woche automatisch aus.
Aktuell zeichne ich die Feuchtigkeit innen und außen auf - wenn es tatsächlich regelmäßig passiert, dass die Luftfeuchte außen geringer ist als innen, wäre das ein Ansatzpunkt für eine Erweiterung: einen Lüfter anschalten, um die trockenere Luft von außen auch nach innen zu befördern und den Wohnwagen ganz ohne Chemie trocken zu halten.
rkopka am 12 Apr 2021 21:08:35
Elmi79 hat geschrieben:In den Tiefschlaf schicke ich den ESP nicht, aber mit ausgeschaltetem WLAN und deaktivertem SSD1306 Display schafft der es im Leben nicht, den mit 100 W Solar betriebenen 30-Ah-Akku leerzusaugen. Und für den Fall, dass ich nach einem Urlaub wirklich mal vergesse, Display und WLAN auszuschalten, gehen die nach spätestens einer Woche automatisch aus.
Da bin ich schon näher an die Grenze gekommen. 95Ah und 200Wp, aber neben dem ESP32 noch ein LTE WLAN Router. Nach Wochen im letzten Herbst fast ohne Solarertrag, da immer Nebel und trüb, mußte ich meine Anlage abschalten, weil die Batterie zu weit absank. Allerdings war das ein Schnellschuß zum Testen, daher wird der Router nicht geschaltet. Beim ESP32 geht das auch nicht, da der externe Sensor über ESPNow sendet. Dann wäre man eher im Grünen mit dem Stromverbrauch. Vor allem, wenn man nur selten Daten überträgt.
