EVCC auf Display anzeigen - Anleitung

[ChristianM]

EVCC lauffähig auf OpenWB (mit oder ohne Display) gibt es schon:

https://github.com/evcc-io/evcc/pull/21984

und follow-ups (suche: openwb)

Funktioniert das dann auch mit einer der älteren Duo? Und kann diese dann in mein bestehendes EVCC als Wallbox eingebunden werden?

[aiole]

Gleichzeitig sehe ich openWB nicht als Hochglanzmarke, sondern als Produkt für Menschen mit hoher Technikaffinität, einer gewissen Freude an teilweise übertriebener Gadget-Beschaffung und meist auch einem Mindset rund um Open Source, Unabhängigkeit und den Spaß am Ausprobieren neuer Dinge.

Anfänglich ja - zunehmend geht der Trend jedoch Richtung "normaler" Anwender:innen und auch gewerblicher Installationen. Die geschulten Partner und der Support übernehmen meist die Erstkonfiguration.

Entsprechend kann ich nachvollziehen, dass es als Entwickler schmerzt, plötzlich ein anderes Logo zu sehen. Gleichzeitig zeigt genau das, wie flexibel das Produkt einsetzbar ist und welche Möglichkeiten es im Vergleich zu einer rein App-gesteuerten, „dummen“ Variante bietet.

openWB "schmerzt" das sicher nicht - wird es verständlicherweise jedoch nicht forcieren. Also ich persönlich freue mich über jede modular aufgebaute WB, weil die Teile dadurch lange genutzt werden. Welche Software darauf läuft, kann jede/r frei entscheiden.

openWB steht vorrangig für lokal laufendes, open source EMS, welches kostenfrei bei jeder oWB onboard ist. Dass das EMS einer der wichtigsten Schlüssel für Unabhängigkeit und echte Energiewende ist, wird jeder/m klar, sobald man sich mit dem Thema befasst.

EVCC's Wiege steht bei openWB und sie gehen ähnliche Wege, die der Gesellschaft nützlich sind. Dennoch haben auch proprietäre Systeme ihre Vorteile, wenn z.B. Kund:innen mit nur EINEM Herstellerkosmos glücklich sind. Es wird also immer beides geben - Hauptsache sinnvolle Automatismen zur Nutzung der Regenerativen.

[Frank-H]

Funktioniert das dann auch mit einer der älteren Duo? Und kann diese dann in mein bestehendes EVCC als Wallbox eingebunden werden?

Keine Ahnung. Ich hab's bei EVCC verfolgt und aus Interesse mal versucht, aber nicht hinbekommen. Ich bin mit OpenWB soweit ziemlich zufrieden, daher diente das vornehmlich meinem Spieltrieb.

[Gero]

Also wenn ich das richtig sehe, kann ich auf einer Secondary nicht das Theme auswählen, da diese Einstellung auf von der Primary kommen muss.

Mea culpa wegen der Einstellbarkeit, da hat mich mein Erinnerungsvermögen getäuscht. Es gab hier mal jemanden mit einem Ladepark und der hat sich sein secondary-Theme angepasst oder anpassen lassen. Gibt hier irgendwo einen Thread dazu.

Wie bekomme ich das Theme zum testen auf meine OpenWB? SSH? Wie lautet da das Kennwort?

Gibt‘s gegen Aufgabe des Garantieanspruchs beim support. Kannst auch eine eigene SD-karte mit den Installationsanweisungen von github machen, da bestimmst du das passwort. So hättest du mit der originalen SD-Karte auch noch ein Fallback, falls was schief gehen sollte.

[openWB]

Besser selber installieren auf extra SD Karte.

Aber nochmal, es macht vermutlich mehr Sinn die passende URL die die openWB erwartet bereit zu stellen.
Die IP gibst du der secondary vom Master aus ohnehin vor.

Wenn das ganze Hand und Fuß hat gerne einen PR stellen.
Der sollte dann aber auch sicherstellen das das Display bei Überlast abgeschoßen wird, etc ...

[Gero]

Aber nochmal, es macht vermutlich mehr Sinn die passende URL die die openWB erwartet bereit zu stellen.

Dann gibt es doch mal mindestens zwei Display-Themes, aka URL:

IMG_2065.jpeg (96.85 KiB) 168 mal betrachtet

[LutzB]

Nö, ist nur ein Theme.

[Gero]

Es lebe der URL-Paramter.

[ChristianM]

Wie wird der Secondary denn die URL von der Primary mitgeteilt? MQTT?

[ChristianM]

Also die parent_ip kann über MQTT gesetzt werden, z.B. über das Terminal von MacOS mit installiertem mosquitto:

Code: Alles auswählen

mosquitto_pub -h 192.168.0.221 -p 1883 -t 'openWB/set/internal_chargepoint/global_data' -m '{"heartbeat": '"$(date +%s)"', "parent_ip":"192.168.0.216:7070"}' -q 2 -r

Nun gibt es aber zwei Probleme:

1. der Wert wird sofort wieder auf "null" gesetzt. Das passiert immer wenn EVCC ein Modbus-Read an die OpenWB schickt und ist so in openWB implementiert. die KI sagt dazu:

Das Verhalten passt zur gefundenen Implementierung: Wenn ein Modbus-Read an die Secondary-openWB erfolgt (Adressen > 10099, also typische openWB‑Register wie 10100 ff.), dann publiziert der openWB‑Modbus‑Server automatisch ein openWB/set/internal_chargepoint/global_data mit parent_ip: None. Das überschreibt Deine per mosquitto_pub gesetzte parent_ip und in der UI erscheint dann z.B. "unknown type" / kein gültiger Host.

Belege im Code

Modbus‑Server (auf der openWB) publisht parent_ip = None bei bestimmten Leseadressen:

Datei: packages/helpermodules/modbusserver.py
Relevanter Ausschnitt (siehe dort): Pub().pub("openWB/set/internal_chargepoint/global_data", {"heartbeat": timecheck.create_timestamp(), "parent_ip": None})
Link: https://github.com/openWB/core/blob/86a ... sserver.py
EVCC liest Modbus‑Register (typisch 10100 ff.), daher löst evccs Polling genau diese Aktion aus:

Beispiel: openwb-2.0 Registermap in openWB‑Integration von evcc
Link: https://github.com/evcc-io/evcc/blob/9e ... nwb-2.0.go (Registerbereich 10100 ...)
Warum "unknown type"?

openWB‑Frontend erwartet für internal_chargepoint/global_data ein JSON‑Objekt; wenn parent_ip null/None oder ein nicht erwarteter Typ gesendet wird, kann das UI das nicht korrekt darstellen — daher Meldung wie "unknown type".

2. Das Frontend baut die URL so zusammen: ${location.protocol}//${parent_ip}/openWB/web/display/...
Das ändern der IP bringt also nichts

EVCC könnte angepasst werden um die eigene IP und Port als parent_ip zu senden. Aber was machen wir mit der Art und Weise wie openWB die URL zusammenbaut?