Erfahrungsbericht: openWB Pro als reiner Ladepunkt an externem EMS (E3DC-Control)

HINWEIS: Zusammenfassung aus dem alten openWB Forum

Hallo zusammen,

ich möchte hier kurz meine bisherigen Erfahrungen zur openWB Pro teilen. Ich entwickle – mit großartiger Unterstützung der Community als Tester – das Open-Source EMS "E3DC-Control". Seit Kurzem habe ich die openWB Pro im Einsatz, um unsere Software-Logik für externe Ladepunkte zu optimieren und anzupassen. In meinem Setup läuft die Pro übrigens parallel zu einer bestehenden E3DC-Wallbox. Dieser Multi-Wallbox-Betrieb funktioniert dank der zentralen EMS-Steuerung einwandfrei.

Hier ein paar Erkenntnisse aus der Praxis, die vielleicht für andere interessant sind, die ein ähnliches Setup planen:

Zur Hardware & Montage:
Die Verarbeitungsqualität macht einen sehr soliden Eindruck. Was mir bei der Installation positiv aufgefallen ist: Beim beigelegten Montagezubehör wird nicht gespart, es liegen vernünftige Fischer Duopower Dübel und Torx-Schrauben bei.
Ein kleiner Praxistipp: Bei der Montage des Netzwerkkabels ist der Platz am Port etwas knapp bemessen. Hier ist ein RJ45-Winkelstecker oder ein kurzes 90°-Patchkabel definitiv von Vorteil, um das Ganze entspannt einzustecken.

Zur Regelung, ISO 15118 & Auswertung:
Die Pro wird bei mir über eine externe Standalone-Instanz angesprochen und fungiert als reiner Aktuator. Die eigentliche Logik (PV-Überschuss, dynamische Tarife, Speichermanagement) übernimmt komplett mein EMS. Wichtiges Learning hierbei: Das Ganze funktioniert nur dann reibungslos, wenn keine zusätzliche Standalone-Instanz parallel auf das System zugreift.

Ein großer Vorteil der Pro ist für mein Projekt die Kommunikation über das Ladekabel. Wir haben hier einen gemischten Fuhrpark. Wenn ein Fahrzeug angesteckt wird, können wir es über die MAC-Adresse sofort eindeutig identifizieren und die hinterlegten fahrzeugspezifischen Werte aus der Konfiguration laden. Das ermöglicht es uns, die Ladungen nicht nur zuzuordnen, sondern auch fahrzeugspezifisch zu archivieren. So können wir in Zukunft die komplette Ladehistorie pro Fahrzeug – etwa in einem Jahresvergleich – sauber gegenüberstellen.

Der SoC wird aktuell beim Ladestart zuverlässig ausgelesen, daher interpolieren wir diesen mit den hinterlegten Fahrzeugdaten, was extrem hilfreich ist, um sich nicht auf die oft instabilen Cloud-APIs der Hersteller verlassen zu müssen (während der laufenden Ladung aktualisiert er sich über diesen Weg noch nicht).

Phasenumschaltung (1p/3p) & Ausblick RFID:
Die Leistungssteuerung via API reagiert präzise und setzt die Stromvorgaben des EMS sauber um. Ein sehr wichtiger Punkt zur Phasenumschaltung: Hier sollte man der Wallbox unbedingt ihre Zeit lassen und nicht hektisch weitere Befehle aus dem EMS hinterherschießen. Die Pro weiß selbst am besten, wie sie die Schütze hardwareschonend umsetzt. Gibt man ihr diese kurze Bedenkzeit, läuft die Umschaltung absolut geschmeidig.

Den integrierten RFID-Reader werde ich zukünftig in meiner Regelung dazu verwenden, um direkt an der Wallbox händisch den Lademodus umzuschalten – zum Beispiel, um von einem "ruhigen" PV-Laden auf sofortiges Laden (aus PV + Batterie + Netz) zu wechseln.

Insgesamt lässt sich die Pro für solche speziellen Use-Cases sehr gut in komplexe, externe EMS-Landschaften integrieren. Falls hier jemand an ähnlichen externen Anbindungen bastelt, tausche ich mich gerne aus.

Viele Grüße,
Andreas

[A9xxx]

Zu den Steckdosen: Das ist hier gar nicht so einfach bzw. so profan, wie es sich anhört: So muss man in den Großsystemen auf folgende Punkte achten, insbesondere, da wir es in einem System anbieten wollten:
Der Strom muss gezählt werden. Hierfür haben wir einen weiteren 1-P-Zähler integriert. Anders wäre es Stromklau, sofern die Steckdose wie bei uns an der zentralen Stromunterverteilung (verteilt Allgemeinstrom) angeschlossen ist. Und natürlich fließen hier beim Laden von eBikes und dem Aussaugen von Autos keine Unmengen - aber es gibt eben auch Beispiele, in denen regelmäßig eingesetzte Krafträder (vermutlich 80/ 125er) durchaus dann auch messbare und abrechnungsrelevante Mengen ziehen. Da wir uns ja auf Wunsch der WEG um die Kostenaufschlüsselung kümmern, müssen auch diese Zählerwerte direkt den Nutzer:innen zuordnenbar sein.
Wenn die Anlage in ihrer Leistung durch den Netzbetreiber reduziert ist, dann gilt das auch für die Steckdosen. Diese sind kein Plan B für Netzanbieterreduktionen :-).
Steckdosen sind sehr ungut regelbare Leistungen, viel "hinterhältiger" als Autos. Dies mag oftmals nicht für eine Steckdose gelten, wir denken aber eben immer in großen Mengen, siehe auch in diesem Beispiel der TG hier. Hintergrund: Bevor Strom in ein Auto fließt, vereinbaren dies die Wallbox und das Auto. Hier kennen wir also vor dem Stromfluss den maximal möglichen Stromfluss - oftmals sogar die belasteten Phasen. Bei der Steckdose gibt man diese frei - und es passiert erst einmal nichts. Nach z.B. 10 Minuten wird die Last, z.B. ein Staubsauger, angeschaltet - und plötzlich fließen da ohne weitere Vorankündigung 10 A. Wie gesagt, bei einer Steckdose kein Problem. Bei mehreren dann durchaus - insbesondere da Steckdosen immer einphasig agieren und wir hier sehr schnell an Schieflastprobleme kommen. Schon alleine eine Steckdose erzeugt eine Abregelung eines auf der gleichen Phase laufenden 1-/ oder 2-P-Laders.
All diese Punkte und noch viel mehr, z.B. Datenintegration in der App, haben wir eben mit dieser Lösung umgesetzt. Eine Lösung, die im normalen EFH-Bau natürlich nicht gebraucht wird, aber im MFH-Bau durchaus gerne individuell genommen wird. Und gegenüber der normalen MFH-Lösung, nämlich die Einzelverkabelung der Steckdose auf den Wohnungszähler, sind wir durch die hohen Verlegekosten i.d.R. um einiges günstiger.

[A9xxx]

Hallo openWB Admin, vielen Dank für die ausführliche Erläuterung zum Thema Schuko-Steckdosen und Lastmanagement im MFH! Da gab es aber ein kleines Missverständnis beim Lesen: Ich meinte oben gar keine Schuko-Steckdose, sondern einen RJ45-Winkelstecker für das Netzwerkkabel direkt am LAN-Port der Pro, weil es dort beim Einbau etwas eng zuging. Mir ging es in dem Bericht primär um die direkte und performante HTTP-Anbindung der Pro-Hardware an ein externes EMS.

[A9xxx]

Die openWB Pro ist für E3DC-Control spannend: Sie benötigt eine eigene, etwas speziellere Regelung, weil Stromvorgabe, Phasenwunsch, Startfreigabe, CP-Interrupt und echte Ladebestätigung sauber getrennt geführt werden müssen. Genau dadurch wird sie aber zu einem sehr guten Partner für unser EMS. Wenn diese Verträge sauber umgesetzt sind, reagiert die openWB Pro präzise auf externe Vorgaben, setzt Strom- und Phasenbefehle nachvollziehbar um und liefert genug Rückmeldung, damit E3DC-Control nicht raten muss. Sie ist damit kein „einfacher“ Wallbox-Typ, aber als direkt steuerbarer Aktuator sehr passend für eine zentrale PV-/Speicher-/Wallbox-Regelung.

[Gerolein]

Ah, ok. Mit --live bekomme ich nun vermutlich ein Authentifizierungs-Problem:

  File "/home/pi/s10/openwb_e3dc_rscp_bat_prototype.py", line 278, in <module>
    raise SystemExit(main())
                     ~~~~^^
  File "/home/pi/s10/openwb_e3dc_rscp_bat_prototype.py", line 272, in main
    bat.update()
    ~~~~~~~~~~^^
  File "/home/pi/s10/openwb_e3dc_rscp_bat_prototype.py", line 112, in update
    resp = self._request([
        {"tag": EMS_REQ_POWER_BAT, "type": RscpType.Nil, "value": None},
    ...<3 lines>...
        {"tag": EMS_REQ_REMAINING_BAT_DISCHARGE_POWER, "type": RscpType.Nil, "value": None},
    ])
  File "/home/pi/s10/openwb_e3dc_rscp_bat_prototype.py", line 106, in _request
    conn.authenticate(self.config.portal_user, self.config.portal_password)
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/pi/s10/rscp_client.py", line 834, in authenticate
    response = self._recv_frame()
  File "/home/pi/s10/rscp_client.py", line 812, in _recv_frame
    raise ConnectionError("Verbindung geschlossen")
ConnectionError: Verbindung geschlossen

portal-user und passwort stimmen. Kann ja dann nur noch an der fummeligen Eingabe des AES-Passworts am S10 liegen....

[A9xxx]

Der Trace ist hilfreich: Die TCP-Verbindung steht schon, der Abbruch passiert erst beim Warten auf die Authentifizierungsantwort.

Wenn Portal-User und Portal-Passwort sicher stimmen, ist der wahrscheinlichste Kandidat tatsächlich das RSCP-/AES-Passwort des S10 oder dessen Übergabe an das Skript. Bei falschem AES-Key kann der E3DC den verschlüsselten Auth-Frame nicht sinnvoll entschlüsseln und schließt die Verbindung dann gerne einfach. Bei falschen Portal-Zugangsdaten würde ich eher eine Auth-Fehlermeldung bzw. ein niedriges Auth-Level erwarten.

Wichtig sind drei Dinge:

1. RSCP/AES-Passwort exakt wie im E3DC gesetzt verwenden.
2. Sonderzeichen im Passwort sauber quoten, z.B. mit einfachen Hochkommas.
3. Keine Leerzeichen oder Zeilenumbrüche am Ende mitkopieren.

Zum Gegencheck wäre jetzt erst einmal nur ein Auth-/Live-Test sinnvoll, noch ohne Speichersteuerung:

python3 openwb_e3dc_rscp_bat_prototype.py
--host
--portal-user ''
--portal-password ''
--rscp-password ''
--live
--auth-test

Erst wenn der Auth-Test sauber durchläuft, würde ich mit --power-limit -500 weitermachen.

Ich habe den Prototyp außerdem angepasst: Er unterstützt jetzt auch Umgebungsvariablen (E3DC_HOST, E3DC_PORTAL_USER, E3DC_PORTAL_PASSWORD, E3DC_RSCP_PASSWORD) und gibt bei Auth-Problemen eine kürzere Fehlermeldung statt Stacktrace aus.

openwb_e3dc_rscp_bat_prototype.py

[Gerolein]

Ahhh. Das war das Bildschirmschoner-Passwort. Das AES-Passwort kommt wenn man noch einmal nach unten blättert. Klappt nun.

Allerdings macht --power-limit -400 bei mir eine komplette Entladesperre und nicht nur eine Begrenzung auf 400W. Dafür funktioniert der --release aber und ich lebe nun wieder aus dem Speicher.

Ginge eigentlich auch eine lokale RSCP-Verbindung? Man kann da ja noch ein anderes Passwort einstellen für den local.user.

Trotz allem: Sehr cool, dass das so schnell funktioniert. Vielen Dank schonmal!

[A9xxx]

openwb_e3dc_rscp_bat_prototype.py

python3 openwb_e3dc_rscp_bat_prototype.py \ --host <e3dc-ip> \ --rscp-user local.user \ --rscp-login-password '<local-passwort>' \ --aes-password '<aes-passwort>' \ --live \ --power-limit -400

python3 openwb_e3dc_rscp_bat_prototype.py \ --host <e3dc-ip> \ --rscp-user local.user \ --rscp-login-password '<local-passwort>' \ --aes-password '<aes-passwort>' \ --live \ --release

[A9xxx]

Zur lokalen RSCP-Verbindung: Ja, grundsätzlich sollte das gehen. Die Verbindung ist ohnehin lokal auf den E3DC per TCP/5033. Die bisherigen Parameter --portal-user und --portal-password waren im Prototyp nur etwas unglücklich benannt. Du kannst jetzt auch schreiben:

--rscp-user local.user --rscp-login-password '<lokales-passwort>' --aes-password '<aes-passwort>'

Das AES-/RSCP-Passwort bleibt trotzdem zusätzlich nötig, weil es für die verschlüsselte RSCP-Verbindung verwendet wird.