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, EMS Beta, EMS Stable, Utils Testing, Utils Beta, Utils Stable.

Neuerungen in Testing und Beta

Bereich	Veröffentlichtes Verhalten	Referenz
Manager	PV-/Peak-Regelung, Lizenzkontingente, Topologie, Einspeisebegrenzung, Telemetrie und Störungsüberwachung.	Manager
Leistungsverteilung	Bei gleicher Priorität kleinste nächste absolute Leistungsstufe; Energiebezug entscheidet erst bei Gleichstand.	Verteilbeispiel
SDL	Separate Leistung und optionaler SOC, bereinigte Hauslast sowie eigene Energiefluss-/Diagrammreihen.	SDL und Einheiten
Prognosebedienung	Empfang, Vorschau und bewusste Testbedienung im bestehenden Prognose-/Forecast-Bereich. Kein automatischer Start.	Manager-Anleitung
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
Energy-Pie-Farben	Fünf native Farbauswahlen, drei konfigurierbare Hintergrundfarben, Symcon-8-Migration und bidirektionale String-/Integer-Synchronisierung.	Farben und Migration
Ladestatus und Phasen	Explizites Ladeende statt Nullwert-Erkennung, geprüfte Gerätezeitstempel und Phasenprobe nur innerhalb des Managerbudgets.	Ladestation Stand-Alone
Verbraucher	Batterie, Warmwasser, Pufferspeicher, einstufiger Verbraucher, Wärmepumpe und beide Ladestationsvarianten mit lokalen Schutzbedingungen.	EMS-Module
Utils	Verbrauchskostenreport, virtuelle Batterie, CC100-I/O, Energiediagramm, VGT und generisches Shelly-NG-MQTT.	Utils-Anleitung

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 und im Utils-Changelog.

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.