127 lines
4.8 KiB
Markdown
127 lines
4.8 KiB
Markdown
# 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:
|
|
|
|
```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 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
|