Symcon_Belevo_Energiemanagement/docs/OCPP/WATTPILOT_GEN1.md

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. 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

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:

ws://<symcon-ip>:<symcon-web-port>/hook/ocpp/<ChargePointId>

Bei TLS entsprechend:

wss://<symcon-host>/hook/ocpp/<ChargePointId>

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

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

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

• 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