dh/Symcon_Belevo_Energiemanagement
2
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

Update Websocket und weiteres.

Browse Source
This commit is contained in:
Manuel Bürkli
2026-05-10 17:26:05 +02:00
parent e240b17d3d
commit 233aa56d40
9 changed files with 233 additions and 60 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/OCPP/README.md
+15 -6
View File
@@ -22,7 +22,7 @@ Verbindliche Grundsaetze:
`Ladestation_OCPP` ist die fachliche Ladepunkt-/Connector-Instanz. Sie bildet Status, Messwerte, Managementmodi, Diagnose und EMS-Schnittstelle ab.
`OCPP_Server` ist ein separates Transport-Scaffold. Es bereitet WebHook/WebSocket, Routing und Frame-Puffer vor. Die Trennung ist wichtig, weil mehrere Ladepunkte an einem Transport haengen koennen.
`OCPP_Server` ist ein separates Transport-Scaffold. Es bereitet Routing, Frame-Puffer und die Kopplung an einen echten WebSocket-Transport vor. Die Trennung ist wichtig, weil mehrere Ladepunkte an einem Transport haengen koennen.
## EMS-Vertrag
@@ -68,7 +68,7 @@ Sichtbar und vorbereitet:
Noch nicht produktiv fertig:
- echte dauerhafte WebSocket-CSMS-Verbindung mit realer Station.
- echte dauerhafte WebSocket-CSMS-Verbindung ohne externen/Parent-WebSocket-Transport.
- vollstaendige OCPP-1.6/2.0.1 State Machine.
- automatische 1p/3p-Umschaltung mit Hardwarefreigabe.
- bidirektionales Laden.
@@ -106,7 +106,7 @@ Ausgehend vorbereitet:
- `ClearChargingProfile`
- `Reset`
## Transport-Spike
## Transport und WebSocket
OCPP erwartet, dass die Ladestation eine WebSocket-Verbindung zum CSMS aufbaut. Symcon muss hier die CSMS-Rolle uebernehmen.
@@ -118,9 +118,18 @@ Relevante Symcon-Optionen:
Bewertung fuer Phase 1:
- `OCPP_Server` kapselt diese Frage, damit `Ladestation_OCPP` fachlich stabil bleibt.
- Der produktive Rueckkanal und Dauerbetrieb muessen mit Simulator oder OCPP-1.6-Referenzstation getestet werden.
- Ohne bestaetigten Transport wird kein externer Middleware-Dienst als Standard eingebaut.
- `ProcessHookData()` und WebHook Control sind nur als WebHook-Spike zu betrachten.
- Ein produktiver OCPP-CSMS braucht eine persistente bidirektionale WebSocket-Session mit Async-Push, Ping/Pong und Session-Lifecycle.
- `OCPP_Server` kapselt Protokollzustand, Routing und Pufferung, ist aber nicht selbst der vollstaendige WebSocket-Handshake-/Frame-Server.
- Produktiv ist ein echter WebSocket-Parent/Splitter oder ein lokaler Transport-Adapter noetig. Dieser wird nicht automatisch eingebaut.
- Der WebHook-Spike darf fuer Diagnose und einzelne synchrone CallResult-Tests verwendet werden.
Adapter-Vertrag fuer einen echten Transport:
- eingehende Frames mit `ChargePointId`, Roh-Frame und Remote-Adresse an `RouteInboundFrame`/`ReceiveExternalFrame` uebergeben.
- direkte Rueckgabe aus `RouteInboundFrame` ueber dieselbe WebSocket-Session senden.
- gepufferte ausgehende Frames ueber `DequeueOutboundFrame(<ChargePointId>)` holen und aktiv zur bestehenden Session pushen.
- Handshake, Ping/Pong, Close, Reconnect, Fragmentierung und Session-Lifecycle liegen beim Transport.
Quellen: