83 lines
3.2 KiB
Markdown
83 lines
3.2 KiB
Markdown
# Ladestation_OCPP
|
|
|
|
`Ladestation_OCPP` ist das neue OCPP-orientierte Ladestationsmodul fuer das Belevo/Enelix Energiemanagement in IP-Symcon.
|
|
|
|
Status dieser Version: **M1 Scaffold**. Das Modul ist installierbar, haelt den bestehenden EMS-Vertrag ein und stellt die OCPP-Zielarchitektur bereit. Der produktive OCPP-WebSocket-Dauerbetrieb ist bewusst noch als Transport-Spike ueber `OCPP_Server` gekennzeichnet.
|
|
|
|
## Ziel
|
|
|
|
- OCPP-only Architektur fuer Ladestationen.
|
|
- Keine Hersteller-HTTP-APIs, keine Cloud-Token, keine direkte Kopie von `Ladestation_v2`.
|
|
- Fachliche Paritaet zu `Ladestation_v2` als Zielbild.
|
|
- Stabile Anbindung an den bestehenden `Manager` ueber `PowerSteps`, `GetCurrentData`, `SetAktuelle_Leistung` und `Do_UserCalc`.
|
|
- Geraeteprofil `fronius_wattpilot_gen1` fuer erste Fronius-Wattpilot-Gen1-Tests ueber OCPP 1.6J.
|
|
|
|
## Manager-Anbindung
|
|
|
|
Das Modul ist aus Sicht des Energiemanagers ein Verbraucher. Es legt die Pflichtvariablen mit exakt diesen Idents an:
|
|
|
|
- `Sperre_Prio`
|
|
- `PV_Prio`
|
|
- `Idle`
|
|
- `Aktuelle_Leistung`
|
|
- `Bezogene_Energie`
|
|
- `PowerSteps`
|
|
- `Power`
|
|
- `Is_Peak_Shaving`
|
|
- `Leistung_Delta`
|
|
- `IdleCounter`
|
|
|
|
Pflicht-Actions:
|
|
|
|
- `GetCurrentData(bool Peak)`
|
|
- `SetAktuelle_Leistung(power)`
|
|
- `Do_UserCalc()`
|
|
|
|
## Phase-1-Modi
|
|
|
|
Diese Modi sind im Scaffold sichtbar und in der PowerStep-Berechnung vorbereitet:
|
|
|
|
- `0` = Nie laden
|
|
- `1` = Immer laden
|
|
- `2` = Konstanter Strom
|
|
- `3` = Nur Solar
|
|
|
|
Weitere Modi sind als Architektur vorbereitet, aber noch nicht produktiv ausgearbeitet.
|
|
|
|
## OCPP-Struktur
|
|
|
|
Die OCPP-Klassen liegen in `Ladestation_OCPP/libs/`:
|
|
|
|
- Nachrichtenmodell: `OCPPMessage`, `OCPPTransport`
|
|
- Versionsadapter: `OCPP16Adapter`, `OCPP201Adapter`, `OCPP21Adapter`
|
|
- Fachlogik: `PowerStepCalculator`, `ChargingProfileBuilder`, `MeterValueNormalizer`, `TransactionStore`
|
|
- Sicherheit/Diagnose: `FailSafeManager`, `Diagnostics`, `CapabilityModel`, `DataTransferRegistry`, `PhaseManager`
|
|
- Geraeteprofil: `WattpilotGen1Profile`
|
|
|
|
## Fronius Wattpilot Gen1
|
|
|
|
Das Wattpilot-Profil bleibt strikt OCPP-only:
|
|
|
|
- keine lokale go-e HTTP API
|
|
- keine Fronius Solar API
|
|
- keine Fronius Cloud
|
|
- einfache `TxProfile`-Limits in Ampere bei aktiver Transaktion, sonst `TxDefaultProfile`
|
|
- genau eine Schedule-Periode
|
|
- keine Phasen-Erzwingung per OCPP
|
|
- `RemoteStartTransaction`, `RemoteStopTransaction` und `ChangeAvailability`
|
|
- `SetChargingProfile` mit begrenzten Retries und Capability-Abschaltung bei Ablehnung
|
|
|
|
Details stehen in `docs/OCPP/WATTPILOT_GEN1.md`.
|
|
|
|
## Transport
|
|
|
|
OCPP braucht eine WebSocket-Verbindung zwischen Ladestation und CSMS. In dieser Architektur uebernimmt Symcon die CSMS-Rolle. Der Transport ist getrennt im Modul `OCPP_Server` vorbereitet.
|
|
|
|
Wichtig: Der WebHook-Modus von `OCPP_Server` ist nur ein Diagnose-/Spike-Pfad. Fuer echte Wattpilot- und OCPP-Tests muss ein WebSocket-Transport die dauerhafte Session, Ping/Pong, Reconnect und aktiven CSMS-Push uebernehmen und Frames an `RouteInboundFrame`/`DequeueOutboundFrame` koppeln. Erst dann koennen `RemoteStartTransaction`, `SetChargingProfile` und `ChangeAvailability` zuverlaessig aktiv zur Ladestation gesendet werden.
|
|
|
|
## Dokumentation
|
|
|
|
Die fachliche und technische Gesamtdokumentation liegt unter:
|
|
|
|
`docs/OCPP/README.md`
|