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
OCPP_Server/README.md
+19 -4
View File
@@ -7,18 +7,24 @@
- Vorbereitung der CSMS-Transportrolle innerhalb von IP-Symcon.
- Routing von eingehenden OCPP-Frames nach `ChargePointId`, `EVSEId` und `ConnectorId`.
- Entgegennahme von ausgehenden Frames aus `Ladestation_OCPP`.
- Pufferung ausgehender Frames je `ChargePointId` fuer den WebHook/WebSocket-Spike.
- Dokumentation des WebHook/WebSocket-Spikes.
- Pufferung ausgehender Frames je `ChargePointId`.
- Dokumentation des Transport-Spikes und Vorbereitung eines echten WebSocket-Adapters.
## Status
Dieses Modul ist bewusst ein Scaffold. Symcon bietet einen WebSocket Client sowie WebHook Control mit WebSocket-Support und `ProcessHookData()` fuer PHP-Module. Ob diese Mechanik fuer dauerhafte OCPP-CSMS-Verbindungen mit realen Ladestationen robust genug ist, muss mit einer OCPP-Referenzstation, einem Simulator oder dem Fronius Wattpilot getestet werden.
Dieses Modul ist bewusst ein Scaffold. Der WebHook-Pfad ist nur fuer Diagnose und Spike geeignet. Er ist kein vollwertiger OCPP-CSMS-WebSocket-Server, weil ein Charge Point fuer OCPP eine dauerhafte bidirektionale WebSocket-Session und asynchronen CSMS-Push erwartet.
Eingehende Calls werden an `Ladestation_OCPP` geroutet. Die dort erzeugten OCPP-CallResults werden in `OCPP_Server` gepuffert und fuer denselben `ChargePointId` wieder ausgegeben, sofern der Symcon-Hook diesen Rueckkanal bereitstellt.
Produktiv muss `TransportMode` auf einen echten WebSocket-Transport zeigen:
- `external_websocket_adapter`: lokaler Adapter/Service uebernimmt WebSocket-Handshake, Sessions, Ping/Pong und Push.
- `symcon_websocket_parent`: spaeterer Symcon-Parent/Splitter mit echter WebSocket-Server-Funktion.
`webhook_spike` bleibt nur fuer Tests, bei denen eingehende Frames synchron verarbeitet und direkte CallResults zurueckgegeben werden. RemoteStart, SetChargingProfile und ChangeAvailability koennen damit nicht zuverlaessig aktiv gepusht werden.
## Konfiguration
- `HookPath`: Standard `/hook/ocpp`
- `TransportMode`: `webhook_spike`, `external_websocket_adapter` oder `symcon_websocket_parent`
- `DefaultTargetInstance`: Zielinstanz, wenn kein spezifisches Routing gefunden wird
- `Ladepunkte`: optionale Routingliste je ChargePoint/EVSE/Connector
- `HeartbeatSeconds`: Watchdog-Basis
@@ -26,3 +32,12 @@ Eingehende Calls werden an `Ladestation_OCPP` geroutet. Die dort erzeugten OCPP-
## Zusammenspiel
`Ladestation_OCPP` bleibt das fachliche Ladepunktmodul und setzt den EMS-Vertrag um. `OCPP_Server` bleibt Transport/Routing. Mehrere Ladepunkte koennen spaeter ueber denselben Transport angebunden werden.
## Adapter-Vertrag
Ein echter WebSocket-Transport muss die dauerhafte Session halten und nur Frames an `OCPP_Server` koppeln:
- Inbound vom Charge Point: `RouteInboundFrame` oder `ReceiveExternalFrame` mit JSON `{"ChargePointId":"...","Frame":"[...]","Remote":"ip:port"}` aufrufen.
- Rueckgabe von `RouteInboundFrame` sofort als OCPP-CallResult/CallError ueber dieselbe WebSocket-Session senden, falls nicht leer.
- Outbound vom CSMS: `DequeueOutboundFrame(<ChargePointId>)` abrufen und ueber die bestehende WebSocket-Session aktiv an den Charge Point senden.
- Der Adapter muss WebSocket-Handshake, Ping/Pong, Close, Reconnect, Fragmentierung und Session-Zuordnung selbst robust behandeln.