44 lines
2.5 KiB
Markdown
44 lines
2.5 KiB
Markdown
# OCPP_Server
|
|
|
|
`OCPP_Server` ist ein Transport- und Routing-Scaffold fuer das neue `Ladestation_OCPP` Modul.
|
|
|
|
## Aufgabe
|
|
|
|
- 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`.
|
|
- Dokumentation des Transport-Spikes und Vorbereitung eines echten WebSocket-Adapters.
|
|
|
|
## Status
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
## 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.
|