Wie mit ESP32 kommunizieren? (Notstrom-System)
-
TL;DR: Tasmota / ESPEasy auf ESP32-Hardware anpassen oder Firmware selbst entwickeln?
Hi Leute,
ich bin neu hier im Forum, habe aber bereits ein paar Erfahrungen mit IOBroker sammeln können und bin von der Funktions- und Adaptervielfalt begeistert.
Zu meinem Vorhaben:
Ich plane seit einigen Monaten ein Notstrom-System für eine peruanische NGO, das ich mit einem Team an Freiwilligen im September vor Ort installieren werde. Hauptkomponente ist ein Victron Energy-System mit Lithium-Speicher und Photovoltaik, dazu gibt es für längere Stromausfälle noch einen Dieselgenerator. Das Victron-System kann bequem über Modbus-TCP ausgelesen werden, das habe ich auch bereits bei meinem Vater für die Steuerung einer Wärmepumpe so umgesetzt. Der Dieselgenerator wird vermutlich auch ein Modbus-TCP Interface erhalten, um Sensorwerte und Störungsmeldungen auszulesen.Damit das System einfach zu bedienen ist und Störfälle schnell erkannt werden können soll eine Signalampel installiert werden, die Zustände wie "Netzbetrieb", "Inselbetrieb", "Niedriger Tankstand" und "Störung" visuell kommuniziert. Zur Steuerung der Ampel und zum Auslesen weiterer Signaleingänge wird ein NORVI ENET-AE06-T zum Einsatz kommen, der auf einem ESP32 (WROOM-32) basiert.
Nun stellt sich mir die Frage, wie ich am Besten mit dem ESP32 kommuniziere. Eine fertige Firmware gibt es meines Wissens nach für den NORVI nicht, entsprechend sehe ich da (für mich als Software-Entwickler) zwei Wege:
- Firmware-Projekt (Tasmota, ESPEasy, ...) auf NORVI anpassen
- Eigene Firmware entwickeln
Die Logik zur Ansteuerung der Ampel soll in IOBroker liegen, meine Anforderungen an die Firmware sind daher recht niedrig:
- Kommunikation über Ethernet
- Inputs (digital) auslesen
- Outputs (digital) auslesen und schalten
Daher meine Frage an die erfahrenen Bastler: Welchen Weg würdet ihr beschreiten, womit habt ihr gute Erfahrungen gesammelt?
-
@philipptrenz said in Wie mit ESP32 kommunizieren? (Notstrom-System):
entsprechend sehe ich da (für mich als Software-Entwickler) zwei Wege:
Oder den dritten und wahrscheinlich einfachsten Weg? Wenn du mit minimalen Einsatz maximalen Erfolg erzielen willst kann ich dir esphome wärmstens empfehlen. Für dich als Software-Entwickler wahrscheinlich erst einmal verwirrend mit der yaml-Syntax aber wenn dir das zu trivial ist kannst du in esphome auch jederzeit lambdas verwenden.
Ich erinnere ich das mal jemand im esphome discord ein mit fossilen Brennstoffen betriebenes Stromaggregat um einen autostart mittels esphome veredelt hatte
Mit PVbrain gibt es auch eine interessantes Projekt welches sich vielleicht sogar für euer Vorhaben eignen könnte?
PVbrain is an opensource/openhardware project to monitor/control simultaneously a PIPsolar/Voltronic Inverter (most of) and a BMS (JKBMS/AntBMS/DalyBMS). It adds also the possibility to control up to 16 relay allowing for example to control an Automatic Transfert Switch (ATS) (Offgrid<=>return to grid). The PCB board uses only crossing components or pluging ones in order to have an easy setup/maintenance. The MCU used is an ESP32 running ESPhome
die Zustände wie "Netzbetrieb", "Inselbetrieb", "Niedriger Tankstand" und "Störung" visuell kommuniziert.
Eventuell eignet sich da auch ein Display (oder zumindest zusätzlich) da dieses die Zustände "leserlich" und daher leicht verständlich darstellen kann. Unterstütze Displays gibt es ja bei esphome zuhauf, ich bin von den guten alten LCD Displays da diese sehr gut ablesbar sind, aber vielleicht reicht auch so ein kleines billigst oled display, zwar nicht von weitem lesbar aber wenn die Ampel auf rot ist hätte man ja einen guten Grund ein Schritt auf's Display zuzugehen
Die Logik zur Ansteuerung der Ampel soll in IOBroker liegen
Aus welchem Grund? Ist die "Ampel" (Leds?) nicht direkt am esp angeschlossen? Ich würde so essentiellen Funktion immer direkt in esphome umsetzen um nicht irgendwelche Abhängigkeitskaskaden (Netzwerk, Server, etc.) angewiesen zu sein. Bei mir gilt immer alle Basis-, Geräte- und Sicherheitskritischefunktionen direkt auf dem esp (mit esphome wahrlich auch ein Kinderspiel) zu haben, die Zentrale ist dann noch für Geräteübergreifenden Komfortfunktionen vorhanden und für einen "Basisbetrieb" nicht essentiell.
Welchen Weg würdet ihr beschreiten, womit habt ihr gute Erfahrungen gesammelt?
ESPHome is a system to control your ESP8266/ESP32 by simple yet powerful configuration files and control them remotely through Home Automation systems.
ich mit einem Team an Freiwilligen im September vor Ort
Dann lass dir mal ceviche und den pisco sour schmecken
-
Hi @opensourcenomad, danke für deine schnelle Antwort!
Oder den dritten Weg und wahrscheinlich einfachsten Weg? Wenn du mit minimalen Einsatz maximalen Erfolg erzielen willst kann ich dir esphome wärmstens empfehlen.
Du hast völlig recht! Ich hab mich eben noch mal nach Alternativen umgesehen und habe dabei ESPHome wieder entdeckt. Tatsächlich habe ich schon mal ein Projekt damit umgesetzt und die Definition in YAML-Files ist mir sogar sehr sympathisch!
Mit PVbrain gibt es auch eine interessantes Projekt welches sich vielleicht sogar für euer Vorhaben eignen könnte?
Danke für den Tipp! Die Intelligenz übernimmt aber bereits das Victron-System, auch Generator-Start und -Stop werden darüber getriggert. Und es gibt dazu auch ne schicke Aufbereitung im Web. Bin großer Fan von deren Produkten und ihrer Open Source Strategie. Könnte dir deinem Nutzernamen nach auch gefallen
Ich würde so essentiellen Funktion immer direkt in esphome umsetzen um nicht irgendwelche Abhängigkeitskaskaden (Netzwerk, Server, etc.) angewiesen zu sein.
Die LEDs der Ampel hängen direkt am ESP, nur die Daten kommen übers Netzwerk
Die Auswertung der beiden Systeme direkt auf dem ESP32 zu machen habe ich auch schon überlegt, aber die Infos der beiden Systeme über Modbus-TCP auf dem ESP auszuwerten stelle ich mir mindestens schwierig vor.
Nachdem es nur eine Visualisierungskomponente ist und nicht die Funktion des Systems selbst beeinflusst ist die Abhängigkeit von IOBroker aus meiner Sicht zu rechtfertigen.
Zudem ist so eine Anpassung der Logik in IOBroker auch remote etwas einfacher als neue Firmware zu flashen. Ich werde ja nur für begrenzte Zeit in Peru vor Ort sein können.Eventuell eignet sich da auch ein Display (oder zumindest zusätzlich) da dieses die Zustände "leserlich" und daher leicht verständlich darstellen kann.
Das Victron-System verschickt im Fehlerfall Mails, aber die Idee mit dem Display finde ich gut! Das NORVI ENET hat ja ein eingebautes OLED, ich werde mal sehen ob ich das mit ESPHome zum Laufen bekomme
Dann lass dir mal ceviche und den pisco sour schmecken
Danke dir, das werde ich auf jeden Fall! Vielleicht gibts auch ein Cuy auf den Teller
-
@philipptrenz sagte in Wie mit ESP32 kommunizieren? (Notstrom-System):
Hauptkomponente ist ein Victron Energy-System mit Lithium-Speicher und Photovoltaik,
warum wohnst du so weit weg?
ich suche seit Monaten (Jahren) jemanden, der mir das baut
-
warum wohnst du so weit weg?
ich suche seit Monaten (Jahren) jemanden, der mir das baut@homoran Ich kenne dein Leid! Mein Vater arbeitet in einem Installationsbetrieb für PV und die ertrinken in Anfragen. Ohne Material und fair bezahlte Fachkräfte wird das echt schwierig mit der Energiewende ...
-
@philipptrenz sagte in Wie mit ESP32 kommunizieren? (Notstrom-System):
und die ertrinken in Anfragen
das ist inzwischen ein weiteres Problem, aber seit Jahren finde ich nur Betriebe, die Systeme nur von der Stange verkaufen (und häufig nicht einmal da verstehen was sie tun)
Victron und LiFePO4 (oder gar LiFeYPO4) sind da nur Fremdworte und verursachen Kopfschütteln.
-
@philipptrenz said in Wie mit ESP32 kommunizieren? (Notstrom-System):
Das NORVI ENET hat ja ein eingebautes OLED, ich werde mal sehen ob ich das mit ESPHome zum Laufen bekomme
Das Display wird wahrscheinlich keine Probleme bereiten... aber wie du schon sehen musstest ist der w5500 ethernet chip aktuell leider nicht unterstützt in esphome
Da bräuchte man wohl einen software entwickler der da eine Unterstützung für schaffen kann -
@philipptrenz said in Wie mit ESP32 kommunizieren? (Notstrom-System):
Zudem ist so eine Anpassung der Logik in IOBroker auch remote etwas einfacher als neue Firmware zu flashen.
Deine yaml kannst du im browser (z.B. remote in iobroker mittels esphome adapter) bearbeiten und ein klick auf update genügt um den esp ohne anfassen per ota zu bespielen
Dadurch das die ota-logik mit zwei "slots" arbeitet kann auch ein ota update ohne Probleme bei (z.B.) 50% upload abbrechen und die "alte" Version ist trotzdem noch drauf (und wird dann auch direkt wieder gestartet). Sprich das ganze sollte soweit bullet-proof sein 
Überhaupt gibt es bei esphome den Terminus "flashen" gar nicht mehr, da wird nur noch "installiert". Bin zwar kein fan davon so technische Gegebenheiten zu "verwässern", aber es trägt tatsächlich der neuen "Trivialität" bei. Selbst das initiale "installieren" (damals
flashen) ist zwischenzeitlich komplett im browser gelandet (esp web tools sei dank), irgendwelche lokalen Programme sind Geschichte, ein auf chromium basierender Browser (nur diese unterstützen aktuell web serial) genügt. Es ist sogar egal ob der usb-serial/esp am server (wo das esphome dashboard) oder am client (womit man per browser zugreift) läuft, es kann über beide Wege direkt "installiert" werden.... und wenn es einmal per Kabel geklappt hat ist der rest ja sowieso immer wireless 
(oder kabelgebunden bei ethernet 
) 
Ich habe gestern bei mir so um die 80 esphome nodes (
update-all
) auf die neuste Version gehievt und einer wollte tatsächlich nicht 
, geguckt was das für ein Gerät ist, stellt sich raus ein sonoff basic den ich vor über 3 Jahren für €4,26 erworben habe und genau einmal inital serial geflasht habe, seit 3 Jahren wird der nur mittels ota updates gefüttert und jetzt gab es zum ersten mal überhaupt ein Problem. Das Gerät hatte auch keine ota logs ausgespuckt und die angeschlossene Last nicht geschallten, also wie eingefroren (obwohl der web server gleichzeitig erreichbar war), hatte so was noch nie mit einem esp/home Gerät, wie auch immer, einmal vom Strom getrennt und das Teil hatte sich sofort "geheilt", läuft jetzt hoffentlich wieder mindestens 3 Jahre und war hoffentlich ein bug in der alten version (2021.12) die drauf war 
Die Auswertung der beiden Systeme direkt auf dem ESP32 zu machen habe ich auch schon überlegt, aber die Infos der beiden Systeme über Modbus-TCP auf dem ESP auszuwerten stelle ich mir mindestens schwierig vor.
Also ich hatte noch nie ein Modbus-TCP "in der Hand", aber wenn beides am esp zusammenläuft ist esphome dazu ja gerade prädestiniert das direkt "auszuwerten". Wenn dir die yaml-Syntax dafür nicht ausreicht kannst du (der es versteht) ja was mit lambda basteln
-
@opensourcenomad
@philipptrenz
ich rufe da mal nach @klassisch!
Der hat einen kleinen Multiplus und kennt sich auch mit ESPhome aus -
Victron und LiFePO4 (oder gar LiFeYPO4) sind da nur Fremdworte und verursachen Kopfschütteln.
Absolut richtig. Der Betrieb, in dem mein Vater seine Brötchen verdient, verbaut auch nur SMA. Mit der Preiskalkulation und dem Offgrid-Feature konnte ich ihn schließlich überzeugen auf Victron Energy zu setzen. Sein Chef kam zum Anschließen vorbei und war auch technisch angetan
-
Das Display wird wahrscheinlich keine Probleme bereiten... aber wie du schon sehen musstest ist der w5500 ethernet chip aktuell leider nicht unterstützt in esphome
Da bräuchte man wohl einen software entwickler der da eine Unterstützung für schaffen kann Ja, das hab ich entdeckt. Muss ich mal sehen, ob ich die Zeit finde da entsprechend tief rein zu tauchen. C++ ist leider nicht ganz meine Komfortzone ...
-
@philipptrenz said in Wie mit ESP32 kommunizieren? (Notstrom-System):
Zeit finde da entsprechend tief rein zu tauchen
Falls du Zeit findest (oder auch nur grob darüber nachdenkst) solltest du dich unbedingt mit den devs im esphome discord (#dev channels) kurzschließen, diese sind sehr auf Zack und hilfsbereit. Der (Vollzeit)-Hauptentwickler z.B. ist die ganze Nacht online (ein
-er) 
-
Deine yaml kannst du im browser (z.B. remote in iobroker mittels esphome adapter) bearbeiten und ein klick auf update genügt um den esp ohne anfassen per ota zu bespielen
Dadurch das die ota-logik mit zwei "slots" arbeitet kann auch ein ota update ohne Probleme bei (z.B.) 50% upload abbrechen und die "alte" Version ist trotzdem noch drauf (und wird dann auch direkt wieder gestartet). Sprich das ganze sollte soweit bullet-proof sein Das hört sich tatsächlich großartig an. Die Definition von Software- und Hardware-Funktionen in statischen Files ist ja ein Phänomen, das zunehmend in der ganzen IT-Branche zu finden ist. Infrastructure as Code, wie z.B. mit Ansible, ist da eins von vielen guten Beispielen. Automatisierung, Dokumentation und Versionierung an einem Ort – alles was sich ein Entwickler wünscht!
Also ich hatte noch nie ein Modbus-TCP "in der Hand", aber wenn beides am esp zusammenläuft ist esphome dazu ja gerade prädestiniert das direkt "auszuwerten". Wenn dir die yaml-Syntax dafür nicht ausreicht kannst du (der es versteht) ja was mit lambda basteln
Schau ich mir auf jeden Fall genauer an
-
@opensourcenomad said in Wie mit ESP32 kommunizieren? (Notstrom-System):
Falls du Zeit findest (oder auch nur grob darüber nachdenkst) solltest du dich unbedingt mit den devs im esphome discord (#dev channels) kurzschließen, diese sind sehr auf Zack und hilfsbereit. Der (Vollzeit)-Hauptentwickler z.B. ist die ganze Nacht online (ein
-er) Werde ich gleich mal machen
-
@philipptrenz und bzgl. ethernet, ich habe 4 unterstütze ethernet boards (LAN8720) in der Schublade, konnte mich aber noch nicht durchringen mal wenigstens einen irgendwo zu installieren
Alle meine (ca. 80 produktiven) esphome nodes sind tatsächlich alle per WLAN (teilweise auch über repeater) verbunden und laufen (trotzdem) super stabil. Aber Luft ist ja bekanntlich ein "shared-medium" und wer in Ballungsgebieten (nicht mein Terrain 
) wohnt hat eventuell andere Erfahrungen... "your mileage may vary" 
-
@opensourcenomad said in Wie mit ESP32 kommunizieren? (Notstrom-System):
@philipptrenz und bzgl. ethernet, ich habe 4 unterstütze ethernet boards (LAN8720) in der Schublade, konnte mich aber noch nicht durchringen mal wenigstens einen irgendwo zu installieren
Alle meine (ca. 80 produktiven) esphome nodes sind tatsächlich alle per WLAN (teilweise auch über repeater) verbunden und laufen (trotzdem) super stabil. Aber Luft ist ja bekanntlich ein "shared-medium" und wer in Ballungsgebieten (nicht mein Terrain ) wohnt hat eventuell andere Erfahrungen... "your mileage may vary" Als Mensch, der sich zwischenzeitlich mit jedem Layer des IP-Stacks intensiver auseinander gesetzt hat, halte ich IoT über IEEE 802.11 nur für bedingt sinnvoll. Thread könnte da ein game changer werden.
Aber vor allem sind 2,4 und 5 GHz in Peru die Frequenzen, über die unzählige "Wireless Internet Service Provider" ihr Internet verteilen. Und um Leistungsbegrenzung für Antennen schert sich da niemand -
@philipptrenz said in Wie mit ESP32 kommunizieren? (Notstrom-System):
mit jedem Layer des IP-Stacks intensiver auseinander gesetzt hat, halte ich IoT über IEEE 802.11 nur für bedingt sinnvoll.
In der Tat, der overhead ist beachtlich
Ich freue mich schon auf den Tag an dem esphome esp-now im stable hat. Hatte ich schon mal getestet und das ist wirklich beeindruckend, hier gibt es ein ganz nettes (marketing) video von espressif dazu
https://yewtu.be/watch?v=QmvMtgNs9r8
Dies Demonstration hier von 2019 finde ich auch ziemlich beeindruckend https://hackaday.io/project/161896-linux-espnow/log/168678-1khz-closed-loop-control-of-up-to-16-motors-over-wifiThread könnte da ein game changer werden.
Passenderweise gibt es morgen Abend einen vielleicht ganz interessanten "workshop" welcher zwar nicht direkt Thread zum Thema hat, aber dessen "Unterbau" matter
eingesetzte Hardware ein esp32-c3 (RISC-V 
) https://www.home-assistant.io/blog/2022/05/29/matter-in-home-assistant-workshop-announcement/Aber vor allem sind 2,4 und 5 GHz in Peru die Frequenzen, über die unzählige "Wireless Internet Service Provider" ihr Internet verteilen. Und um Leistungsbegrenzung für Antennen schert sich da niemand
Ich war leider schon wieder viel zu lange nicht mehr in Südamerika, meine Erfahrung außerhalb von Bolivien und Peru waren aber das die bereits schon vor 10 Jahren (in der Zeit wurde im Neuland noch VDSL "ausgebaut") schon voll auf Glasfaser bis in die Hütte gesetzt haben. So ganz pragmatisch zusammen mit der Oberleitung für Strom und dann kleines Löchlein in den Fensterrahmen gebohrt und da lief dann gleich alles drüber: TV, Telefon, Internet (Fax konnte das glaube ich noch nicht damals
). Aber in den großen weiten des Amazonas-Regenwald wird wahrscheinlich sehr viel gefunkt 
-
@opensourcenomad said in Wie mit ESP32 kommunizieren? (Notstrom-System):
Passenderweise gibt es morgen Abend einen vielleicht ganz interessanten "workshop" welcher zwar nicht direkt Thread zum Thema hat, aber dessen "Unterbau" matter
eingesetzte Hardware ein esp32-c3 (RISC-V ) https://www.home-assistant.io/blog/2022/05/29/matter-in-home-assistant-workshop-announcement/Oh spannend, vielleicht schau ich da morgen mal rein!
Ich war leider schon wieder viel zu lange nicht mehr in Südamerika, meine Erfahrung außerhalb von Bolivien und Peru waren aber das die bereits schon vor 10 Jahren (in der Zeit wurde im Neuland noch VDSL "ausgebaut") schon voll auf Glasfaser bis in die Hütte gesetzt haben. So ganz pragmatisch zusammen mit der Oberleitung für Strom und dann kleines Löchlein in den Fensterrahmen gebohrt und da lief dann gleich alles drüber: TV, Telefon, Internet (Fax konnte das glaube ich noch nicht damals
). Aber in den großen weiten des Amazonas-Regenwald wird wahrscheinlich sehr viel gefunkt Tatsächlich haben die größtenteils den Kupfer-Quatsch übersprungen, wir haben auf dem Gelände auch Glasfaser. Nur ist das für die wenigsten der Einheimischen erschwinglich. Daher hängen an den Glasfaserleitungen vor allem Schüsseln, die den Anschluss dann großzügig gegen kleines Entgelt verteilen
Ich bin übrigens im Hochland unterwegs
-
Für diejenigen, die über diesen Thread stolpern:
Nach langer Recherche musste ich feststellen, dass aufgrund verschiedener Inkompatibilitäten IoT-Projekte wie ESPEasy und ESPHome kein kabelgebundenes Ethernet mittels W5500 Chipsatz anbieten. Dementsprechend habe ich selbst etwas entwickelt: https://github.com/philipptrenz/Norvi-Enet-Modbus
Dort sind auch ein paar der Probleme mit den Inkompatibilitäten zwischen Arduino und ESP32 Core erläutert.
