openWB: Display unusable in EVCC-managed setup (missing primary display URL)

[andreasgapsch]

Description
I am using one openWB Pro and one openWB Series 2+, both equipped with 7" displays.

When the wallboxes are configured in secondary mode and managed by EVCC, the openWB display logic expects a URL provided by the primary system to be rendered on the local display.

However, EVCC does not provide such a display URL, which leads to the following behavior:

• An error occurs while resolving the display destination
• The display turns grey
• The display becomes unusable (no fallback or error handling)

The issue appears to originate from the display URL construction logic here:

🔗 Code reference:
https://github.com/openWB/core/blob/210f17b47811e6c38c0cdbb66c92fd87202912b4/web/display/processAllMqttMsg.js#L50

// retrieve display theme from primary
host = data["openWB/internal_chargepoint/global_data"]["parent_ip"];

const queryObject = {
  // we need our own ip address for status information
  localIp: data["openWB/system/ip_address"],
  // we need to know the current branch, commit and version
  localBranch: data["openWB/system/current_branch"],
  localCommit: data["openWB/system/current_commit"],
  localVersion: data["openWB/system/version"],
  // we need to know how to map local charge points to primary
  parentChargePoint1: data["openWB/internal_chargepoint/0/data/parent_cp"],
  parentChargePoint2: data["openWB/internal_chargepoint/1/data/parent_cp"]
};

query.append("data", JSON.stringify(queryObject));

// load display from primary or local
destination = `${location.protocol}//${host}/openWB/web/display/?${query.toString()}`;
addLog(`all done, loading theme from primary`);

// no iframe here as this would result in another nesting with the wrapper on primary

Describe alternatives you've considered
We asked openWB to make this more flexibel in OpenWB itself bat they refused.

Additional context
Some discussion on that page: https://forum.openwb.de/viewtopic.php?t=10096

[andig]

the openWB display logic expects a URL provided by the primary system to be rendered on the local display.

Was genau meinst Du damit und warum sollte evcc etwas "providen"? Zu welchem Zweck und was fehlt konkret?

Soweit ich weiss, gibts auf der OpenWB eine ENV Variable die angibt, welche URL im UI dargestellt werden soll. Die muss dann gesetzt werden.

[premultiply]

Und selbst falls sie fix wäre könntest du schnell einen minimalen HTTP-Dienst unter dieser URL laufen lassen und einen Redirect auf die evcc UI dort ausliefern.

[andig]

/cc @snaptec

[SmaMa82]

/cc @snaptec

Das ist das alte openWB 1.x. das neue findest du hier: https://github.com/openWB/core

[snaptec]

Entweder wie von premultiply einen http Dienst als Redirect aufsetzen.
Im EVCC die URL anpassen (keine Ahnung ob das geht)
Alternativ wurde ja um PR gebeten.

Ich habe dennoch erhebliche Bedenken bzw Seiteneffekten wenn zuviele Ressourcen durch das UI in Anspruch genommen werden.
Gilt es aber schlicht zu testen.

Feel free, dir stehen mehrere Lösungswege zur Verfügung.

[andreasgapsch]

OpenWB hat in einem anderen Beitrag bereits abgelehnt, etwas anderes als das Default-Theme auf der OpenWB zu unterstützen, mit der Begründung, dass Performance-Probleme zu erwarten seien, welche die Wallbox einschränken würden. Aus meiner Sicht ist das eher ein vorgeschobenes Argument und passt leider nicht ganz zu dem Anspruch, wirklich Open Source und offen zu sein, wie es kommuniziert wird. Die Einschränkung ist zudem technisch sehr hart umgesetzt.

Ich habe gestern EVCC in einem separaten LXC-Container installiert und werde heute versuchen, das Ganze mittels eines 302-Redirects über einen kleinen HTTP-Server umzubiegen. Das ist allerdings vor allem für Nutzer, die EVCC beispielsweise im Home-Assistant-Integrated-Mode betreiben, wenig praktikabel. Wer möchte schon einen zusätzlichen kleinen HTTP-Server neben EVCC auf seinem Home Assistant betreiben. Wenn EVCC dies nativ bereitstellen könnte, wäre das deutlich einfacher, auch für weniger versierte Benutzer wie mich.

[premultiply]

Was hat evcc mit der OpenWB-Software zu tun?
Das ist ein Ladepunkt wie jede andere WB auch.
Wozu sollte dazu irgendein Custom-HTTP-Zeug ausgerechnet von evcc angeboten werden?
Einen minimalen HTTP-Server für die eigenen Bedürfsnisse zu bauen ist nun wirklich kein Kunststück aber in evcc hat das dennoch nichts verloren - zumal der integrierte Webserver für UI & Services auch auf einem anderen Port läuft.

[andreasgapsch]

Wenn evcc eine Wallbox offiziell unterstützt, dann besteht aus Anwendersicht zu Recht die Erwartung, dass diese Unterstützung nicht nur das reine Laden abdeckt, sondern die vorhandenen Fähigkeiten der Hardware sinnvoll nutzt. Dazu gehören auch integrierte Displays oder lokale Bedien- und Visualisierungsmöglichkeiten, sofern diese technisch vorgesehen sind.

Gerade für bestehende openWB-Nutzer ist das relevant. Wenn beim Umstieg auf evcc zentrale Funktionen oder das bekannte Bedienkonzept faktisch verloren gehen, wird der Wechsel unattraktiv oder unnötig komplex. In der Praxis führt das dazu, dass Nutzer anfangen, eigene Workarounds zu bauen, etwa um Statusinformationen wieder auf einem Display darzustellen. Das ist weder effizient noch im Sinne eines sauberen Ökosystems.

Es geht dabei nicht zwingend darum, dass evcc selbst einen zusätzlichen oder „Custom“-HTTP-Server für openWB bereitstellen muss. Ein klarer Dokumentationshinweis, eine empfohlene Integrationsmöglichkeit oder ein offiziell beschriebener Ansatz würden bereits helfen. Ziel wäre, einen konsistenten Weg aufzuzeigen, statt dass jede ehemalige openWB-Installation ihre eigene, inoffizielle Lösung entwickelt.

Zur Klarstellung: evcc „hat nichts mit der openWB-Software zu tun“ ist technisch korrekt, greift aber zu kurz. Faktisch adressiert evcc dieselbe Nutzergruppe und dieselbe Hardwareklasse. Wenn eine Wallbox mehr kann als ein generischer Ladepunkt, dann sollte eine deklarierte Unterstützung diese Fähigkeiten zumindest berücksichtigen oder transparent machen, warum sie bewusst nicht genutzt werden.

Kurz gesagt: Keine Forderung nach „Custom-HTTP-Kram“ in evcc, aber sehr wohl eine Erwartung an vollständige, realitätsnahe Unterstützung und saubere Dokumentation. Alles andere erhöht die Migrationshürden unnötig und schwächt die Attraktivität von evcc für openWB-Bestandsnutzer.

[premultiply]

Puh...

[andig]

Kurz gesagt: Keine Forderung nach „Custom-HTTP-Kram“ in evcc, aber sehr wohl eine Erwartung an vollständige, realitätsnahe Unterstützung und saubere Dokumentation

Da haben wir ja echt Glück gehabt 😂

[andreasgapsch]

Kurz um... Ich versuch was zum Laufen zu bringen und hoffe wir können die Lösung dann diskutieren und evtl. in die Doku mitaufnehmen. Problematisch ist glaube Ich, dass es nicht nur den Webserver braucht, sondern per MQTT auch alle 60sek die Master IP bereitgestellt werden muss. Ich werde berichten, ob ich es mit meinen beschränkten Kenntnissen einigermassen hinbekomme...

[andreasgapsch]

Also… ich hab das Ganze mal getestet. Und ehrlich: es ist eine ziemliche Katastrophe.

Ich habe, wie in den Foren beschrieben, per Nginx einen Redirect auf Port 80 und 443 auf die EVCC-Webseite (Port 7070) gebaut. Das lief technisch einwandfrei.

Zusätzlich habe ich einen Job eingerichtet, der alle 30 Sekunden per openWB HTTP API den Heartbeat sowie die Parent-/Master-IP setzt. Auch das funktioniert, aber nicht persistent: Die openWB überschreibt die Werte nach ca. 1–2 Sekunden wieder, sodass am Ende erneut sowas steht: {"heartbeat":1766524618.92118,"parent_ip":null}

Ich glaube daher, das ist ein Holzweg und schlicht viel zu kompliziert für etwas, das eigentlich trivial sein müsste.

Die einzige realistische Alternative wäre vermutlich, die SD-Karte zu ziehen, die Zertifikats-/SSH-Daten (bzw. einen eigenen SSH-Key) zu hinterlegen, sich dann per SSH zu verbinden und das Verhalten hart zu patchen (z.B. das Display direkt auf EVCC zu routen), statt diese Topic-Werte ständig gegen die openWB-Logik „zu verteidigen“.

[andig]

Soweit ich weiss, gibts auf der OpenWB eine ENV Variable die angibt, welche URL im UI dargestellt werden soll. Die muss dann gesetzt werden.

[andig]

Pragmatisch inwiefern? Wenn du willst kannst du evcc direkt auf der Box betreiben.

[premultiply]

Da dies mit einer externen Lösung im Handumdrehen umsetzbar ist halte ich alles andere für unverhältnismäßig.

Uns ist sehr an sauberen, gradlinigen Lösungen gelegen.

[andreasgapsch]

Ich habe zwei OpenWB Boxen mit Display. Entsprechend möchte Ich eine Zentrale Instanz, welche auch zentral verwaltet und verwaltet werden kann. Auf der Hardware von OpenWB selbst sehe Ich es nicht, auch aus Garantie und Lastgründen.

Die Frage ist daher, ob EVCC die Parent IP und Hartbeat wie die ${location.protocol}//${parent_ip}/openWB/web/display/index.html bzw. den redirect bereitstellen könnte?

[premultiply]

Nutze einen Mini-HTTP-Handler der unter dieser Adresse antwortet und nur einen Redirect zum evcc-UI ausgibt. Fertig.

Das hatten wir aber nun schon ein paar Mal...

[andreasgapsch]

Wäre das evtl. nicht was für die dokumentation von EVCC? Als Advanced ergänzung, wie es am besten geht?

[andreasgapsch]

Es gibt nun eine Lösung:

1. DNS Eintrag setzten
Ich habe im AdGuard zwei DNS Rewrite regeln für null definiert.

2. Nginx proxy, welche die requests auf den EVCC weiterleitet.
Nginx installieren
sudo apt update sudo apt install -y nginx

Redirect-Site anlegen
sudo tee /etc/nginx/sites-available/null-redirect >/dev/null <<'EOF' server { listen 80 default_server; listen [::]:80 default_server; # egal welcher Host kommt (null / null.home / IP) -> redirect server_name _; location / { return 302 http://192.168.1.34:7070$request_uri; } } EOF

Default-Site entfernen und Redirect aktivieren
sudo rm -f /etc/nginx/sites-enabled/default sudo ln -sf /etc/nginx/sites-available/null-redirect /etc/nginx/sites-enabled/null-redirect

Config testen + nginx neu laden + Autostart
sudo nginx -t sudo systemctl reload nginx sudo systemctl enable --now nginx

Tests
curl -I http://192.168.1.34/ curl -I -H "Host: null" http://192.168.1.34/ curl -I -H "Host: null.home" http://192.168.1.34/

Logs (falls Debug nötig und zum check ob request kommt)
sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log

Ich bin ehrlich gesagt schockiert, was das für ein riesen grosser Mist ist, nur weil sich OpenWB hier weigert es einfach zu machen. Das UI ist Pfeilschnell und verursacht sicher keine Probleme. Das ganze läuft schneller wie das Original. Wär die Box nicht an der Wand und würde ich es nicht so schätzen einzelne Komponenten auszutauschen, würde Ich sie auf den Müll hauen... :-)

[andreasgapsch]

So ganz verstehe ich es aber nicht.

Warum nutzt du dann nicht einfach ein anderes Standard-Image nur mit evcc und einem Kiosk-Browser auf der Box? Dann könntest du dir viele Verrenkungen sparen.

Ich will EVCC zentral auf meinem Proxmox laufen haben. Die OpenWB's wurden zu Ladepunkten degradiert. Alleine schon aus Frust über die OpenWB Entwickler... ;)

[andreasgapsch]

Das der Raspberry zu schwach ist eine Website anzuzeigen, was immer von den openWB Entwicklern behauptet wird, war mir schon immer klar und ich würde mir auch eine einfachere Lösung wünschen.

Ich finde es traurig und unnötig, da es ein vorgeschobene Behauptung ist. Keiner erwartet, das Sie ein solches Setup supporten aber die flexibilität sollten Sie bieten. Für mich war die Flexibilität der Kaufentscheid, der hier wohl komplett abhanden gekommen ist...

[SmaMa82]

hatte da ein "nicht" in meinem Satz vergessen :D

[premultiply]

So genau kenne ich die verbaute Hardware jetzt nicht aber ich gehe doch davon aus, dass da mindestens ein Raspberry Pi 3B drin ist, oder?
Die Darstellung einer einfachen Webseite sollte damit kein größeres Problem darstellen wenn sich das Ding sonst langweilt.

Flexibilität hast du doch damit in jedem Fall jede. Könntest auch ganz Teile austauschen, hinzufügen oder stillegen.

[Subito]

Danke, dass du dir die Zeit genommen hast, das einmal aufzudröseln! Ich wäre nicht auf die Idee gekommen einfach das DNS wegzubiegen und hab schon nach Wegen gesucht die parent_ip irgendwie dauerhaft zu setzen.

[SmaMa82]

Es würde eine Lösung geben wie EVCC ohne Anpassungen an openWB das EVCC Frontend auf dem Display der openWB anzeigen kann. Dazu sind zwei Dinge notwendig:

1. EVCC muss seine eigne IP und Port als parent_ip der openWB bereitstellen. Allerdings setzt openWB bei jeder Modbusanfrage durch EVCC die parent_ip auf "null". 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](https://github.com/openWB/core/blob/86a39069cde3b434afe0cb980910c189ccfb1b65/packages/helpermodules/modbusserver.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](https://github.com/evcc-io/evcc/blob/9eba13.../charger/openwb-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".

über der Terminal von MacOS geht das so:
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

2. EVCC muss die passende URL bereitstellen. Das Frontend von openWB baut die URL so zusammen: ${location.protocol}//${parent_ip}/openWB/web/display/...
   EVCC müsste diese URL dann bedienen.

[SmaMa82]

Idee zur Lösung von Punkt 2:
EVCC müsste diese Datei bereitstellen (/openWB/web/display/index.html) welche relativ auf die EVCC Adresse zeigt.

<!DOCTYPE html>
<html lang="de">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="refresh" content="0; url=../../../../">
    <title>Weiterleitung</title>
</head>
<body>
</body>
</html>

Sehe ich das richtig, das diese Datei hier liegen müsste?:
evcc/assets/openWB/web/display/index.html