integration Fronius ladestation mit ocpp.

docs/OCPP/README.md

@@ -56,6 +56,7 @@ Phase 1 ist ein produktionsnaher Scaffold, aber noch kein fertig abgenommener OC
 Sichtbar und vorbereitet:
 
 - OCPP 1.6 Grundgeruest.
+- Fronius Wattpilot Gen1 Profil fuer OCPP 1.6J mit einfachen Ampere-Profilen.
 - OCPP 2.0.1/2.1 Adapterklassen als Struktur.
 - Manager-Anbindung mit `PowerSteps`.
 - Managementmodi: Nie laden, Immer laden, Konstanter Strom, Nur Solar.
@@ -127,6 +128,18 @@ Quellen:
 - https://www.symcon.de/de/service/dokumentation/modulreferenz/webhook-control/
 - https://www.symcon.de/de/service/dokumentation/entwicklerbereich/sdk-tools/sdk-php/module/processhookdata/
 
+## Fronius Wattpilot Gen1
+
+Der Wattpilot-Gen1-Pfad ist in `docs/OCPP/WATTPILOT_GEN1.md` beschrieben. Die Umsetzung bleibt strikt OCPP-only und verwendet keine lokale go-e API, keine Fronius Solar API und keine Cloud.
+
+Wichtige technische Regeln:
+
+- OCPP 1.6J.
+- einfache `SetChargingProfile`-Limits in Ampere.
+- keine erzwungenen `numberPhases` oder `phaseToUse`.
+- `RemoteStartTransaction`, `RemoteStopTransaction` und `ChangeAvailability` sind vorbereitet.
+- Smart-Charging wird bei Ablehnung nach begrenzten Retries capability-basiert deaktiviert.
+
 ## Variablenkatalog
 
 Bedienung:

docs/OCPP/WATTPILOT_GEN1.md

@@ -0,0 +1,125 @@
+# Fronius Wattpilot Gen1 ueber OCPP 1.6J
+
+Stand: 2026-05-10
+
+Diese Anleitung beschreibt den Testpfad fuer Fronius Wattpilot Home/Go Gen1 mit `Ladestation_OCPP` und `OCPP_Server`.
+
+## Grundsatz
+
+Die Integration ist OCPP-only:
+
+- keine lokale go-e HTTP API
+- keine Fronius Solar API
+- keine Fronius Cloud
+- kein MQTT
+- keine proprietaeren Fallbacks
+
+Der Wattpilot wird als unterstuetztes Geraet behandelt, aber nicht als Referenz fuer die gesamte OCPP-Architektur. Alle Funktionen bleiben capability-basiert.
+
+## 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.
+
+## Wattpilot-Konfiguration
+
+Im Wattpilot OCPP aktivieren und die lokale Symcon-CSMS-Adresse eintragen.
+
+Das genaue URL-Schema haengt vom aktiven Symcon-Webserver und der WebHook/WebSocket-Unterstuetzung ab. Fuer den Spike ist die Zielstruktur:
+
+```text
+ws://<symcon-ip>:<symcon-web-port>/hook/ocpp/<ChargePointId>
+```
+
+Bei TLS entsprechend:
+
+```text
+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.
+
+## Implementierter OCPP-1.6J-Pfad
+
+Eingehend:
+
+- `BootNotification` -> `Accepted`, Heartbeat-Intervall
+- `Heartbeat` -> `currentTime`
+- `StatusNotification` -> Fahrzeugstatus, `Car_detected`, `Car_is_full`
+- `MeterValues` -> Leistung, Energie, Strom, Spannung
+- `Authorize` -> `Accepted`
+- `StartTransaction` -> TransactionId und `Accepted`
+- `StopTransaction` -> `Accepted`
+- `DataTransfer` -> nur bei erlaubter Registry
+
+Ausgehend:
+
+- `SetChargingProfile`
+- `ClearChargingProfile`
+- `RemoteStartTransaction`
+- `RemoteStopTransaction`
+- `ChangeAvailability`
+
+## Smart Charging fuer Wattpilot Gen1
+
+Das Profil erzeugt bewusst nur einfache Ampere-Limits:
+
+- `chargingRateUnit = A`
+- `chargingProfileKind = Absolute`
+- `chargingProfilePurpose = TxProfile` bei aktiver Transaktion, sonst `TxDefaultProfile`
+- genau eine `chargingSchedulePeriod`
+- kurze Gueltigkeit von 120 Sekunden
+
+Nicht verwendet:
+
+- mehrere Perioden
+- komplexe Schedules
+- `numberPhases`
+- `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.
+
+## Testablauf
+
+1. `OCPP_Server` und `Ladestation_OCPP` anlegen und konfigurieren.
+2. Wattpilot mit Symcon-CSMS-Adresse verbinden.
+3. `BootNotification` pruefen:
+   - `OCPP_Connected = true`
+   - `OCPP_LastSeen` aktualisiert
+   - `Capability_MeterValues = true`
+4. Fahrzeug einstecken:
+   - `StatusNotification` setzt `Car_detected`
+   - `Fahrzeugstatus` wechselt
+5. Ladevorgang starten:
+   - `Remote Start` testen oder lokal starten
+   - `StartTransaction` wird gespeichert
+6. Messwerte pruefen:
+   - `Ladeleistung_Effektiv`
+   - `Bezogene_Energie`
+   - optional `Strom_L1/L2/L3`, `Spannung_L1/L2/L3`
+7. Manager testen:
+   - `PowerSteps` enthalten `0` und plausible Wattwerte
+   - `SetAktuelle_Leistung` schreibt nur `Power`
+   - `Do_UserCalc` sendet `SetChargingProfile`
+8. Fehlerfaelle testen:
+   - WLAN trennen
+   - MeterValues stoppen
+   - falsche ChargePointId
+   - abgelehntes ChargingProfile
+
+## 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.
+
+## Quellen
+
+- Fronius Wattpilot Support: https://www.fronius.com/en/help-center/solar-energy/e-mobility/support-wattpilot
+- Fronius Wattpilot OCPP 1.6 J: https://www.fronius.com/en/help-center/solar-energy/products/monitoring-control/solutions/open-interfaces/wattpilot-ocpp-1-6-j