aqua
luftfederung

ESP32, 8266, Arduino und Co


rkopka am 26 Jan 2020 20:27:42

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.

RK

Anzeige vom Forum

Hier findest Du vielleicht schon, was Du suchst: --->Link

Elmi79 am 27 Jan 2020 11:06:52

So, dann darf ich meine Lösung mal vorstellen. Benötigt wird lediglich ein ESP32 (im Schaltplan nicht mit dargestellt) mit ein wenig Zusatzbeschaltung:

Bild

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
Code: --> Link
http://192.168.1.1
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!

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.

mit jQuery z.B.:
Code: --> Link
var timeUri = "/time.json";
jQuery.post(timeUri, { time: new Date().getTime() });

und am Gerät macht time.json etwa das (hier in PHP und gekürzt):
Code: --> Link
if ($_SERVER["REQUEST_METHOD"] == "POST" && $_REQUEST["time"])
{
    $time = gmstrftime("%c", $_REQUEST["time"] / 1000);
    sudo("/bin/date -u -s '$time'");    //Linux cmd
}

RK

Solarcomputer am 29 Jan 2020 11:32:09

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.
Code: --> Link
time (Server): 2020-02-03 09:56:27 (1580720187)

Letzter Status: 2020-02-03 09:55:23 (1580720123)
Time seit letztem Status: 64sek. -> 0:1:4

alive=1
Time(Womo): 2020-02-03 09:55:24 (time=1580720124 )
rssi=-23
logfilelength=1838
logfilewritten =1580719532
timediff=3600
ontime=4800 sek. -> 1:20:0
version=2000
temperature=5.6
humidity=59.2
light=332
ubatt=13.69

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:
Bild

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.

Bild
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.
Bild
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

  • Die neuesten 10 Themen
  •  
  • Die neuesten 10 Reiseberichte
  • Die neuesten 10 Stellplätze

Ersatzrad auf der Anhängerkupplung?
keine Schrauben zu kriegen .. und nun?
Alle Rechte vorbehalten ©2003 - 2020 AGB - Datenschutzerklaerung - Kontakt