feat(workflow): publish verified forecast controls and consolidated docs

Approved by Daniel Haefliger for develop and beta. Author dh_Agent, authenticated account dh. Preserve published battery, charging and overall Energy Pie changes. No deployment or plant control authorization.

docs/public/faq.md

@@ -68,6 +68,59 @@ Nein. Dokumentationsabgleich und Modulupdate sind getrennt. IP-Symcon-Module wer
 
 Prüfe die drei Pflichtzähler, deren Archivierung, die Einheit beziehungsweise den Faktor und den gewählten Zeitraum. Das Modul benötigt Energiezähler, nicht nur momentane Leistungsmessungen.
 
+## Wo stehen Neuerungen und bekannte Fehler?
+
+In der [Kanal- und Fehlerübersicht](versionen.md), den Changelogs und den
+Modulreferenzen. Dort werden behobene Codefehler, noch offene Betriebsfehler
+und fehlende Abnahmen getrennt. Ein dokumentierter Fix ist kein Beleg dafür,
+dass die eigene Anlage bereits aktualisiert wurde.
+
+## Warum fehlen in Stable die beschriebenen Module?
+
+Beim Abgleich vom 8. Oktober 2026 enthält `main` in beiden Repositories noch
+die Bibliotheksgrundlage. Die implementierten Module liegen in `beta` und
+`develop`. Kanalwechsel nur nach der Freigabe für deine Anlage durchführen;
+die Website nennt ihren tatsächlichen Quellkanal.
+
+## Bedeutet unbekannte Autarkie einen Messwert von null?
+
+Nein. Bei einer nicht eindeutig bestimmbaren Energieaufteilung, etwa mit einem
+separaten SDL-Zweig, ist eine Prozentzahl nicht belastbar. Das Energiediagramm
+zeigt dann die vorhandenen Zähler weiter, aber keine erfundenen Energieanteile.
+
+## Warum zeigt ein aktiver Modulstatus trotzdem keine frischen V4-Werte?
+
+Status `102` bestätigt nicht, dass alle Timer laufen. Am 6. Oktober wurde nach
+Modul-Reload ein Batterietimerproblem dokumentiert; am 7. Oktober liefen die
+periodischen Timer bei der späteren Nachkontrolle wieder. Die Ursache und
+Wiederholbarkeit nach Reload bleiben offen. Vor jedem separat freigegebenen
+V4-Test müssen automatischer Timerlauf, Rückmeldung und Stopp nachgewiesen
+sein. Keine Schutzgates oder Timer durch zusätzliche Aufrufskripte umgehen.
+
+## Warum startet die Phasenprobe trotz Solarüberschuss nicht?
+
+Bei unbekannten Phasen bietet eine zugeordnete Stand-Alone-Station zunächst
+`[0,4104] W` an. Die Probe benötigt eine entsprechende Managerzuteilung sowie
+gültige Freigaben und frische Gerätedaten. 3000 W Restbudget reichen nicht.
+Im Peakbetrieb mit Solarladen bleibt `[0]` maßgeblich. Eine 0-W-Messung beweist
+keine Einphasigkeit. [Details und Beispiele](../module/Ladestation-Stand-Alone/README.md#beispiele-zur-diagnose).
+
+## Bedeutet 0 W, dass ein Fahrzeug vollständig geladen ist?
+
+Nein. Solarpausen, fehlendes Budget oder Autorisierungswartezeit können ebenfalls
+0 W ergeben. Seit `5885681` genügt ein niedriger Strom nicht mehr für
+`FahrzeugGeladen`. go-e benötigt ein aktuelles explizites Ladeende ohne relevante
+Last; Pico besitzt kein eindeutiges Voll-Signal. Historische Pico-Ereignisse
+erscheinen getrennt als `Geraetehinweis`.
+
+## Warum hat das Energiediagramm nach dem Speichern andere Farben?
+
+Ältere Symcon-8-Farbfelder waren an Stringwerte gebunden und konnten diese
+überschreiben. Seit `2ce95e7` verwendet das Formular native Integer-Farbfelder
+und synchronisiert vorhandene Stringwerte. Bereits falsch gespeicherte Farben
+müssen gezielt neu gewählt werden. Gleiche Grund- und Akzentfarben ergeben
+einen einfarbigen Hintergrund; die Zähler bleiben unverändert.
+
 ## Welche Daten sollte ich bei einem Fehler bereithalten?
 
 Notiere Modulname, Version beziehungsweise Kanal, Instanzstatus, genaue Fehlermeldung, Zeitpunkt und die letzten Änderungen. Ergänze relevante Messwerte mit Einheiten. Entferne Lizenzcodes, Kontodaten, Passwörter und Tokens aus Screenshots und Protokollen.

docs/public/manager.md

@@ -46,6 +46,30 @@ Die Optionen für Energy Pie, Diagramme, Energy Facts und Energiefluss verwalten
 
 Prüfe Lizenzstatus, Netzleistung, Verbraucherstatus und Störtext bei ausgeschalteter Regelung. Nimm zunächst einen Verbraucher unter Aufsicht in Betrieb und vergleiche Sollwert mit physischem Verhalten. Prüfe außerdem Abschaltung und Verhalten bei fehlenden Messwerten, bevor weitere Geräte hinzukommen.
 
+## Prognose, SDL und neue Anzeigen
+
+Im bestehenden Bereich **Prognose / Forecast** findest du jetzt Planempfang,
+Vorschau und die bewusste Testbedienung. Das Aktivieren der Prognosetelemetrie
+startet keine Netzfahrplanregelung. Der alte Schalter `NetzfahrplanAktiv` und
+der neue begrenzte V4-Test sind unterschiedliche Funktionen. Vor einer
+Aktivierung gelten die [bekannten Betriebsgrenzen](versionen.md).
+
+Die Portal-Prognose zeigt die gespeicherte Eingangsprognose getrennt vom
+ausführbaren Netz-/Batterieplan. Noch nicht veröffentlichte Preise verkürzen
+den ausführbaren Horizont. Alte Pläne ohne vollständige `forecastPoints`
+zeigen Hinweise und Lücken, keine künstlich verlängerten Stellwerte.
+
+SDL kann mit eigener Istleistung und optionalem SOC berücksichtigt werden.
+Die Hauslast wird unabhängig von den Anzeigeschaltern bereinigt. Bei aktiver SDL
+können PV-Eigenverbrauch und Autarkie nicht eindeutig bestimmbar sein; dies
+erscheint im Energy Pie ausdrücklich als unbekannt. Zuerst Utils, danach EMS
+aktualisieren. Bestehende Visualisierungsschalter nicht zum Erzwingen einer
+Migration aus- und wieder einschalten.
+
+Die [Manager-Referenz](../module/Manager/README.md) enthält alle zusätzlichen
+Properties, Diagnosevariablen, dynamischen Anzeige-Idents sowie ein rein
+lesendes Schnellausführungsbeispiel.
+
 ## Im Alltag
 
 `Aktiv` schaltet die Manager-Regelung ein oder aus. `Betriebsart` zeigt **Inaktiv**, **PV** oder **Peak**. Verbraucher können eigene Mindestzeiten, Temperaturanforderungen und lokale Schutzfunktionen haben. Ein deaktivierter Manager ist deshalb kein universeller elektrischer Not-Aus. Verwende für Arbeiten an der Anlage die vorgesehenen technischen Sicherheitsmaßnahmen.

docs/public/utils.md

@@ -8,6 +8,19 @@ Wähle die archivierten, fortlaufenden Zähler für Produktion, Einspeisung und
 
 Wähle einen Zeitraum mit vorhandenen Archivdaten und prüfe Energiebilanz, Eigenverbrauch und Autarkie. Fehlende Archivdaten werden als Diagnose angezeigt. [Energiediagramm-Referenz](../../../Enelix-Utils/docs/module/Energiediagramm/README.md).
 
+Bei nicht eindeutig abgrenzbarer Energieaufteilung setzt eine passende
+Integration `EnergieanteileBerechenbar=false`. Zähler bleiben sichtbar,
+Autarkie und Eigenverbrauch erscheinen unbekannt statt als erfundene Prozentwerte.
+Beispiel: Zusätzliche Speicherflüsse können einen Netzbezug von 20 kWh bei nur
+10 kWh gemessenem Hausverbrauch erklären; daraus folgt keine sichere Hausquote.
+
+Die beiden Diagrammfarben und drei Hintergrundfarben sind in der Konfiguration
+wählbar. Gleiche Werte bei allen drei Hintergrundfarben ergeben eine einfarbige
+Fläche. Native Integer-Farbfelder mit Suffix `RGB` synchronisieren ältere
+Stringwerte; gleichzeitig geänderte Integerwerte haben Vorrang. Bereits
+fehlerhaft gespeicherte Altfarben werden nicht erraten. Die normale Kachel ist
+unter Symcon 8 zu verwenden, falls der angebotene Vergrösserungsdialog leer bleibt.
+
 ## Shelly Modul
 
 Richte zuerst den nativen MQTT-Datenfluss in IP-Symcon und MQTT am Shelly-Gerät ein. Das Modul verarbeitet Shelly-NG-Meldungen der Generationen 2, 3 und 4; alte Gen1-Topics sind nicht Teil dieser Anbindung.

docs/public/versionen.md

@@ -0,0 +1,129 @@
+# Versionen, Neuerungen und Fehlerstatus
+
+Stand des Dokumentationsabgleichs: **8. Oktober 2026**. Die Quellbasis bezeichnet
+den geprüften Funktionsstand vor den anschliessenden Dokumentationscommits.
+Die Kopfzeile dieser Website nennt die tatsächlich veröffentlichte Dokumentation.
+
+## Die drei Kanäle
+
+| Kanal | Enelix EMS | Enelix Utils | Bedeutung |
+| --- | --- | --- | --- |
+| Testing / `develop` | `5885681` | `2ce95e7` | Aktuelle Entwicklung; Funktionen kontrolliert prüfen. |
+| Beta / `beta` | `5885681` | `2ce95e7` | Derzeit gleicher Code wie Testing; anlagenspezifische Abnahme bleibt erforderlich. |
+| Stable / `main` | `b6253f9` | `51bcf9d` | Noch Bibliotheksgrundlagen: EMS-Vertrag 3.0, keine installierbaren EMS-/Utils-Module. |
+
+**Stable ist derzeit kein vollständiges EMS-Paket.** Die aktuellen Modul-
+anleitungen dieser Website beziehen sich auf den oben angezeigten Quellkanal,
+nicht automatisch auf alle drei Branches. Ein Dokumentationsupdate übernimmt
+keinen Testing-Code nach Stable und aktualisiert keine laufende Anlage.
+
+Die Original-READMEs sind kanalgenau erreichbar:
+[EMS Testing](https://git.belevo.ch/ENELIX/Enelix-EMS/src/branch/develop/README.md),
+[EMS Beta](https://git.belevo.ch/ENELIX/Enelix-EMS/src/branch/beta/README.md),
+[EMS Stable](https://git.belevo.ch/ENELIX/Enelix-EMS/src/branch/main/README.md),
+[Utils Testing](https://git.belevo.ch/ENELIX/Enelix-Utils/src/branch/develop/README.md),
+[Utils Beta](https://git.belevo.ch/ENELIX/Enelix-Utils/src/branch/beta/README.md),
+[Utils Stable](https://git.belevo.ch/ENELIX/Enelix-Utils/src/branch/main/README.md).
+
+## Neuerungen in Testing und Beta
+
+| Bereich | Veröffentlichtes Verhalten | Referenz |
+| --- | --- | --- |
+| Manager | PV-/Peak-Regelung, Lizenzkontingente, Topologie, Einspeisebegrenzung, Telemetrie und Störungsüberwachung. | [Manager](../module/Manager/README.md) |
+| Leistungsverteilung | Bei gleicher Priorität kleinste nächste absolute Leistungsstufe; Energiebezug entscheidet erst bei Gleichstand. | [Verteilbeispiel](../module/Manager/README.md#verteilalgorithmus) |
+| SDL | Separate Leistung und optionaler SOC, bereinigte Hauslast sowie eigene Energiefluss-/Diagrammreihen. | [SDL und Einheiten](../module/Manager/README.md#sdl--regelenergie) |
+| Prognosebedienung | Empfang, Vorschau und bewusste Testbedienung im bestehenden Prognose-/Forecast-Bereich. Kein automatischer Start. | [Manager-Anleitung](manager.md) |
+| Prognosekurven | Vollständige gespeicherte Eingangsprognose getrennt vom ausführbaren Preis-/Planungshorizont; PV, Last, SDL-Szenario, Netz, Batterie, SOC, Preise und Kosten. | Hinweise unten |
+| Energieanteile | Nicht bestimmbare Autarkie-/Eigenverbrauchsanteile ausdrücklich unbekannt; Zähler bleiben sichtbar. | [Energiediagramm](https://git.belevo.ch/ENELIX/Enelix-Utils/src/branch/develop/docs/module/Energiediagramm/README.md) |
+| Energy-Pie-Farben | Fünf native Farbauswahlen, drei konfigurierbare Hintergrundfarben, Symcon-8-Migration und bidirektionale String-/Integer-Synchronisierung. | [Farben und Migration](https://git.belevo.ch/ENELIX/Enelix-Utils/src/branch/develop/docs/module/Energiediagramm/README.md#darstellung) |
+| Ladestatus und Phasen | Explizites Ladeende statt Nullwert-Erkennung, geprüfte Gerätezeitstempel und Phasenprobe nur innerhalb des Managerbudgets. | [Ladestation Stand-Alone](../module/Ladestation-Stand-Alone/README.md) |
+| Verbraucher | Batterie, Warmwasser, Pufferspeicher, einstufiger Verbraucher, Wärmepumpe und beide Ladestationsvarianten mit lokalen Schutzbedingungen. | [EMS-Module](../module/README.md) |
+| Utils | Verbrauchskostenreport, virtuelle Batterie, CC100-I/O, Energiediagramm, VGT und generisches Shelly-NG-MQTT. | [Utils-Anleitung](utils.md) |
+
+Der bisherige Forecast-Datenweg und Netzfahrplan V4 sind nicht identisch.
+Bei V4 umfasst die Modellfamilie `3` PV 1 und Last 2, `13` PV 10 und Last 11,
+`23` PV 21 und Last 22. Die wirtschaftliche Vergleichsauswertung hat einen
+begrenzten Replay-Umfang; sie ist kein nachgewiesener rollender Produktionsbetrieb.
+Bis zu 48 Stunden Eingangsprognose bedeuten nicht, dass für 48 Stunden gültige
+Preise oder ausführbare Stellwerte vorliegen. Ein gekennzeichnetes SDL-Szenario
+ist kein bestätigter zukünftiger SDL-Fahrplan. Fehlende Werte bleiben Lücken.
+
+## Belegte Fehlerkorrekturen
+
+| Fehlerbild | Korrektur im Quellstand | Was weiter zu prüfen ist |
+| --- | --- | --- |
+| Veraltete Sollleistung nach verworfener Vorgabe | Gespeicherte und sichtbare Sollleistung wird bereinigt. | Lokale Ersatz-/Schutzfunktionen und reale Istleistung separat prüfen. |
+| Gleichrangige Verbraucher werden ungleich versorgt | Schrittweise Leistungsstufenvergabe statt vollständiger Vergabe nach Energiegruppe. | Mindestzeiten, Sperren und individuelle Leistungsraster bleiben wirksam. |
+| Festlasten verfälschen das Restbudget | Bilanzierung anhand gemessener Istleistung. | Messquellen und Alter kontrollieren. |
+| Solarpause wird als Ladeende behandelt | Ladeende, Solarpausen, Phasen-/Anlaufzustände und Übergänge korrigiert. | Ladefreigabe, Fahrzeuglimit und Gerätekommunikation prüfen. |
+| go-e-Fehler oder alte Pico-Daten werden weiterverwendet | go-e `err`/`car`, Pico-Zustand, Kontakt- und Messzeit werden validiert. Managerdaten erneuern den Gerätecache nicht. | Pico-Autorisierungswartezeit und historisches Ereignis nicht mit aktuellem Gerätefehler verwechseln. |
+| Nullleistung erzeugt eine falsche Phasenanzahl | 0 W bleibt unbekannt; frische Dreiphasenströme korrigieren alte Einphasigkeit. Die 6-A-Probe braucht bei Managerzuordnung 4104 W Budget. | Migration verwirft alte unsichere Erkennung einmalig. Freigaben und Solar-/Peak-Grenzen bleiben erhalten. |
+| Easee-Werte bleiben nach Stopp stehen | Veraltete Ladeleistung wird genullt; Ereignisverbindung konsistent neu aufgebaut. | Cloud-/Parent-Verbindung bleibt Voraussetzung. |
+| V4-Datenkennung unterscheidet `100` und `100.0` | Numerische Normalisierung und eng begrenzte Kompatibilitätsbehandlung. | Keine Originalkennungen oder Cursor manuell ersetzen. |
+| Veraltete oder blockierende V4-Rückmeldung | Bestätigter Geräteabruf, getrenntes Sampling und quellengebundener Cache. | Ein implementierter Fix beweist keinen laufenden Timer oder Hardware-Watchdog. |
+| V4-Plan wird bei Zwischenzustand verpasst | Empfangs-Retry und Initialisierungsdrossel korrigiert. | Abgelaufene Pläne und HTTP-429 bleiben gesperrt bzw. gedrosselt. |
+| Nicht bestimmbarer PV-Anteil erscheint als Zahl | Explizite Darstellung unbekannter Energieanteile. | Geeignete Zähler und passende Messgrenzen bleiben erforderlich. |
+| Symcon-8-Farbfelder überschreiben Stringfarben | Native Integer-Farbproperties mit Synchronisierung vorhandener Stringwerte. | Bereits falsch gespeicherte schwarze Werte werden nicht automatisch rekonstruiert. |
+
+Die vollständigen Quellverweise stehen im [EMS-Changelog](../../CHANGELOG.md)
+und im [Utils-Changelog](https://git.belevo.ch/ENELIX/Enelix-Utils/src/branch/develop/CHANGELOG.md).
+
+## Bekannte Grenzen und offene Betriebsfehler
+
+**V4-Batterietimer:** Am 6. Oktober 2026 wurde nach Modul-Reload erneut eine
+Timerblockade beobachtet. Die spätere dokumentierte Nachkontrolle vom 7. Oktober
+2026, 20:34 Uhr Europe/Zurich, zeigt laufende periodische Timer bei aktiven
+Instanzen. Der frühere Stillstand wird deshalb nicht als heutiger Live-Zustand
+behauptet. Ursache und Wiederholbarkeit nach Reload sind weiter offen; Status
+`102` allein ist kein Funktionsnachweis. Kein Timerersatz und keine automatische
+Aktivierung aus dieser Anleitung. Es fand hier keine neue Anlagenprüfung statt.
+
+**V4-Abnahme:** Physische Soll-/Ist-Nachführung, sicherer Null-/Stopp-Pfad,
+Weiterbetrieb über mehrere Planerneuerungen und unabhängiger Geräte-Ausfallschutz
+sind nicht vollständig abgenommen. Die frühere befristete Testfreigabe endete
+am 7. Oktober 2026 um 17:38 Uhr Europe/Zurich. Sie ist zum Dokumentationsstand
+abgelaufen. Diese Dokumentation verlängert sie nicht und erklärt V4 nicht
+produktionsreif.
+
+**Ladestationen:** `5885681` ist auf Testing/Beta veröffentlicht. Der jüngste
+hier verwendete Installationsbericht vom 7. Oktober beschreibt nur eine
+gesicherte Vorbereitung, noch keine Installation dieses Fixes. Nach einem
+gesondert freigegebenen Update bleiben Ladepause/Wiederanlauf, frische Statusdaten,
+Phasenerkennung und physischer Stopp an echten Fahrzeugen abzunehmen. Die
+ursprünglichen Ladeunterbrechungen sind nicht zweifelsfrei auf eine einzige
+Ursache zurückgeführt. Behobene Codefehler sind kein nachträglicher Ablaufbeweis.
+
+**Forecast-Backend:** Der verwendete Rolloutbericht vom 6. Oktober meldet Portal-
+Assets aktualisiert, das neue Backend-Image mit vollständigen `forecastPoints`
+aber noch ausstehend. Alte Pläne können deshalb gekennzeichnete fehlende Kurven
+haben. Dies ist eine datierte Rolloutgrenze, kein in dieser Dokumentationsarbeit
+neu gemessener Live-Zustand. Ein späterer erfolgreicher Backend-Rollout ist
+für diesen Abgleich nicht belegt. Kein stilles Auffüllen fehlender Werte.
+
+**Weitere Grenzen:** Produktiv signierte Lizenz-Leases, Untermanager-
+Messabgrenzung sowie gerätespezifische Feldabnahmen bleiben separat zu prüfen.
+Die vorbereitete Wärmepumpen-Bestelloberfläche erfordert den passenden Portal-
+Backend-Rollout. Die Einbindung einer VGT-Anwendung ins Portal ist noch keine
+durch das vorhandene MQTT-Modul belegte Funktion.
+
+**Energiediagramm:** Der von Symcon 8 angebotene Vergrösserungsdialog kann leer
+bleiben; dann die normale Kachel verwenden. Der zusätzliche HTML-SDK-Vollbildmodus
+ist erst ab Kernelversion 9.0 aktiviert. Fehlende Archivwerte und unbekannte
+Energieanteile sind getrennte Zustände und dürfen nicht als null ersetzt werden.
+
+Der Abgleich basiert auf veröffentlichtem Code, Repository-Dokumentation und
+datierten Test-/Installationsberichten. Die separate Gitea-Issue-Liste konnte
+in diesem Lauf nicht authentifiziert gelesen werden; eine vollständige
+Erfassung aller dort gemeldeten offenen Fehler wird deshalb nicht behauptet.
+
+## Sicher aktualisieren und Fehler melden
+
+1. Installierten Kanal, Version und vorhandene lokale Änderungen prüfen.
+2. Konfiguration, Zähler und individuelle Visualisierungen sichern.
+3. Für die neuen SDL-Anzeigen zuerst Utils, danach EMS im freigegebenen Kanal aktualisieren.
+4. Quellen, Vorzeichen, Timer und Rückmeldungen prüfen, bevor Steuerung freigegeben wird.
+5. Bei einem Fehler Modul, Kanal, Zeitpunkt, Status und bereinigte Diagnose notieren; keine Zugangsdaten teilen.
+
+Ein Git-Push ist kein Anlagenupdate. Ein grüner Softwaretest ist keine
+Hardwareabnahme. Die bestehenden Beispiel-IDs und Screenshots sind niemals
+ungeprüft als Anlagenkonfiguration zu übernehmen.