Enelix-EMS/docs/prognose-bedienintegration.md

Prognosebedienung im bestehenden Manager

Stand: 06.10.2026. Gepruefter Integrationsstand zur von Daniel freigegebenen Veroeffentlichung auf develop und beta. Kein Deployment und keine neue Stellfreigabe.

Umfang

Der separate Formularbereich V4 Planempfang / Prognosemanager entfaellt. Empfang, Planpruefung, Lizenzportal-Verweis und explizites Ein-/Ausschalten stehen im bestehenden Bereich Prognose / Forecast.

Der neue Formularaufruf FormNetzfahrplanSchalten delegiert an den vorhandenen V4ManagerAktivtestSchalten-Pfad. Er prueft beim Start nochmals gespeicherte Prognosekonfiguration, Netzfahrplanlizenz, Managerstatus und bestehende lokale Testfreigaben. Ein Formularaufruf allein erteilt keine Berechtigung. Ausschalten bleibt auch nach Lizenzverlust moeglich. Der bestehende Stopp beinhaltet eine frisch berechnete normale Regelung nach Widerruf der V4-Sitzung; er ist kein anlagenweiter Not-Aus und veraendert keine unabhaengigen SDL-Auftraege.

Die Anzeige nennt weiterhin Testbetrieb und das bestehende Testende. Es gibt keine neue Dauerbetriebsfreigabe, keinen Reset der 48-Stunden-Frist und keine Aenderung an Watchdog-Ausnahmen, Messwertgrenzen oder Geraeteschutzpruefungen.

Kompatibilitaet

• Keine Properties, Attribute, Objekt-IDs, Timer, Datenpfade oder Backend-APIs werden migriert.
• Prognosemodelle, Optimierer, Planempfang, ACKs, Messaufnahme und Versand bleiben unveraendert.
• Die vorhandene Portalpruefung fuer grid_schedule bleibt massgeblich. Keine Portal- oder Lizenzbestellung wird geaendert.
• NetzfahrplanAktiv bedeutet weiterhin den alten Regler. Bei vorhandener V4-Konfiguration wird dessen ausgeschalteter Schalter ausgeblendet. Ein eingeschalteter Altregler bleibt zum Ausschalten sichtbar.
• Nicht auf V4 eingerichtete Installationen behalten den bisherigen Schalter. Diese Aenderung provisioniert keine neue V4-Installation.
• PrognoseAktiv wird nicht zum automatischen V4-Startsignal. Bestehende Aufnahme-/Sender-Properties und die bisherige Laufzeitvariable bleiben erhalten.

Dateien

• Manager/form.json: stabiler Anker fuer den bestehenden Prognosebereich.
• Manager/module.php: Formularintegration und gepruefter Bedienaufruf.
• libs/ManagerPrognoseFormular.php: reine Formularzusammenstellung ohne I/O.
• libs/ManagerNetzfahrplanV4EmpfangTrait.php: nur bisherigen Formulargenerator entfernt; Empfangscode unveraendert.
• tests/PrognoseFormular/: Formular- und echte RequestAction-Pruefungen mit simulierten IPS-/Stellaufrufen.
• tests/V4Receiver/receiver_checks.php: Strukturpruefung an die zusammengefuehrte Oberflaeche angepasst.

Tests

Isoliert im PHP-8.3.6-CLI auf einer Quellkopie, nicht im Symcon-Kernel:

Suite	Erfolgreiche Pruefungen
PrognoseFormular/checks.php	59
PrognoseFormular/manager_checks.php	26
V4Receiver/receiver_checks.php	32
V4ControlTrial/checks.php	96
V4Feedback/receiver_checks.php	8
V4Feedback/device_read_checks.php	9
V4ControlTrial/register_checks.php	1
Gesamt	231

Zusaetzliche Gesamttests des zusammengefuehrten Stands am 06.10.2026:

• PHP 8.3.6 / PHPUnit 9.6.36: 357 Tests, 1758 Assertions erfolgreich.
• Syntaxpruefung: alle 150 PHP-Dateien erfolgreich.
• Backend: 310 Python-Tests erfolgreich mit den vorhandenen QA-Abhaengigkeiten.
• Portal: 16 Node-Tests erfolgreich.
• Konfliktmarker- und Patch-Pruefung erfolgreich.

Die Pruefungen liefen in isolierten Quellkopien. Die PHP-Laufzeit wurde nur im Agent-Arbeitsordner entpackt, ohne Systeminstallation. Kein Symcon-Kernel-/GUI- oder Hardwaretest; der vorhandene Docker-Zugang war nicht nutzbar.

Eine vorbestehende, nicht committe Aenderung an measurement_pipeline.py wurde bewusst nicht uebernommen: Sie erzeugte fuer jede konfigurierte Messgrenze ein accountingEvidenceId trotz measurementBoundaryVerified=false und verletzte den bestehenden Backendtest. Die Datei bleibt im Integrationsstand bytegleich zum bisherigen versionierten V4-Stand. Die fremde Arbeitskopie und das laufende Backend wurden nicht veraendert. Eine spaetere Freigabe dieser Messgrenze braucht einen eigenstaendigen fachlichen Nachweis, keine Anpassung des Tests an das Label.

Offener Abschluss

Der Auftrag ist mit dieser Bedienintegration noch nicht vollstaendig umgesetzt:

• Die dokumentierte Batterietimerblockade und die fehlende Anlagenabnahme werden hier nicht behoben.
• Ein regulaerer, lizenzierter Dauerbetrieb anstelle des begrenzten Testpfads ist nicht implementiert.
• Die separaten Laufzeitvariablen und Diagnoseordner werden noch nicht entfernt oder ausgeblendet.
• In gespeicherten Settings vom 06.10.2026, 13:06:07 UTC sind nur die Kategorien 21196 (ENELIX_V4_SEPARATED_OBSERVATION) und 57590 (ENELIX_V4_PASSIVE_CAPTURE) eindeutig als V4-Diagnosebereiche erkannt. Darin liegen weiterhin Beobachtungs-/Aufnahmeskripte. Keine pauschale Loeschung nach Namen.
• Der allgemeine Testordner 10249 enthaelt auch Abrechnung, Schnittstellen und weitere nicht zu dieser Integration gehoerende Objekte. Er bleibt unangetastet.
• Vor einem Rollout aktuelle Moduldateien sichern, mit dem getesteten Stand vergleichen und Abhaengigkeiten pruefen. Keine pauschalen Modulupdates, Reloads oder Dienstneustarts aus diesem Dokument ableiten.
• Die Divergenz wurde in einem separaten develop-Checkout auf ubuntu zusammengefuehrt: Server-89-Historie bis ce525a1 und origin/develop bis 5437f3f. Die Originalarbeitsverzeichnisse mit fremden Aenderungen bleiben erhalten. Daniel hat Merge, Commit und Push auf develop und beta ausdruecklich freigegeben; main bleibt unveraendert.

Uebergabe und Ruecksetzung

Die fruehere Einzelpatch-Uebergabe ist durch den zusammengefuehrten Quellstand ersetzt. Die Ausgangshistorie und die zugehoerigen lokalen V4-Quellen sind unter /srv/agent/prognose-integration-20261006 gesichert. Der gepruefte Kandidat enthaelt keine temporaren Live-Hooks, Zugangsdaten oder fremden uncommitteten Ladestationsaenderungen. Ruecksetzungen nur additiv nach Driftpruefung; keine fremden Aenderungen verwerfen. Fuer einen spaeteren Runtime-Rollout sind eine eigene Sicherung, Abhaengigkeitspruefung und Anlagenabnahme erforderlich.

Vorschlag PR-Text

Titel: Manager: Prognosebedienung im bestehenden Forecast-Bereich buendeln

Aenderung: Separaten V4-Formularbereich entfernen, bestehende Funktionen unter Prognose / Forecast anbieten und explizite Bedienaktionen zusaetzlich gegen Lizenz-, Konfigurations- und Freigabestatus pruefen.

Unveraendert: Prognose-/Optimierungsbackend, Empfangsprotokoll, Anlagenlimits, befristete Testfreigaben, Datenhistorie und SDL. Keine automatische Aktivierung.

Pruefung: 357 PHPUnit-Tests, 310 Backend-Tests, 16 Portal-Tests sowie die oben genannten isolierten Bedien-/V4-Checks; kein Hardware- oder Symcon-GUI-Abnahmetest.