Shelly als EV-Lader in Venus OS / Cerbo GX – DBus-Integration mit PV-Überschuss-Automatik

Elektrik, DIY, Softwareprojekte, Neue Ideen Open Source - Software Projekte
1

Ich möchte hier mein Wallbox-Skript für Victron Venus OS vorstellen:

Das Projekt bindet einen Shelly-Aktor als EV-Charger in Venus OS ein. Dadurch erscheint die Wallbox direkt in der Victron GUI und im VRM-Portal. Sie kann manuell oder per PV-Überschuss-Automatik gesteuert werden.

Ein paar Punkte, die mir bei der Umsetzung wichtig waren:

  • lokale Kommunikation, keine Shelly-Cloud nötig
  • native Einbindung über DBus (Daher kann die Steuerung z.B. auch über MQTT in Home Assistant eingebunden werden.)
  • Auto-Modus mit PV-Überschuss, Netzbezug und Batterie-SOC
  • robuste Architektur mit separatem Helper-Prozess, damit DBus-/Netzwerkprobleme nicht gleich den Hauptdienst blockieren
  • Schutz der GX-Hardware durch RAM-basierte Runtime-Daten statt unnötiger Flash-Schreibzugriffe
  • Logging und Tests für Fehlerfälle wie Timeouts, fehlende Werte und unstabile Eingangsdaten

Außerdem gibt es Installations- und Deinstallationsskripte für Venus OS.

Vielleicht ist es für den einen oder anderen interessant, der eine einfache EVSE bzw. einen Ladeziegel über Shelly in ein Victron-System integrieren möchte.

Das Projekt ist auf github unter martinthebrain/dbus-shelly-evcharger zu finden.

Update 17. April 2026: Das Projekt ist inzwischen deutlich breiter als die ursprüngliche Shelly-/Ladeziegel-Beschreibung. Neben Shelly-basierten Relay-Pfaden unterstützt es heute auch native Charger-Integrationen, konfigurierbare HTTP-/Modbus-Adapter, Split-/Combined-Topologien, externe Phasenumschaltung sowie Manual-, Auto- und Scheduled-/Plan-Modi auf Venus OS.

2 „Gefällt mir“
2

Danke für die Vorstellung und den sicherlich hohen Aufwand.

Ich persönlich habe mich allerdings von solchen Individual-Lösungen verabschiedet, da sie aus meiner Sicht langfristig schwer wartbar sind und für Dritte kaum nachvollziehbar bleiben. Gerade wenn später jemand anderes auf das System schaut, wird es schnell unübersichtlich, wenn Logik in eigenen Skripten steckt.

Mit Node-RED ist man zwar nicht maximal performant und auch „nur“ im Community-Support unterwegs, aber dafür sind die Abläufe direkt sichtbar. Über das Victron VRM Portal erkennt man sofort, dass Node-RED im Einsatz ist, und einfache Flows lassen sich schnell verstehen und bei Bedarf anpassen.

Ein weiterer Punkt: Über virtuelle Devices ist die Darstellung für den Nutzer am Ende identisch – es macht also keinen Unterschied, ob die Logik im Hintergrund über Node-RED oder einen eigenen DBus-Service läuft.

Auch das Argument der tieferen Integration bzw. Einflussnahme auf ESS/DVCC sehe ich in der Praxis nicht als Vorteil. Diese Logiken lassen sich genauso über Node-RED auf einem Victron Venus OS umsetzen.

Beim Thema Timing erschließt sich mir der Vorteil ebenfalls nicht wirklich. Wir sprechen hier, wenn überhaupt, von Mikrosekunden. Alles, was im realen Betrieb relevant ist, lässt sich mit Node-RED genauso zuverlässig abbilden – inklusive direktem Lesen und Schreiben auf den DBus.

Auch das Argument, dass sich ein System nur über einen nativen Service wie ein „echtes Produkt“ verhält, sehe ich so nicht. Durch virtuelle Devices ist dieses Verhalten bereits vollständig abbildbar und für den Nutzer nicht von einer nativen Integration zu unterscheiden.

Subjektiv tue ich mich zudem immer etwas schwer damit, wenn die Bereitschaft fehlt, sich mit bestehenden Gegebenheiten und etablierten Lösungen auseinanderzusetzen, und stattdessen direkt eine individuelle Eigenentwicklung gebaut wird. Das ist am Ende sicher auch eine Frage der persönlichen Herangehensweise – aus meiner Sicht überwiegen dabei jedoch oft die Nachteile in Bezug auf Wartbarkeit, Nachvollziehbarkeit und langfristige Nutzbarkeit durch Dritte.

Aus meiner Sicht spricht deshalb vieles dafür, auf standardisierte und verbreitete Lösungen zu setzen. Die Integration von Shelly funktioniert zuverlässig und flexibel, unabhängig davon, ob man das Device als EV-Charger, Inverter oder anders abbildet.

3

Danke für dein Feedback, die Perspektive ist absolut nachvollziehbar.

Node-RED hat gerade bei Transparenz, schneller Anpassbarkeit und niedriger Einstiegshürde klare Stärken. Mein Ziel war allerdings ein etwas anderer Anwendungsfall, eine Lösung, die sich möglichst nah wie ein nativer EV-Charger in Venus OS verhält und danach idealerweise einfach unauffällig läuft.

Deshalb habe ich mich hier bewusst für einen dedizierten DBus-Service entschieden, vor allem wegen klarer Versionierung, Tests, reproduzierbarer Installation und der sauberen Einbindung in die von Victron vorgesehene Prozessüberwachung.

Das soll Node-RED gar nicht abwerten. Für viele Setups ist das wahrscheinlich sogar der pragmatischere Weg. Mein Projekt ist eher als Alternative für alle gedacht, die genau diesen stärker „produktartigen“ Ansatz bevorzugen.

Am Ende haben beide Wege ihre Berechtigung, je nachdem, ob der Schwerpunkt eher auf visueller Flexibilität oder auf einer möglichst gekapselten, nativen Integration liegt.

2 „Gefällt mir“
4

Danke dir für die offene und sachliche Sichtweise – dem stimme ich zu, das Ganze ist am Ende sehr subjektiv und stark vom jeweiligen Anwendungsfall abhängig.

Was ich dabei etwas kritisch sehe: Solche individuellen Lösungen können schnell auch weniger erfahrene Nutzer dazu verleiten, proprietäre oder wenig transparente Setups in ihr System zu übernehmen, ohne sie wirklich zu verstehen. Da entsteht leicht der Eindruck, man müsse das so machen, um „richtig“ unterwegs zu sein.

Gerade mit Node-RED sehe ich hier einen großen Vorteil: Ein kompletter Flow ist einfach exportier- und importierbar, visuell nachvollziehbar und in sich konsistent. Die paar nötigen Einstellungen danach sind aus meiner Sicht überschaubar – und wenn das schon eine Hürde darstellt, sollte man sich vielleicht grundsätzlich fragen, wie tief man in solche Systeme eingreifen möchte.

Ein eigenes Skript macht es aus meiner Sicht nicht automatisch besser, wenn am Ende genauso fremder Code ohne Verständnis übernommen wird – nur eben weniger sichtbar.

Aber klar: Am Ende kann man nur darauf hinweisen. Jeder ist für sein Setup selbst verantwortlich :+1:

5

Eigentlich nur beim letzteren.
Und ich sag mal, ob da jetzt eine Node-Red-Lösung läuft, oder ein Script, macht für jemanden, der sich damit nicht auskennt, keinen Unterschied. Der handelsübliche PV-Servicetechniker wird mit beidem nichts anfangen können.

Oliver

1 „Gefällt mir“
6

Ich habe den Startbeitrag ergänzt, weil das Projekt seit der ersten Vorstellung deutlich gewachsen ist. Während es ursprünglich nur auf Shelly-Relay-Pfade für Ladeziegel beschränkt war, unterstützt es nun auch native Charger-Backends, Modbus-/HTTP-Adapter, Split-/Combined-Topologien, externe Phasenumschaltung sowie Scheduled-/Plan-Logik. Wer sich den aktuellen Stand anschauen will, findet die Details im README und in den Deploy-/Konfigurationsdokus.