Files
Symcon_Belevo_Energiemanage…/OCPP_Server
2026-05-10 17:26:05 +02:00
..
2026-05-10 17:26:05 +02:00
2026-05-10 17:26:05 +02:00
2026-05-10 17:26:05 +02:00
2026-05-10 17:26:05 +02:00

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.