Update Websocket und weiteres.

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