Enelix-EMS/docs/netplan-v4-accounting.md

# V4: getrennte Last-/Batterie-/SDL-Bilanz (Kandidat, keine Stellfreigabe)

## Status 2026-10-02

`NetzfahrplanV4Bilanzierung` ist ein reiner Rechen-/Validierungsbaustein. Noch keine
Einbindung in die laufende Telemetrie, den Trainer oder den Kontrolltest. Er ruft
keine IPS-, Netzwerk-, Archiv- oder Stellfunktionen auf. Ergebnis ist immer
`controlEligible=false`, auch bei geschlossener mathematischer Bilanz.

34 isolierte PHP-Pruefungen wurden mit der gleichen SHA256-Datei auf iot-symcon01
bestanden. Das ist kein Nachweis fuer die reale Hardware-/Messgrenzenzuordnung
und kein vollstaendiger PHPUnit- oder Symcon-Kernel-Test.

## Gefundener Unterschied in Lihrenmoos

Installierter Manager `Manager/module.php::leseMessleistungen()` verwendet:

    Haus = PV + Netz - Summe der konfigurierten Batterie-Istleistungen

Konfiguriert ist hier die virtuelle EV-Leistung 52020, nicht die gesamte physische
Batterieleistung. Daher bleibt der externe SDL-Anteil und eine allfaellige
Abweichung der virtuellen Aufteilung im an den Prognosedienst gesendeten Hauswert.
`sendePrognoseTelemetrie()` sendet genau diesen errechneten Wert. Die parallel
existierenden Hausvariablen 46714 und 40713 sind NICHT automatisch diese Quelle.

Der bisherige Gateway `Bat_EV_SDL_V4` liest die physische Batterieleistung aus
47725, 35724 und 36380 und invertiert diese Vorzeichen. EV und SDL sind daraus
abgeleitete, separat gefilterte virtuelle Konten, keine zwei unabhaengigen Zaehler.
Die Filter koennen alte Teilwerte halten. `UpdateActualPowerSplit` aktualisiert die
Ausgabevariablen trotzdem. Ein neuer Ausgabezeitstempel beweist deshalb nicht die
Frische aller darunter liegenden Originalmessungen.

## Kandidat fuer die korrekte Bilanz

Mit einheitlicher Messgrenze und Vorzeichen Batterie+ = Laden, Netz+ = Bezug:

    Verbraucherlast = Netz + PV - gesamte physische Batterieleistung
    Grundlast = Verbraucherlast - separat geplante flexible Verbraucher
    Zuordnungsrest = physische Batterie - virtuell steuerbare Batterie - externe virtuelle Konten
    Externer Netzeffekt = externe virtuelle Konten + Zuordnungsrest
    Netz = Grundlast + flexible Last + steuerbare Batterie + externer Netzeffekt - PV

Der Zuordnungsrest wird nicht erneut als Hausverbrauch trainiert, sondern separat
angezeigt. Eine grosse Abweichung sperrt die Datenqualitaet. Gegenlaeufige virtuelle
Konten (z.B. EV +42 kW, SDL -40 kW, physisch +2 kW) bleiben korrekt getrennt.
Spaetere Ladestationen/Boiler sind ueber `flexible_load` erweiterbar. Solange sie
nicht separat geplant werden, verbleiben sie in der nicht separat steuerbaren Last.

Keine Messgroesse wird doppelt subtrahiert. Ein negatives Grundlastergebnis wird
nicht heimlich auf null begrenzt. Numerische Nullen sind echte Werte; fehlende,
nicht endliche oder umtypisierte Werte sind keine Nullen.

## Originalzeit und Datenqualitaet

Jede Quelle hat explizite Variable/Parent/Ident, Faktor, maximales Alter und optionale
Ursprungsabhaengigkeiten. Alle Quellen werden zweimal gelesen. Wertewechsel waehrend
der Aufnahme werden abgewiesen; Zeitstempel werden nie kuenstlich verjuengt.
Abhaengigkeiten sind zyklenfrei, doppelte Quellen werden verhindert.
Eine virtuelle Summenvariable erbt das aelteste Datum ihrer physischen Eingangsquellen.
Konfigurierbare Alters-/Synchronitaetspruefung ist erforderlich. Diagnoseberechnungen
mit ungeeigneten Daten bleiben `quality_hold`, nicht `base_load`-Trainingsfreigabe.
Die momentanen Beispielgrenzen (60 s Alter, 30 s Versatz) sind konservative
Diagnoseparameter, keine garantierten Geraeteeigenschaften.

Die konkrete Solar-PV-Herkunft sowie AC/DC-/Wirkungsgradgrenzen aller Hybridgeraete
sind noch zu verifizieren. Eine algebraisch geschlossene Gleichung beweist diese
physische Messgrenze NICHT. Die vorgeschlagene Quellkonfiguration ist nicht freigegeben.

## Migration in die Prognose (noch offen)

1. Originalmessquellen und Messgrenze dokumentieren und Qualitaet ueberwachen.
2. Korrigierte Grundlast und externe Kanaele als NEUE versionierte Zeitreihen erfassen.
3. Bestehende Historien nicht ueberschreiben oder als bereinigte Historie umbenennen.
   Rekonstruktion nur bei ausreichenden zeitlich passenden Originaldaten.
4. Prognosemodell auf der korrigierten Basis trainieren/validieren.
5. Zukunfts-SDL separat liefern. Unbekannt ist nicht null; eine geschaetzte Annahme
   muss explizit bezeichnet werden und darf nicht als veroeffentlichter SDL-Fahrplan gelten.
6. Erst nach diesen Pruefungen eine echte Bilanzierungsreferenz im Trial-Gate verwenden.
   `mappingId` aus dieser Klasse ist ein Konfigurationsfingerabdruck, KEIN solcher Nachweis.

## Gateway-Ausfallverhalten (nicht getestet/freigegeben)

Quelltextpruefung des installierten Alt-Gateways ergab keinen Frischetest fuer
`Nennleistung_Soll_EV` im Weg `Update -> ApplySetpoints`. Der zwischengespeicherte
EV-Sollwert wird weiter verwendet, solange die Gateway-Schleife laeuft. Der Eingang
wird von `scripts/31800.ips.php` geschrieben; dieser enthaelt ebenfalls keine Lease.
Der vorhandene 30-s-Timeout des EMS-Batterieadapters ist ein Schutz innerhalb von
Symcon, nicht ein unabhaengiger Wechselrichter-Timeout bei Rechnerausfall.

`State=false` im Alt-Gateway beendet `Update` ohne dort Nullwerte zu schreiben.
Diesen Schalter nicht als nachgewiesenen Hardware-Notstopp verwenden.
Keine Kommunikationsunterbrechung, kein Abschalttest und keine neue Stellwertausgabe
wurden an der realen Anlage durchgefuehrt. Auch aus dem fehlenden Code kann NICHT
gefolgert werden, dass das Geraet selbst keinen Timeout hat. Exakte Typen/Firmware
und das wirksame geraeteseitige Verhalten muessen noch festgestellt werden.

Wichtig fuer spaetere Anpassung: Ein EV-Befehlsablauf darf nicht pauschal den
externen SDL-Auftrag loeschen. Ein Kernel-interner Timer ersetzt wiederum keinen
Schutz bei komplettem Kernel-/Rechner-/Kommunikationsausfall.