Enelix-EMS/docs/public/versionen.md

# 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.