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)

Originalmessquellen und Messgrenze dokumentieren und Qualitaet ueberwachen.
Korrigierte Grundlast und externe Kanaele als NEUE versionierte Zeitreihen erfassen.
Bestehende Historien nicht ueberschreiben oder als bereinigte Historie umbenennen. Rekonstruktion nur bei ausreichenden zeitlich passenden Originaldaten.
Prognosemodell auf der korrigierten Basis trainieren/validieren.
Zukunfts-SDL separat liefern. Unbekannt ist nicht null; eine geschaetzte Annahme muss explizit bezeichnet werden und darf nicht als veroeffentlichter SDL-Fahrplan gelten.
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.

5.7 KiB Raw Blame History