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