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

@homoran

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

@opensourcenomad

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

@opensourcenomad

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

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.

@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

@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

@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

@opensourcenomad

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

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

@homoran

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

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

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

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?