NEWS
Füllstandsmessung per Pegelsonde.
Füllstandsmessung per Pegelsonde.
-
@eisbaeeer @AndyGR42 Moin, könnt ihr mir mal erläutern, wie die Konfiguration per MQTT funktioniert? Bisher stelle ich alles in im ESPEasy Menü ein und sende die Daten per MQtt an den ioBroker. Ist damit die "manuelle" Methode gemeint?
Bezüglich der analogen Eingange ist ein ADC1115 nicht schlecht, dann stehen 4 Kanäle für 0-5V zur Verfügung. So mache ich es aktuell. -
@eisbaeeer @AndyGR42 Moin, könnt ihr mir mal erläutern, wie die Konfiguration per MQTT funktioniert? Bisher stelle ich alles in im ESPEasy Menü ein und sende die Daten per MQtt an den ioBroker. Ist damit die "manuelle" Methode gemeint?
Bezüglich der analogen Eingange ist ein ADC1115 nicht schlecht, dann stehen 4 Kanäle für 0-5V zur Verfügung. So mache ich es aktuell.@bastler sagte in Füllstandsmessung per Pegelsonde.:
Bezüglich der analogen Eingange ist ein ADC1115 nicht schlecht,
Das wäre ein Workaround. Ist aber wieder ein zusätzliches Bauteil, das man beschalten müsste. Der ESP32 hat das eben schon von Haus aus drin. Bin aber gerne offen, wenn die NodeMCU Vorteile bietet. Derzeit sehe ich aber keine
-
@bastler sagte in Füllstandsmessung per Pegelsonde.:
Bezüglich der analogen Eingange ist ein ADC1115 nicht schlecht,
Das wäre ein Workaround. Ist aber wieder ein zusätzliches Bauteil, das man beschalten müsste. Der ESP32 hat das eben schon von Haus aus drin. Bin aber gerne offen, wenn die NodeMCU Vorteile bietet. Derzeit sehe ich aber keine
-
@eisbaeeer Ist die Leistungsaufnahme beim 8266 nicht deutlich geringer?
-
@andygr42 sagte in Füllstandsmessung per Pegelsonde.:
Ich ziehe in meinem Framework die Konfiguration per MQTT aus iobroker. So kann ich jederzeit Intervalle und auch den Deep Sleep Modus ändern, ohne den Sensor selbst ausbuddeln zu müssen. Gerade im Außenbereich ist der Zugang zum Sensor/ESP mitunter mit Aufwand verbunden. So kann ich z.B. auch einen Dev Modus aktivieren, um mir nicht meine Live Daten in der History mit sinnlosen Werten vollzumüllen.
Das ist natürlich noch eleganter. Ich würde die "manuelle" Methode aber trotzdem zusätzlich einbauen. Es kann ja auch passieren, dass man sich mal selbst aussperrt. Kannst du mal zeigen, welche Objekte du nutzt, um das Setup durchzuführen?
Die NodeMCU ist auch meine Basis, das einzige was mir daran nicht gefällt ist die Tatsache, dass der ESP8266 Chip nur einen A/D Wandler Eingang hat. Ich würde gerne die Batteriespannung zusätzlich überwachen. Mit der Sonde wären es dann schon zwei A/D Wandler. Ich tendiere, auch wegen dem Stromverbrauch zu einer ESP32 Node. Die hätte auch für andere Projekte genügend A/D-Wandler onboard.
Grüße@eisbaeeer sagte in Füllstandsmessung per Pegelsonde.:
Das ist natürlich noch eleganter. Ich würde die "manuelle" Methode aber trotzdem zusätzlich einbauen. Es kann ja auch passieren, dass man sich mal selbst aussperrt. Kannst du mal zeigen, welche Objekte du nutzt, um das Setup durchzuführen?
Das ist nicht die aktuellste Version, aber schon auf MQTT umgestellt: https://github.com/AndreasExner/ioBroker-IoT-Framework
Ich habe auch noch den ADS1115 in meinem Framework für weitere A/D Kanäle.
-
@eisbaeeer sagte in Füllstandsmessung per Pegelsonde.:
Das ist natürlich noch eleganter. Ich würde die "manuelle" Methode aber trotzdem zusätzlich einbauen. Es kann ja auch passieren, dass man sich mal selbst aussperrt. Kannst du mal zeigen, welche Objekte du nutzt, um das Setup durchzuführen?
Das ist nicht die aktuellste Version, aber schon auf MQTT umgestellt: https://github.com/AndreasExner/ioBroker-IoT-Framework
Ich habe auch noch den ADS1115 in meinem Framework für weitere A/D Kanäle.
@andygr42 sagte in Füllstandsmessung per Pegelsonde.:
Kannte ich noch gar nicht. Sehr geil, was du da gebaut hast. Dein Windsensor/Wetterstation könnte auch was für mich sein.
Ich muss mich mal in deinen Code einlesen. Die Basis sieht auf den Ersten Blick richtig gut aus. War auf jeden Fall viel Arbeit.Meine neuen Projekte versuche ich alle auf ESP32 zu realisieren. Grund dafür sind so Sachen wie "dual core" und SSL Fähigkeiten, die der ESP32 einfach besser kann als der schon betuchte ESP8266. Vor allem aber wenn es um SSL request geht, hat man eben keinen Block und kann das auf dem Core0 asynchron machen.
Hast du schon mal mit Vscode und Platformio gearbeitet? Scheint das ist alles auf der Arduino IDE entstanden?
-
@andygr42 sagte in Füllstandsmessung per Pegelsonde.:
Kannte ich noch gar nicht. Sehr geil, was du da gebaut hast. Dein Windsensor/Wetterstation könnte auch was für mich sein.
Ich muss mich mal in deinen Code einlesen. Die Basis sieht auf den Ersten Blick richtig gut aus. War auf jeden Fall viel Arbeit.Meine neuen Projekte versuche ich alle auf ESP32 zu realisieren. Grund dafür sind so Sachen wie "dual core" und SSL Fähigkeiten, die der ESP32 einfach besser kann als der schon betuchte ESP8266. Vor allem aber wenn es um SSL request geht, hat man eben keinen Block und kann das auf dem Core0 asynchron machen.
Hast du schon mal mit Vscode und Platformio gearbeitet? Scheint das ist alles auf der Arduino IDE entstanden?
@eisbaeeer Danke. Ja, das ist über die Zeit gewachsen
ESP32 hat auch noch den Vorteil der BLE-Unterstützung. Da bin ich jüngst drüber gestolpert. Wäre aber an der einen oder anderen Stelle zu prüfen, ob das Framework 100% kompatibel ist. Da fehlt mir gerade etwas die Zeit.Ich habe mit dem Arduino IDE begonnen und nie den Bedarf es zu ändern. Vor 14 Monaten war die 2.0 dermaßen instabil, dass ich weiter bei 1.x geblieben bin. 2.0 hätte den Vorteil der Github Integration. Aber bisher kann ich mit einem manuellen Upload auch ganz gut leben.
P.S.: ich sehe gerade, von Github bei 2.0 ist nix zu sehen. Vielleicht hab ich das auch falsch im Kopf.
-
@eisbaeeer Danke. Ja, das ist über die Zeit gewachsen
ESP32 hat auch noch den Vorteil der BLE-Unterstützung. Da bin ich jüngst drüber gestolpert. Wäre aber an der einen oder anderen Stelle zu prüfen, ob das Framework 100% kompatibel ist. Da fehlt mir gerade etwas die Zeit.Ich habe mit dem Arduino IDE begonnen und nie den Bedarf es zu ändern. Vor 14 Monaten war die 2.0 dermaßen instabil, dass ich weiter bei 1.x geblieben bin. 2.0 hätte den Vorteil der Github Integration. Aber bisher kann ich mit einem manuellen Upload auch ganz gut leben.
P.S.: ich sehe gerade, von Github bei 2.0 ist nix zu sehen. Vielleicht hab ich das auch falsch im Kopf.
-
@AndyGR42 @bastler Ich habe einen Lieferanten an der Hand, der eine Drucksonde mit Betriebsspannung 5V, Messbereich 0-3 Meter und Ausgansspannung 0-3.3V liefern kann. Also genau so, wie es der ESP verarbeiten kann. Somit benötigt man minimale, äußere Beschaltung. Ich werde mir die bestellen und meine bisherige Lösung (24V, 0-5 Meter und 2-40mA) umbauen. Mal sehen, wie sich diese Schaltung dann verhält. 2-40mA ist natürlich sehr stabil, da es nicht auf Kabellängen ankommt.
-
@eisbaeeer Moin, hört sich interessant an, was soll sie kosten? Hätte eventuell Interesse an 2 Stück. Bezüglich des Ausgangssignals sollte es eigentlich kein Problem sein, ist doch alles hochohmig. Was fehlt ist die Rückmeldung, dass die Sonde funktioniert. Beim 4-20mA Ausgang ist klar das etwas nicht stimmt, wenn der Wert unter 4mA sinkt.
-
@AndyGR42 @bastler Ich habe einen Lieferanten an der Hand, der eine Drucksonde mit Betriebsspannung 5V, Messbereich 0-3 Meter und Ausgansspannung 0-3.3V liefern kann. Also genau so, wie es der ESP verarbeiten kann. Somit benötigt man minimale, äußere Beschaltung. Ich werde mir die bestellen und meine bisherige Lösung (24V, 0-5 Meter und 2-40mA) umbauen. Mal sehen, wie sich diese Schaltung dann verhält. 2-40mA ist natürlich sehr stabil, da es nicht auf Kabellängen ankommt.
@eisbaeeer Moin. Ich komme eigentlich mit meiner Ultraschall Messung super klar. Läuft seit fast 3 Jahren ohne jeden Aussetzer
Aber wenn Du ein Datenblatt der Drucksonde hast kann ich mal schauen wie man das am besten elektrisch verschaltet. -
@eisbaeeer Moin. Ich komme eigentlich mit meiner Ultraschall Messung super klar. Läuft seit fast 3 Jahren ohne jeden Aussetzer
Aber wenn Du ein Datenblatt der Drucksonde hast kann ich mal schauen wie man das am besten elektrisch verschaltet.@andygr42 Kein Problem. Die Verschaltung ist easy going. 5V Versorgungsspannung, der Pegel wird mit 0-3,3V ausgegeben. Den kann man direkt am A/D-Wandler anschließen. Ich bin gerade nochmal am lesen von deinem Framework. Werde die nächsten Tage mal ein paar "deep-sleep" Tests fahren. Die Hardware habe ich schon rumliegen. Bisher habe ich noch kein Projekt mit umschaltbarem Modus realisiert, bei dem man per Variable zwischen "Dauermodus" und "Deep-sleep" wechseln kann. Das wird interessant und reizt mich.
-
@andygr42 Kein Problem. Die Verschaltung ist easy going. 5V Versorgungsspannung, der Pegel wird mit 0-3,3V ausgegeben. Den kann man direkt am A/D-Wandler anschließen. Ich bin gerade nochmal am lesen von deinem Framework. Werde die nächsten Tage mal ein paar "deep-sleep" Tests fahren. Die Hardware habe ich schon rumliegen. Bisher habe ich noch kein Projekt mit umschaltbarem Modus realisiert, bei dem man per Variable zwischen "Dauermodus" und "Deep-sleep" wechseln kann. Das wird interessant und reizt mich.
@eisbaeeer Der 8266 wird per Reset aufgeweckt. Das ist etwas hemdsärmelig, vereinfacht aber den Code. Ansonsten müssten nach einem längerem Sleep WLAN und MQTT wieder aufgebaut werden bevor eine Messung erfolgt. Da kann man auch einfach den ganzen ESP neu starten. Daher würde ich es mit dem ESP32 auch so machen.
Doof wird das nur bei bestimmten Sensoren wie den BME680 oder SCD30. Die müssen halt eine Weile laufen, um sich zu kalibrieren. Aber diese Sensoren dürften eh nicht für den Solarbetrieb geeignet sein, weil sie durch die permanente Messung recht viel Strom verbrauchen.
-
@eisbaeeer Moin. Ich komme eigentlich mit meiner Ultraschall Messung super klar. Läuft seit fast 3 Jahren ohne jeden Aussetzer
Aber wenn Du ein Datenblatt der Drucksonde hast kann ich mal schauen wie man das am besten elektrisch verschaltet. -
@eisbaeeer Der 8266 wird per Reset aufgeweckt. Das ist etwas hemdsärmelig, vereinfacht aber den Code. Ansonsten müssten nach einem längerem Sleep WLAN und MQTT wieder aufgebaut werden bevor eine Messung erfolgt. Da kann man auch einfach den ganzen ESP neu starten. Daher würde ich es mit dem ESP32 auch so machen.
Doof wird das nur bei bestimmten Sensoren wie den BME680 oder SCD30. Die müssen halt eine Weile laufen, um sich zu kalibrieren. Aber diese Sensoren dürften eh nicht für den Solarbetrieb geeignet sein, weil sie durch die permanente Messung recht viel Strom verbrauchen.
@andygr42 sagte in Füllstandsmessung per Pegelsonde.:
Doof wird das nur bei bestimmten Sensoren wie den BME680 oder SCD30.
Ja, da gehört der MH-Z19B und die ganzen MQ-Sensoren auch noch dazu. Die müssen am besten dauerhaft geheizt sein, damit die Werte passen. Der Stromverbrauch von diesen Kandidaten ist nicht gerade wenig. Das Thema hab ich schon mal überlegt und dann begraben.
Zum Ablauf könnte ich mir sowas vorstellen. Config-Mode kann über MQTT gesetzt werden bzw. über den Resetknopf und einem Timeout.
Verbesserungsvorschläge?
Die Konfiguration der Sensoren habe ich in anderen Projekten über Drop-down bei der Konfiguration realisiert. Ist ein mitleser dabei, der react kann? Da würde noch jemand fehlen, der sich um die Webseite kümmert
Bezüglich Zisterne könnte man dann auch verschiedene Behälter hinterlegen.
-
@andygr42 sagte in Füllstandsmessung per Pegelsonde.:
Doof wird das nur bei bestimmten Sensoren wie den BME680 oder SCD30.
Ja, da gehört der MH-Z19B und die ganzen MQ-Sensoren auch noch dazu. Die müssen am besten dauerhaft geheizt sein, damit die Werte passen. Der Stromverbrauch von diesen Kandidaten ist nicht gerade wenig. Das Thema hab ich schon mal überlegt und dann begraben.
Zum Ablauf könnte ich mir sowas vorstellen. Config-Mode kann über MQTT gesetzt werden bzw. über den Resetknopf und einem Timeout.
Verbesserungsvorschläge?
Die Konfiguration der Sensoren habe ich in anderen Projekten über Drop-down bei der Konfiguration realisiert. Ist ein mitleser dabei, der react kann? Da würde noch jemand fehlen, der sich um die Webseite kümmert
Bezüglich Zisterne könnte man dann auch verschiedene Behälter hinterlegen.@eisbaeeer Also, das kannste machen, wie du willst. Ich finde es halt praktisch, die komplette Konfiguration remote zu machen. So kann ich während der Laufzeit Intervalle ändern oder auch das Ziel der Daten (im dev Mode in andere Datenpunkte für's Debugging). Z.B. ändere ich bei der Zisterne während des Nachfüllens den Intervall auf eine Minute, während ich sonst nur alle 15 Minuten messe.
Ich muss dem Sketch nur die Device ID sowie die aktiven Sensoren mitgeben und der Rest kommt vom iobroker. Rein Theoretisch nicht mal das, wenn man die MAC Adresse auswerten und auch die Aktivierung der Sensoren remote machen würde. Das bläht aber den Code auf, da immer alle Sensoren compiliert werden müssten.
Nach der Umstellung auf MQTT werte ich mögliche Änderungen sogar bei jedem Loop aus (ca. 1x pro Sekunde), weil MQTT im Gegensatz zu meiner vorherigen HTTP/REST eh asynchron läuft. Damit kann ich viel schneller auf Änderungen reagieren.
Besonders wichtig wird das bei Aktoren. Meine Rasensprenger haben es noch nicht ins Repository geschafft. Aber das Prinzip ist das Gleiche. Das Device "zieht" sich den Befehl zu bewässern vom iobroker. Zur Sicherheit inklusive der gewünschten Dauer. Sollte die WLAN Verbindung abreißen beendet das Device die Bewässerung automatisch nach der übermittelten Zeit.
-
@eisbaeeer Also, das kannste machen, wie du willst. Ich finde es halt praktisch, die komplette Konfiguration remote zu machen. So kann ich während der Laufzeit Intervalle ändern oder auch das Ziel der Daten (im dev Mode in andere Datenpunkte für's Debugging). Z.B. ändere ich bei der Zisterne während des Nachfüllens den Intervall auf eine Minute, während ich sonst nur alle 15 Minuten messe.
Ich muss dem Sketch nur die Device ID sowie die aktiven Sensoren mitgeben und der Rest kommt vom iobroker. Rein Theoretisch nicht mal das, wenn man die MAC Adresse auswerten und auch die Aktivierung der Sensoren remote machen würde. Das bläht aber den Code auf, da immer alle Sensoren compiliert werden müssten.
Nach der Umstellung auf MQTT werte ich mögliche Änderungen sogar bei jedem Loop aus (ca. 1x pro Sekunde), weil MQTT im Gegensatz zu meiner vorherigen HTTP/REST eh asynchron läuft. Damit kann ich viel schneller auf Änderungen reagieren.
Besonders wichtig wird das bei Aktoren. Meine Rasensprenger haben es noch nicht ins Repository geschafft. Aber das Prinzip ist das Gleiche. Das Device "zieht" sich den Befehl zu bewässern vom iobroker. Zur Sicherheit inklusive der gewünschten Dauer. Sollte die WLAN Verbindung abreißen beendet das Device die Bewässerung automatisch nach der übermittelten Zeit.
@andygr42 sagte in Füllstandsmessung per Pegelsonde.:
Das bläht aber den Code auf, da immer alle Sensoren compiliert werden müssten.
Ja das ist schon richtig. Für die Leute, die sich den Code selbst comilieren ist das natürlich kein Problem.
So kann ich während der Laufzeit Intervalle ändern oder auch das Ziel der Daten (im dev Mode in andere Datenpunkte für's Debugging). Z.B. ändere ich bei der Zisterne während des Nachfüllens den Intervall auf eine Minute, während ich sonst nur alle 15 Minuten messe.
Ok, so dynamisch. Dann ist klar, dass du die Objekte über MQTT einliest. Sehr interessant.
Wenn man nur über MQTT arbeitet, benötigt man natürlich noch nicht mal eine Webseite für die Config. Einzig der MQTT-Server, MQTT-User und MQTT-Password müsste gesetzt werden.Ich fange mal auf der technischen Seite an. Deep-Sleep kann tricky sein. Da gibt es einiges zu beachten, damit der Stromverbrauch klein bleibt. Wenn das dann steht, ist der Rest nur noch Fleißarbeit.
P.S.: der ESP32 S3 hat noch einen Coprozessor, der im deep-sleep programmiert werden kann. Dieser kann dann sogar im Schlafmodus noch etwas abarbeiten.
Und wenn man den Hauptprozessor runtertaktet, läuft er auch nochmal doppelt so lange. Viel Spielraum also. -
@andygr42 sagte in Füllstandsmessung per Pegelsonde.:
Das bläht aber den Code auf, da immer alle Sensoren compiliert werden müssten.
Ja das ist schon richtig. Für die Leute, die sich den Code selbst comilieren ist das natürlich kein Problem.
So kann ich während der Laufzeit Intervalle ändern oder auch das Ziel der Daten (im dev Mode in andere Datenpunkte für's Debugging). Z.B. ändere ich bei der Zisterne während des Nachfüllens den Intervall auf eine Minute, während ich sonst nur alle 15 Minuten messe.
Ok, so dynamisch. Dann ist klar, dass du die Objekte über MQTT einliest. Sehr interessant.
Wenn man nur über MQTT arbeitet, benötigt man natürlich noch nicht mal eine Webseite für die Config. Einzig der MQTT-Server, MQTT-User und MQTT-Password müsste gesetzt werden.Ich fange mal auf der technischen Seite an. Deep-Sleep kann tricky sein. Da gibt es einiges zu beachten, damit der Stromverbrauch klein bleibt. Wenn das dann steht, ist der Rest nur noch Fleißarbeit.
P.S.: der ESP32 S3 hat noch einen Coprozessor, der im deep-sleep programmiert werden kann. Dieser kann dann sogar im Schlafmodus noch etwas abarbeiten.
Und wenn man den Hauptprozessor runtertaktet, läuft er auch nochmal doppelt so lange. Viel Spielraum also.@eisbaeeer Moin. Schaue ich mir auch an. Ich habe gerade ein par ESP32 bestellt. Beim ESP8266 ist das recht simpel. Im DeepSleep verbraucht er 10uA, was quasi nix ist. Reset erfolgt über ein GPIO Pin. Gefällt mir schon mal ganz gut
-
@andygr42 sagte in Füllstandsmessung per Pegelsonde.:
Das bläht aber den Code auf, da immer alle Sensoren compiliert werden müssten.
Ja das ist schon richtig. Für die Leute, die sich den Code selbst comilieren ist das natürlich kein Problem.
So kann ich während der Laufzeit Intervalle ändern oder auch das Ziel der Daten (im dev Mode in andere Datenpunkte für's Debugging). Z.B. ändere ich bei der Zisterne während des Nachfüllens den Intervall auf eine Minute, während ich sonst nur alle 15 Minuten messe.
Ok, so dynamisch. Dann ist klar, dass du die Objekte über MQTT einliest. Sehr interessant.
Wenn man nur über MQTT arbeitet, benötigt man natürlich noch nicht mal eine Webseite für die Config. Einzig der MQTT-Server, MQTT-User und MQTT-Password müsste gesetzt werden.Ich fange mal auf der technischen Seite an. Deep-Sleep kann tricky sein. Da gibt es einiges zu beachten, damit der Stromverbrauch klein bleibt. Wenn das dann steht, ist der Rest nur noch Fleißarbeit.
P.S.: der ESP32 S3 hat noch einen Coprozessor, der im deep-sleep programmiert werden kann. Dieser kann dann sogar im Schlafmodus noch etwas abarbeiten.
Und wenn man den Hauptprozessor runtertaktet, läuft er auch nochmal doppelt so lange. Viel Spielraum also.
Support us
62
Online32.4k
Users81.3k
Topics1.3m
Posts