Ocpp protocol

[pvhpsb]

Für die Verbindung mit einem OCPP-Backend in den Niederlanden ist eine vollständige Unterstützung des OCPP-Protokolls erforderlich.
Wäre es möglich, das openWB-OCPP-Protokoll zu erweitern?

[Gerolein]

Die Frage ist ja, ob das viele haben wollen. Denn das, was dem OCPP-Client in der openWB fehlt ist die Abgabe der Steuerung an den OCPP-Server. Sprich, die openWB wird dann nicht mehr überschuss laden oder bei billigen dynamischen Strompreisen. Sondern nur dann, wenn der OCPP-Server die Freigabe gibt. Und das macht der, wenn die richtige Ladekarte davor gehalten wird.

Das trifft dann auch die anderen Ladenodi wie Zeit- oder Zielladen.

[andreasmuellerka]

Ich hänge mich hier mal dran, weil ich genau an dem Punkt unterwegs bin — aber bewusst ohne Abgabe der Steuerung.

Mein Backend ist Monta. Ich will von dort nichts steuern lassen: Überschussladen, Zielladen, Lastmanagement bleiben komplett bei der openWB. Das Backend soll nur sehen, was passiert, und die Ladungen sauber abrechnen können. Dafür habe ich auf Basis von 2.1.9-Patch.2 lokal ein paar Dinge am OCPP-Client umgebaut:

Dauerhafte Verbindung statt Verbindung pro Nachricht. Im Stock-Code (auch noch in 2.2.1) öffnet _process_call für jede OCPP-Nachricht eine neue Websocket-Verbindung, wartet 2 s auf die Antwort und schließt wieder. Backends mit verbindungsbasierter Online-Erkennung — Monta ist so eins — sehen die Box damit nur für ein paar Sekunden online, im Portal ist sie dauerhaft offline. Jetzt hält ein Hintergrund-Thread je Chargebox ID eine stehende Verbindung mit automatischem Reconnect. Nach jedem Verbindungsaufbau BootNotification, danach zyklisch Heartbeat im Intervall aus der BootNotification-Antwort (Default 300 s). Der bisherige 5-Minuten-Heartbeat aus optional.py entfällt dadurch. Nebeneffekt: Antworten kommen jetzt als typisierte Objekte statt roh aus ws.messages gefischt, Fehlerantworten des Backends werden überhaupt erst erkannt.

Eingehende Nachrichten werden beantwortet — das ging vorher konstruktionsbedingt gar nicht, weil nie eine Verbindung offen stand.
TriggerMessage für MeterValues/Heartbeat/StatusNotification wird ausgeführt (Monta nutzt das beim Ladestart). Und, für die Diskussion hier der entscheidende Punkt: RemoteStart-/RemoteStopTransaction wird regulär mit Rejected beantwortet. Die Box lässt sich nicht fernsteuern, aber sie antwortet protokollkonform statt die Library in einen Traceback laufen zu lassen.

StatusNotification, die es im Stock-Code überhaupt nicht gibt (der Begriff kommt nirgends vor). Monta zeigte den Connector deshalb dauerhaft als Available und „Vehicle: Not Connected", selbst mitten in einer laufenden Ladung. Der Zustand wird jetzt aus cp.data abgeleitet (Available/Preparing/Charging/SuspendedEV/SuspendedEVSE/Faulted) und nur bei Änderung gesendet.

MeterValues brauchbar gemacht: transactionId mitsenden (ohne die ordnet Monta den Zählerstand keiner Session zu und verwirft ihn), zusätzlich zum Zählerstand auch Leistung, Ströme und Spannungen je Phase, und das Ganze im 60-Sekunden-Takt statt alle 5 Minuten. Fehlende Werte werden übersprungen statt als 0 gesendet, negative Werte auf ungenutzten Phasen (Zählerrauschen) werden auf 0 begrenzt, sonst meckert Monta. SoC bleibt bewusst draußen.

Das läuft bei mir und ist zusätzlich gegen einen lokales OCPP-1.6-Dienst getestet (Verbindungsaufbau, Reconnect nach Backend-Ausfall, Statusfolge über einen kompletten Ladevorgang, MeterValues). Der Scheduler der openWB wird nicht angefasst — kein Eingriff in main.py, keine zusätzlichen Threads, optional.py wird durch die Änderungen sogar kleiner.

Wichtig zur Einordnung: Das ist alles kein „vollständiges OCPP" im Sinne von Steuerungshoheit beim Server, und ich hätte auch kein Interesse daran, das zu bauen. Es macht nur den vorhandenen Client so weit protokollkonform, dass ein Backend die Station dauerhaft online sieht, den Connector-Zustand kennt und einen echten Verbrauchsverlauf bekommt. Das dürfte der Teil sein, den man haben kann, ohne die Ladelogik der openWB anzufassen.

Frage in die Runde: Besteht Interesse daran? Ich würde das gern in verdaubare PRs zerlegen — die stehende Verbindung samt Heartbeat wäre der erste, StatusNotification und die erweiterten MeterValues jeweils eigene. Aktuell habe ich aber den Eindruck, dass fremde PRs sehr stiefmütterlich behandelt werden. Wenn das also grundsätzlich nichts ist, spare ich mir den Aufwand und behalte es lokal.

[Gerolein]

Ich denke, dass das eine gute Erweiterung ist und auch gut in die openWB-Philosophie passt. Ich verfolge aus Interesse die OCPP-Threads schon seit langem. Sie tauchen in schöner Regelmässigkeit immer wieder auf, wahrscheinlich weil der Anreiz, PV-Strom zu fixen Bezugskosten steuerfrei seinem Dienstwagenherrn in Rechnung zu stellen, durchaus vorhanden ist.

Von daher bin ich auch für die weitergehenden Erklärungen dankbar, so weiss ich wieder ein bisschen mehr über OCPP und wie das so funktioniert. Gerade auch im Hinblick auf die openWB-Implementierung.

Ich wäre dafür, das zu mergen, aber ich bin da keiner der entscheidenden Personen. Meinen Segen hast du aber :)

[pvhpsb]

Ich bin sehr an dem OCPP-Patch interessiert; es wäre toll, wenn er integriert würde. Die Steuerungsfunktion benötige ich nicht ,der Ladevorgang an sich reicht aus. Eine Frage: Ist es möglich, dass ich Ihren Patch 2.1.9-Patch.2 selbst installiere?

[andreasmuellerka]

Mein Patch basiert auf Version 2.1.9 Patch 2. Auf dieser Version habe ich entwickelt. Um den Eingriff minimal zu halten, habe ich lediglich unter /var/www/html/openWB/packages/control die Dateien ocpp.py und optional.py angepasst.
Wenn Sie die Möglichkeit haben diese beiden Dateien auf der Micro-SD-Karte der openWB zu ersetzen, dann wäre es schon erledigt.

[pvhpsb]

Mein openBW läuft auf einer virtuellen Maschine auf einem Synology NAS, dort kann ich die Dateien ändern. Kann ich Ihre ocpp.py und optional.py bekommen?

[andreasmuellerka]

Klar, ich habe damit kein Problem. Wichtig ist nur: Sie müssen die Version 2.1.9 Patch 2 verwenden und dazu passen dann die beiden Dateien. Nur im Loglevel "Info" oder "Detail / Debug" loggt OCPP was raus. Bei diesen beiden Loglevel ist die openWB aber sehr geschwätzig. Stattdessen geht auch folgendes: Wenn man im Loglevel "Warnungen und Fehler" alle Nachrichten von OCPP ans Backend und den Verbindungsstatus etc. im main.log sehen möchte, dann in ocpp.py hinter Zeile 24 folgendes einfügen:

# OCPP-Vorgänge sollen unabhängig vom konfigurierten Loglevel immer im Main-Log
# protokolliert werden, daher wird der Level dieses Loggers fest auf DEBUG gesetzt.
log.setLevel(logging.DEBUG)
# Dasselbe gilt für den Logger der ocpp-Library ("ocpp", eigener Logger-Baum - nicht mit
# "control.ocpp" verwandt): Sie protokolliert jede gesendete und empfangene Rohnachricht auf
# INFO. Seit der Client die Verbindung selbst hält, sind das die einzigen Logzeilen für alle
# vom Backend initiierten Nachrichten (z. B. GetConfiguration, ChangeConfiguration,
# DataTransfer) und für die Antworten, die openWB darauf schickt - die laufen nicht über
# _process_call/_logged_call. Ohne diese Zeile fehlen sie beim Standard-Loglevel
# "Warnungen und Fehler" komplett.
logging.getLogger("ocpp").setLevel(logging.DEBUG)

optional.py
ocpp.py

[pvhpsb]

Wenn ich den github Link öffne, erhalte ich eine Fehlermeldung.

[seaspotter]

Wäre es möglich, dass du beim Antworten per email nicht immer einen elendlangen email-Ratenschwanz mit anhängst? Ich lösche bei jeder Antwort immer kilometer an unnötigen Text bei deinen Antworten. Und nicht immer einen neuen Sub-Thread zu erstellen wäre auch super :)
Danke

[andreasmuellerka]

Es tut mir Leid, aber da kann ich Ihnen nicht helfen. Die beiden Dateien sind an der Antwort angehängt und ich kann sie (auch ausgeloggt) herunterladen. Also wenn es bei Ihnen nicht klappt, dann blockt irgendwas auf Ihrem PC / Notebook / Gerät den Download (Antivirus?! Sonstige "Schutz"-Software?!)