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