Update Websocket und weiteres.

docs/OCPP/README.md

@@ -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:
 

docs/OCPP/WATTPILOT_GEN1.md

@@ -19,14 +19,15 @@ Der Wattpilot wird als unterstuetztes Geraet behandelt, aber nicht als Referenz
 ## Symcon-Konfiguration
 
 1. `OCPP_Server` Instanz anlegen.
-2. `HookPath` auf `/hook/ocpp` lassen oder passend setzen.
-3. `Ladestation_OCPP` Instanz anlegen.
-4. `DeviceProfile` auf `Fronius Wattpilot Gen1 OCPP 1.6J` setzen.
-5. `OCPPVersionMode` auf `OCPP 1.6` oder `Automatisch` setzen.
-6. `ChargePointId` exakt so setzen, wie sie im Wattpilot konfiguriert wird.
-7. `OCPPServerInstance` auf die `OCPP_Server` Instanz setzen.
-8. Im `OCPP_Server` entweder `DefaultTargetInstance` auf die Ladestationsinstanz setzen oder unter `Ladepunkte` eine Route fuer `ChargePointId`, `EVSEId = 1`, `ConnectorId = 1` anlegen.
-9. Die `Ladestation_OCPP` Instanz im bestehenden `Manager` als Verbraucher eintragen.
+2. `TransportMode` fuer echte Tests auf `external_websocket_adapter` oder spaeter `symcon_websocket_parent` setzen. `webhook_spike` ist nur Diagnose.
+3. `HookPath` auf `/hook/ocpp` lassen oder passend setzen, falls der Spike bewusst genutzt wird.
+4. `Ladestation_OCPP` Instanz anlegen.
+5. `DeviceProfile` auf `Fronius Wattpilot Gen1 OCPP 1.6J` setzen.
+6. `OCPPVersionMode` auf `OCPP 1.6` oder `Automatisch` setzen.
+7. `ChargePointId` exakt so setzen, wie sie im Wattpilot konfiguriert wird.
+8. `OCPPServerInstance` auf die `OCPP_Server` Instanz setzen.
+9. Im `OCPP_Server` entweder `DefaultTargetInstance` auf die Ladestationsinstanz setzen oder unter `Ladepunkte` eine Route fuer `ChargePointId`, `EVSEId = 1`, `ConnectorId = 1` anlegen.
+10. Die `Ladestation_OCPP` Instanz im bestehenden `Manager` als Verbraucher eintragen.
 
 ## Wattpilot-Konfiguration
 
@@ -44,7 +45,7 @@ Bei TLS entsprechend:
 wss://<symcon-host>/hook/ocpp/<ChargePointId>
 ```
 
-Wenn der Wattpilot im Status nicht bis "connected and accepted" kommt, ist zuerst der Symcon-WebHook/WebSocket-Rueckkanal zu pruefen. Es wird kein externer Transport-Adapter automatisch eingebaut.
+Wenn der Wattpilot im Status nicht bis "connected and accepted" kommt, ist zuerst der echte WebSocket-Transport zu pruefen. WebHook Control reicht fuer produktiven OCPP-Betrieb nicht als garantierter CSMS-Server. Es wird kein externer Transport-Adapter automatisch eingebaut.
 
 ## Implementierter OCPP-1.6J-Pfad
 
@@ -85,7 +86,7 @@ Nicht verwendet:
 - `phaseToUse`
 - asymmetrische Phasenprofile
 
-Wenn `SetChargingProfile` abgelehnt wird, versucht das Modul maximal `SmartChargingRetryLimit` Wiederholungen. Danach wird `Capability_SmartCharging = false` gesetzt und weitere Profile werden blockiert, bis "SmartCharging testen" erneut ausgefuehrt wird.
+Wenn `SetChargingProfile` abgelehnt wird oder kein ACK kommt, plant das Modul maximal `SmartChargingRetryLimit` Wiederholungen mit Backoff. Danach wird `Capability_SmartCharging = false` gesetzt und weitere Profile werden blockiert, bis "SmartCharging testen" erneut ausgefuehrt wird.
 
 ## Testablauf
 
@@ -117,7 +118,7 @@ Wenn `SetChargingProfile` abgelehnt wird, versucht das Modul maximal `SmartCharg
 
 ## Bekannte Grenze
 
-`OCPP_Server` bleibt ein Symcon-Transport-Spike. Er puffert ausgehende Frames pro ChargePoint und gibt direkte CallResults zurueck. Ob die WebHook/WebSocket-Mechanik in der konkreten Symcon-Windows-Installation fuer dauerhafte OCPP-Verbindungen ausreicht, muss mit dem Wattpilot oder einem OCPP-1.6J-Simulator bestaetigt werden.
+`OCPP_Server` bleibt ein Protokoll-/Routing-Modul. Der WebHook-Modus ist nur ein Spike und kann keine stabile dauerhafte WebSocket-Session mit aktivem CSMS-Push garantieren. Fuer produktive Wattpilot-Tests muss ein echter WebSocket-Server/Parent oder ein freigegebener lokaler Transport-Adapter die WebSocket-Verbindung halten und Frames an `RouteInboundFrame`/`QueueOutboundFrame` koppeln.
 
 ## Quellen