Display im Secondary-Modus navigiert nach http://null (parent_ip nicht gesetzt), local-Modus nicht implementiert

[floxius3d]

Umgebung

• Gerät: openWB Pro+
• Software: 2.2.2, Branch Release
• Betriebsart: Secondary (openWB/general/extern = true)
• Steuerung: EVCC (v0.314.2) über die Pro+-HTTP-API (Port 8080, /connect.php)

Problem

Die Pro+ wird als Secondary betrieben und von EVCC geregelt — eine verbreitete Konstellation, wenn Tarifoptimierung oder ein übergreifendes Energiemanagement genutzt wird. Es existiert dabei keine primäre openWB, weil EVCC diese Rolle übernimmt.

Das integrierte Display zeigt daher dauerhaft eine Browser-Fehlerseite:

Die Website ist nicht erreichbar
Prüfe, ob „null" einen Tippfehler enthält.
DNS_PROBE_FINISHED_NXDOMAIN

Ursache

In openWB/web/display/processAllMqttMsg.js:

host = data["openWB/internal_chargepoint/global_data"]["parent_ip"];
// ...
destination = `${location.protocol}//${host}/openWB/web/display/?${query.toString()}`;
location.href = destination;

Da keine primäre openWB existiert, ist parent_ip = null. Der Wert wird ungeprüft als Host eingesetzt — das Display navigiert wörtlich nach http://null/....

Der eigentlich passende Modus ist im selben Code nicht implementiert:

case "local":
    // host = location.host;
    // ...
    // ToDo, fallback to primary
    addLog("Local display in secondary mode not yet supported! fallback to primary display");

openWB/general/extern_display_mode steht folglich auf "primary" und läuft ins Leere.

Geprüfte Workarounds (alle nicht tragfähig)

1. extern_display_mode = "local" setzen — greift nicht, da nicht implementiert (Fallback auf primary).
2. parent_ip per MQTT auf einen eigenen Redirect-Webserver zeigen lassen — der interne Chargepoint-Prozess überschreibt openWB/internal_chargepoint/global_data im Sekundentakt (Heartbeat) und setzt parent_ip wieder auf null. Getestet: der gesetzte Wert war nach ~25 s wieder verworfen. Permanentes Nachsetzen würde nur ein flackerndes Display erzeugen.
3. Display-Theme mit konfigurierbarer URL — nicht vorhanden; verfügbar sind nur cards und colors, beide ohne URL-Option. Im Secondary-Modus wird das Theme zudem von der (nicht existenten) primären Instanz geholt.

Als Notlösung bleibt aktuell nur, das Display komplett zu deaktivieren (openWB/optional/int_display/active = false) — bei einem Gerät mit verbautem Display unbefriedigend.

Vorschläge (nach Aufwand sortiert)

1. Kurzfristig – Fehlerbehandlung: Wenn parent_ip leer/null ist, keine Navigation zu http://null auslösen, sondern einen verständlichen Hinweis anzeigen (z. B. „Keine primäre openWB konfiguriert"). Das verhindert zumindest die kryptische Browser-Fehlerseite.
2. Mittelfristig – local-Modus implementieren: Den vorhandenen case "local" funktionsfähig machen, sodass eine Secondary-Instanz ihre eigene Ladepunkt-Ansicht anzeigt.
3. Wunsch – freie Display-URL: Eine konfigurierbare Ziel-URL für das Display (Kiosk-Modus). Damit ließe sich die Oberfläche des tatsächlich regelnden Systems anzeigen — hier EVCC, bei anderen Home Assistant o. ä. Dürfte alle Nutzer betreffen, die eine Pro/Pro+ unter Fremdsteuerung betreiben.

Vielen Dank für die Prüfung!

[floxius3d]

Ergänzung: Bezug zu PR #3205

Ich bin nachträglich auf PR #3205 („Add URL Display Theme for Raspberry Pi", @MartinRinas) gestoßen — der deckt meinen Vorschlag 3 (freie Display-URL) im Kern bereits ab. Sehr schön, das wäre für unseren Anwendungsfall genau richtig.

Ein Hinweis dazu, der für diesen Report relevant bleibt: Nach den geänderten Dateien zu urteilen legt #3205 ein neues Theme-Modul unter packages/modules/display_themes/url_display/ an, berührt aber nicht web/display/processAllMqttMsg.js — also nicht den Zweig, der im Secondary-Modus greift:

if (data["openWB/general/extern"] === true) {
    switch (data["openWB/general/extern_display_mode"]) {
        case "local":
            // ToDo, fallback to primary
        case "primary":
        default:
            host = data["openWB/internal_chargepoint/global_data"]["parent_ip"];
            destination = `${location.protocol}//${host}/openWB/web/display/?...`;

In dieser Betriebsart wird das Theme von der primären Instanz geholt und parent_ip als Host verwendet. Ein lokal konfiguriertes url_display-Theme würde hier vermutlich also gar nicht zum Zug kommen, solange der Secondary-Zweig unverändert bleibt.

Zwei Punkte, die aus meiner Sicht unabhängig von #3205 bestehen bleiben:

1. Der null-Fall sollte abgefangen werden. Ist keine primäre openWB konfiguriert, entsteht wörtlich http://null/.... Eine Prüfung auf leeres parent_ip mit verständlichem Hinweis wäre eine kleine, aber wirksame Verbesserung.
2. Der local-Zweig (aktuell „not yet supported") müsste greifen bzw. auf das lokal konfigurierte Theme zeigen, damit Secondary-Instanzen ohne primäre openWB überhaupt etwas Sinnvolles anzeigen können — dann würde Add URL Display Theme for Raspberry Pi #3205 auch in dieser Konstellation nutzbar.

Falls das mit #3205 ohnehin mitgeplant ist, gerne dieses Issue entsprechend zusammenführen oder schließen. Danke fürs Draufschauen!

[Frank-Hoe]

Es gibt eine weitere elegante Möglichkeit, EVCC direkt auf der OpenWB (ohne externen Raspi) zu betreiben: https://docs.evcc.io/de/chargers/openwb-embedded-software-replacement/.
Ich habe das testweise auch installiert und es funktioniert einwandfrei.

[floxius3d]

@Frank-Hoe danke für den Hinweis, den kannte ich noch nicht!

Eine Rückfrage dazu, weil ich beim Nachlesen unsicher geworden bin: Die evcc-Dokumentation nennt als unterstützte Hardware ausdrücklich nur die openWB Series2. Bei mir läuft eine Pro+, und die ist ja laut openWB „nur ein Ladepunkt und kein vollständiges openWB-System" — mit eigener Steuerfirmware hinter der HTTP-API auf Port 8080 (/connect.php), über die evcc sie bei mir bereits steuert.

Hast du das auf einer Series2 oder tatsächlich auf einer Pro/Pro+ installiert? Falls Letzteres, wäre das für einige hier sicher interessant — dann würde ich mich über einen kurzen Hinweis freuen, worauf man dabei achten muss.

Für mich selbst bleibe ich vorerst bei der aktuellen Konstruktion: Der Hinweis in der evcc-Doku, dass die Installation zum Verlust der Garantie führt, ist bei der Pro+ ein Argument — und ein dokumentierter Rückweg zur Originalsoftware ist dort nicht beschrieben.

Unabhängig davon bleiben die beiden Punkte aus dem Ursprungsbeitrag ja bestehen, auch für alle, die bei der Original-Software bleiben möchten: der ungeprüfte null-Wert in der Display-URL und der nicht implementierte local-Zweig im Secondary-Modus.

[kevinwieland]

Die Pro ist "nur" ein Ladepunkt. Die Pro + beinhaltet unser vollwertiges openWB EMS mit dabei.

Wenn du auf hier EVCC installierst muss dann auch das interne Netzwerkhandling mit der Pro durch EVCC erfolgen.

Machbar, aber ggf nicht trivial.

Ist auch die Frage ob du die Pro+ als series2 ansprichst oder direkt nur die Pro ?

Zu 2. Eine secondary ohne Primary macht keinen Sinn. Aufgrund des Heartbeat wäre sie ohnehin nicht ladefähig.

[floxius3d]

@kevinwieland danke für die Einordnung — vor allem der Hinweis zum EMS der Pro+ war für mich neu und erklärt einiges.

Zu deiner Frage: Ich spreche sie direkt als Pro an. evcc kommuniziert über die HTTP-API auf Port 8080 (/connect.php bzw. /api/v1/status), nicht über die openWB-Software.

Zu deiner Anmerkung, eine Secondary ohne Primary sei wegen des Heartbeats nicht ladefähig: Das deckt sich hier interessanterweise nicht mit der Praxis — geladen wurde bislang problemlos, aktuell stehen 45,4 kWh auf dem Zähler. Ich vermute, genau weil evcc die Ladesteuerung direkt über die Pro-API macht und die openWB-Software daran gar nicht beteiligt ist. Beide Seiten melden zeitgleich identische Messwerte (Spannungen ~233,6/233,9/234,3 V, imported 45449 Wh, plug_state), die Kopplung ist also intakt.

Damit habe ich faktisch folgenden Zustand:

• Ladepunkt-Hardware: wird von evcc über die Pro-API gesteuert und funktioniert
• openWB-Software auf demselben Gerät: steht auf extern = true ohne Primary — also in genau dem Zustand, den es laut dir nicht geben sollte. Das erklärt auch das Display, das mangels parent_ip nach http://null navigiert.

Daraus meine eigentliche Frage, die vermutlich mehr Pro+-Besitzer betrifft:

Welchen Modus sollte die openWB-Software einnehmen, wenn die Ladesteuerung bewusst über die Pro-API durch ein externes EMS (hier evcc) erfolgt und das openWB-EMS nicht genutzt wird?

• extern = false (also Primary) wäre die naheliegende Antwort — aber würde dann nicht das openWB-EMS ebenfalls die interne Ladehardware regeln wollen und mit evcc um dieselbe EVSE konkurrieren?
• Oder ist für diesen Fall vorgesehen, in der Software schlicht keinen Ladepunkt zu konfigurieren, damit sie nicht regelt, das Display aber wieder eine lokale Ansicht bekommt?

Falls es dafür einen dokumentierten Weg gibt, nehme ich den gerne — dann erledigt sich der Display-Punkt für meinen Fall von selbst. Unabhängig davon bliebe aus meiner Sicht sinnvoll, den null-Fall abzufangen (statt http://null ein Hinweis wie „keine primäre openWB konfiguriert"), damit eine Fehlkonfiguration nicht als kryptische Browser-Fehlermeldung endet.

[kevinwieland]

Ich vermute, genau weil evcc die Ladesteuerung direkt über die Pro-API macht und die openWB-Software daran gar nicht beteiligt ist.

Ja, du "schiebst" dich dazwischen. Das ist weder vorgesehen noch getestet. Aber schön das es für dich funktioniert.

also in genau dem Zustand, den es laut dir nicht geben sollte.

Ohne externen Eingriff geht es auch nicht.

Was aber gehen sollte ist wenn du dich nicht in die Kommunikation dazwischen hängst sondern die Pro+ ansprichst und nicht direkt die Pro. Heißt Pro+ als Secondary und diese ansprechen. So wie evcc auch eine series2 anspricht. Die Displaythematik erledigt sich dann mit dem noch offenen PR.

Alternativ, schau dir die Tarifoptimierung und Lastmanagement von openWB an, das ist recht mächtig ;)

[Frank-Hoe]

@Frank-Hoe danke für den Hinweis, den kannte ich noch nicht!

Hast du das auf einer Series2 oder tatsächlich auf einer Pro/Pro+ installiert? Falls Letzteres, wäre das für einige hier sicher interessant — dann würde ich mich über einen kurzen Hinweis freuen, worauf man dabei achten muss.

Ich habe eine Series2 und überlesen, dass du eine Pro hast.

[MartinRinas]

@floxius3d in meinem PR ist das jetzt behandelt, wäre dankbar wenn das noch jemand testen kann.