feat(accounting): separate physical storage and SDL with source-age validation

docs/netplan-v4-accounting.md

@@ -0,0 +1,99 @@
+# 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.