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.

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

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 erste Commit ist kein vollstaendiger produktiver OCPP-CSMS. Er dokumentiert und kapselt den Transport-Spike, damit echte Stationstests gezielt folgen koennen.

Dokumentation

Die fachliche und technische Gesamtdokumentation liegt unter:

docs/OCPP/README.md