feat(workflow): publish verified forecast controls and consolidated docs
Tests / test (push) Successful in 1m1s
Tests / test (push) Successful in 1m1s
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.
This commit is contained in:
@@ -1,5 +1,15 @@
|
||||
# ENELIX Netzfahrplan V4 – verbindlicher Gesprächs- und Arbeitskontext
|
||||
|
||||
## Veroeffentlichungsauftrag 08.10.2026: gemeinsamer Stand
|
||||
|
||||
Daniel Haefliger hat den aktuellen Stand inklusive Batterie, Ladestationen,
|
||||
Energy Pie und weiterer unveroeffentlichter Projektarbeit fuer develop und beta
|
||||
freigegeben: Autor/Committer dh_Agent <dh@belevo.ch>, Git-Zugang dh.
|
||||
Dies ist weder eine Anlageninstallation noch eine neue Stell-/Testfreigabe.
|
||||
Aktuellen Veroeffentlichungsnachweis in docs/RELEASE_20261008.md und Remote-Refs pruefen.
|
||||
Die folgenden Betriebsbeobachtungen sind datierte Historie, keine Live-Nachkontrolle
|
||||
dieses Releaseauftrags. Neuere Timer-/Ladestationskorrekturen bleiben enthalten.
|
||||
|
||||
## Fortsetzung 06.10.2026, 17:32 UTC: Forecast/SDL installiert, Betriebsblocker
|
||||
|
||||
Massgeblicher neuer Bericht: `docs/FORECAST_SDL_RELEASE_20261006.md`.
|
||||
@@ -404,3 +414,148 @@ EMS `examples/V4CorrectedFeedback/`, `examples/V4UnifiedRelease/`, `services/net
|
||||
5. Nach jedem Abschluss diese Übergabe mit Datum, Codecommit, tatsächlichem Installations-/Teststatus und nächstem konkreten Arbeitsschritt ergänzen. Keine gescheiterten Schritte in „fertig“ umdeuten. Bei Widerspruch aktuelle geprüfte Laufzeit und ausdrückliche spätere Nutzerkorrektur nennen.
|
||||
|
||||
**Kurzübernahme:** „Netzfahrplan V4 in ENELIX fortsetzen. Datenkennung/Versand repariert, Unified RC1 und korrigierter Feedback-/Testpfad installiert. Aktuell `feedback_source_skew`; bestätigte Geräte-Lesezeitpunkte in die bestehende lokale Rückmeldung integrieren. EV 161.44 kWh/39 kW. Keine neue Diagnosekategorie, keine alten Installer, kein automatischer Stelltest. Dauerproduktion ist noch nicht fertig; Tests/Abnahme/Veröffentlichung sauber getrennt halten.“
|
||||
|
||||
|
||||
## Ergaenzte historische Server-Uebergaben
|
||||
|
||||
## Neuer Stand 06.10.2026, 17:41 UTC: Forecast/SDL, erneute Timerblockade
|
||||
|
||||
Der neuere Bericht `docs/FORECAST_SDL_RELEASE_20261006.md` ist massgeblich.
|
||||
EMS 372b997876a2faa1ff563b6e004f9c864ed2504b und Utils
|
||||
5b6125d0862a39fe93e1479d4cc5424df0168491 sind auf develop UND beta bestaetigt.
|
||||
Autor dh_Agent, technisches Git-Konto dh, ausdruecklicher Auftrag Daniel.
|
||||
Dieser alte divergente Arbeitsordner wurde NICHT ueberschrieben oder bereinigt.
|
||||
Portal-Assets live; Backend-Image noch nicht ausgerollt (Dockerrechte fehlen).
|
||||
Testanlage aktualisiert, SDL-Anzeigen eingerichtet, Diagnosen verborgen.
|
||||
WICHTIG: Nach dem Modul-Reload haengt alter Batterie-Timer 70 erneut; neue
|
||||
Sampler-/Meldetimer laufen nicht. Die untenstehende Entwarnung um 14:35 UTC
|
||||
gilt nicht mehr. Neuer kontrollierter Symcon-Neustart wurde bei Daniel angefragt.
|
||||
Netzfahrplan-Schalter 46716 bleibt false. Keine unbefristete Freigabe oder
|
||||
Umgehung von Timern/Hardware-Schutz. Temporaere Hooks wieder entfernt.
|
||||
|
||||
## Nachkontrolle 06.10.2026, 14:35 UTC: Batterietimer laufen nach Neustart
|
||||
|
||||
Dieser neuere Laufzeitnachweis ersetzt die unten dokumentierte weiterhin offene
|
||||
Timerblockade und den damaligen Nullauftrag, nicht die verbleibenden V4-Abnahmeanforderungen.
|
||||
|
||||
- Daniel hat den kontrollierten Symcon-Neustart nach Sicherung ausdruecklich freigegeben. Der Agentversuch wurde mit `Interactive authentication required` abgewiesen. Nach manueller Uebergabe meldete Daniel die Anlage wieder als laufend; `ActiveEnterTimestamp` bestaetigt 06.10.2026, 16:32:09 Europe/Zurich. Keine Berechtigungsumgehung.
|
||||
- Gepruefte Sicherung vor dem Versuch: Settings und 147 EMS-Quelldateien unter `/srv/agent/symcon-restart-20261006/backup` auf iot-symcon01, Verzeichnis 0700 und Dateien 0600. Keine Zugangsdaten ausgegeben oder in das Repository uebernommen.
|
||||
- Rein lesende Kernel-Nachkontrolle 14:34:11 bis 14:35:11 UTC, 13 Stichproben: `Meldezyklus`, `NetzfahrplanV4RueckmeldungAktualisieren` und `RueckmeldungVerzoegert` zeigen fortlaufend steigende `LastRun`-Werte. Managerstoertext leer; Verbrauchermeldung `Alle aktiven Verbraucher werden geregelt.` Kernel weiterhin 8.0.
|
||||
- Der separate V4-Abschnitt im Batterieformular ist entfernt und im laufenden Kernel als abwesend bestaetigt. Die zugehoerige Konfiguration und Backend-Methoden bleiben erhalten; zuvor 12 isolierte Formularvarianten erfolgreich geprueft.
|
||||
- Konfigurationshashes von Manager 17004, Batterie 44234 und Gateway 58448 sind vor/nach dem Neustart gleich. V4-Schalter bleibt AUS, V4-Batteriestatus `stopped`. Der bereits vor dem Neustart eingeschaltete ALTE Netzfahrplan bleibt EIN. Die normale Regelung gibt wieder EV-Leistung vor; letzter Snapshot 21055 W EV / 0 W SDL. Das ist KEIN V4-Stellversuch und KEINE physische Tracking-Abnahme.
|
||||
- Nachweis: `/srv/agent/symcon-restart-20261006/verification-result.json`, `passed=true`. Die aeltere `result.json` dokumentiert bewusst den zuvor abgewiesenen Agent-Neustart. `after.jsonl` enthaelt beide Beobachtungsphasen; `verification-start.json` grenzt die echte Neustart-Nachkontrolle ab.
|
||||
- Temporaere rein lesende Beobachtung wieder entfernt; 12555.ips.php hat erneut SHA-256 `c702a4947ae200b23c3eecccabeb843ad6a55e97509292584ca2de779d5e4940`. Kein externer Timerersatz, kein Aktivstart und keine neue Testfreigabe hinterlassen.
|
||||
- Der akute Timerstillstand ist behoben; seine urspruengliche Ursache ist damit nicht nachgewiesen. Der V4-Testwatchdog war mangels aktiver V4-Sitzung deaktiviert und wurde NICHT erprobt. Physisches V4-Tracking, >90-s-Planwechsel und Watchdog-/Nullstopp-Abnahme bleiben offen. Bestehendes Testende 07.10.2026, 17:38:07 Europe/Zurich unveraendert.
|
||||
- Keine Modulquelle in dieser Nachkontrolle geaendert. Server-89-develop nach Fetch weiterhin divergent und mit bestehenden lokalen Aenderungen; kein Fast-Forward, Commit, Merge oder Push. Nur diese datierte Uebergabe ergaenzt.
|
||||
|
||||
|
||||
## 16. Nachtrag 07.10.2026: Ladeunterbrechungen und Ladebedienung
|
||||
|
||||
- Auftrag Daniel: Morgenbeschwerde zu Pico und go-e untersuchen, bekannte Bedienung inklusive Boost fuer alle fuenf Ladepunkte wiederherstellen. Keine V4-/SDL-Freigabe und kein Auftrag fuer einen pauschalen Ladealgorithmus-Rollout.
|
||||
- Laufzeit iot-symcon01 geprueft: Symcon 8.0, seit 06.10. 16:32 CEST gestartet; aktuelle Instanzen und Timer aktiv. Neue stufenweise Manager-Verteilung ist installiert (Git-Blob libs/ManagerRegler.php: 36cf412b8b0d5ee6652c141095261dd4fb6bb3f7). Keine alten Timerblockaden als heutigen Zustand darstellen.
|
||||
- Archiv 07.10. bis ca. 19:05 CEST: Pico 1 ohne Energiezuwachs; Pico 2 ca. 0.231 kWh, go-e Ladesaeule ca. 0.295 kWh, rechte go-e ca. 6.417 kWh, Easee ca. 31.611 kWh. Pico 2 und go-e zeigen kurze Ladephasen und Stopps. Exakte Nutzer-/Fahrzeugzuordnung der Beschwerde fehlt. Keine behauptete gemeinsame Hardwareursache.
|
||||
- Zentrale Portal-Auswertung: 325 Vorkommen, davon 315 Peak/PV-Angebotskonflikte (35 Gruppen x 9 Verbraucher), daneben zehn Kommunikations-/Statusvorkommen. Vollstaendige lokale Tageslogs fehlen: Dateilog abgeschaltet, Modul-Logging aus, Journal mit Agentkonto nicht lesbar. Keine vollstaendige native Zustands-/Bedienhistorie. Direkter Pico-1-Status ca. 19:07 CEST: frische Daten, 32 A erlaubt/dynamisch, 0 W/0 A. Ursache am Fahrzeug/Autorisierung/Ladeweg noch offen.
|
||||
- Aktueller Modulcode: fuenf isolierte Reproduktionen bestaetigen latchende Voll-Erkennung nach kurzem Niedrigstromwert, nicht ausgewertete go-e-Fehler, nicht gepruefte Pico-Datenfrische/Fehler, 0-W-Phasentest ergibt eine Phase, gespeicherte eine Phase ueberstimmt neue Dreiphasen-Rueckmeldung. Das sind aktuelle Codebefunde, keine bewiesene Rekonstruktion des Morgenablaufs. Keine dieser Modulschwaechen hier behoben.
|
||||
- Installation 19:17:31 CEST: /srv/agent/lihrenmoos-charger-ui. Root 16447, Aktionsskript 46103. Zuordnung Instanz/Gruppe/Boost: 22078/31363/16854; 31986/29211/47015; 27189/42489/28906; 43878/22180/50715; 46052/22895/27030. Vorhandene fuenf Links unter 14536 umgestellt; native Variablen nur verlinkt. Keine alten Module reaktiviert.
|
||||
- Boost bildet die fruehere Prioritaetslogik ab: PrioritaetPeak=0, vorherigen Wert sichern und bei Aus/erkanntem Abstecken wiederherstellen. Solarladen bleibt separat. Spaetere Boost-Bedienung verwendet gezieltes ApplyChanges der Station. Installer selbst hat keine Instanz angewendet, keine Ladebefehle gesendet und keine Stromgrenzen/V4/SDL-Einstellungen geaendert. Urspruenglicher Beobachterskript-Inhalt 12555 bytegleich wiederhergestellt (SHA256 c702a4947ae200b23c3eecccabeb843ad6a55e97509292584ca2de779d5e4940).
|
||||
- Nachweis: install-result.json status=installed, configurationUnchanged=true; 38 isolierte Bedienungstests und 66 gespeicherte Zustandspruefungen erfolgreich. settings.json schreibt zeitverzoegert; erste Nachkontrolle war deshalb noch unvollstaendig, spaetere Pruefung vollstaendig erfolgreich. README.md und before.json dokumentieren Wiederanlauf/Rueckbau. rollback.php nur syntaktisch geprueft, nicht ausgefuehrt. Kein echter WebFront-Bildschirmtest und kein Fahrzeug-Ladeversuch.
|
||||
- Git: kein neuer Codecommit, kein Commit/Push. Bestehende lokale Aenderungen erhalten. origin/develop am Abschluss erfolgreich gefetcht; wegen zahlreicher sich mit Remote-Aenderungen ueberschneidender lokaler Arbeiten nicht automatisch integriert. Dieser Nachtrag ist nur angehaengt.
|
||||
- Naechster konkreter Schritt: Pico 1 mit bekanntem Fahrzeug und zeitgleichem Zustands-/Sollstrom-/Fehlertrace pruefen; danach falsche Voll-Erkennung sowie Phasen-/Fehlerauswertung gezielt korrigieren, regressionspruefen und kontrolliert ausrollen. Keine Behauptung, die Ladeunterbrechungen seien durch die UI-Wiederherstellung behoben.
|
||||
|
||||
## Ladestationskorrekturen veroeffentlicht: 07.10.2026, 18:26 UTC
|
||||
|
||||
- Auftraggeber Daniel Haefliger hat Fehlerkorrekturen sowie Commit/Push auf develop und beta mit Autor dh_Agent und Konto dh ausdruecklich freigegeben. Kein Anlagenrollout daraus abgeleitet.
|
||||
- Repository ENELIX/Enelix-EMS, Commit `58856816697e4720a57cac046ec1793c1325576b`, `fix(charging): validate status and budget phase detection`. Autor und Committer `dh_Agent <dh@belevo.ch>`. Konfigurierter Login dh und authentifizierte Repository-Pushberechtigung technisch geprueft; Profil-Endpunkt wegen Token-Scope nicht verfuegbar. Atomarer normaler Fast-Forward-Push erfolgreich; anschliessendes ls-remote bestaetigt develop UND beta auf diesem Commit. main blieb `b6253f9e55c659913ebb43783fe2b6a72cfd180f`.
|
||||
- Die schmutzigen kanonischen Arbeitsverzeichnisse wurden erhalten. Entwicklung im sauberen develop-Checkout `/srv/agent/charger-fixes-20261007` auf ubuntu. Zehn eigene Dateien committed; nur die dort beim Test erzeugte composer.lock bleibt untracked und wurde nicht veroeffentlicht. Der vorhandene Pre-Push-Schutz wird ueber core.hooksPath weiterverwendet; einmalige beta-Freigabe ist verbraucht und nicht mehr gesetzt.
|
||||
- Stand-alone-Korrekturen: kein verriegeltes Ladeende aus einzelnen Null-/Niedrigwerten; go-e err/car validiert; Pico-Zustaende und echte Kontakt-/Messzeitstempel geprueft. Pico LastWarningOrError ist nur historische Diagnose und Pico hat kein eindeutiges Voll-Signal. Leerlauf-ValueDate 0001 ist nur mit frischem LastSeen und ohne Ladeleistung zulaessig. Managerdaten koennen defekten/abgelaufenen Geraetecache nicht erneuern oder Fehler wegdruecken.
|
||||
- Die 6-A-Phasenprobe nutzt bei zugeordnetem Manager das normale Angebot [0,4104] und braucht Budget; kein direkter Probebefehl aus dem Lesepfad. Freigaben und Solar/Peak gelten auch waehrend der Probe. 0 W ergibt keine Einphasigkeit. Frische Dreiphasenmessung korrigiert alte Einphasigkeit; bestaetigte drei Phasen werden bis zum Ausstecken nicht aus einer einzelnen belasteten Phase heruntergestuft. Migration der Erkennungsversion 2 verwirft alte unsichere Phasenwerte einmalig, ohne Bedienfreigaben zu aendern.
|
||||
- Verifiziert: composer check mit PHP-Syntaxpruefung und 402 Unit-/Struktur-/isolierten Laufzeittests, 1875 Assertions; zusaetzlich 92 reine Adapter-/Reglerpruefungen in eigenem Namespace im Symcon-8.0-Entwicklungskernel. git diff --check erfolgreich. Native vollstaendige Modul-Funktionstests angepasst, aber nicht ausgefuehrt. Kein Hardwaretest, keine Stellbefehle an die Anlage, keine Feldabnahme. Testhelfer `/srv/agent/charger_kernel_regression_20261007.py` auf ubuntu.
|
||||
- VEROEFFENTLICHT IST NICHT INSTALLIERT: Lihrenmoos wurde in diesem Korrekturauftrag nicht aktualisiert. Die zuvor eingerichtete Bedienung der fuenf Stationen bleibt unveraendert. V4, Batterie, SDL und die zeitlich befristeten Freigaben wurden nicht angefasst oder verlaengert.
|
||||
- Naechster operativer Schritt nur separat beauftragt: laufende Quelldateien/Konfiguration sichern, Konflikte zu fremden Laufzeitaenderungen vergleichen, passenden Modulstand kontrolliert installieren und frische Daten, PV/Peak, Ladepause/Wiederanlauf, Phasen und physischen Stop an realen Fahrzeugen abnehmen. Nicht pauschal alle fremden Moduldateien ueberschreiben. Die urspruengliche morgendliche Beschwerde bleibt mangels vollstaendiger Stell-/Zustandshistorie nicht zweifelsfrei einem einzigen Fehler zugeordnet.
|
||||
|
||||
|
||||
## Ladestationsinstallation vorbereitet: 07.10.2026, 18:41 UTC
|
||||
|
||||
Daniel hat die Installation von 58856816697e4720a57cac046ec1793c1325576b in Lihrenmoos beauftragt. Noch NICHT installiert: Vor Aktivierung wurde eine ausdrueckliche Rueckfrage zum erforderlichen bibliotheksweiten MC_ReloadModule gestellt, weil dieser auch Manager/Batterie neu initialisieren und bekannte Timerprobleme ausloesen kann. Kein Dienstneustart freigegeben. Die Primaerverbindung iot-symcon01 ist erreichbar. Quellenvergleich: Regler/Adapter entsprechen dem Commit-Elternstand; die Stand-alone-Moduldatei hat lediglich die noch fehlende veroeffentlichte Sollwertbereinigung. Abhaengigkeiten VerbraucherBasisTrait und Nachrichtenvertrag entsprechen dem Release. Andere Laufzeitanpassungen bleiben unangetastet.
|
||||
|
||||
Vorbereitung auf iot-symcon01: /srv/agent/lihrenmoos-charger-fix-5885681. release.json, prepared.json und source/ enthalten die drei exakt mit Git-Blob und SHA256 geprueften Dateien. PHP-8.3-CLI-Syntaxpruefung bestanden. backup/ ist 0700, Dateien 0600; drei alte Quelldateien und settings.json (3474385 Bytes) gesichert. 110 unbeteiligte PHP-/JSON-Dateien per Hash erfasst. Kein Live-Modul ausgetauscht. Vor spaeterer Ausfuehrung erneut alle before-Hashes und aktuelle Konfiguration pruefen; prepare.py nicht erneut ausfuehren/Backup nicht ueberschreiben.
|
||||
|
||||
probe-v2.json liefert echten Kernelstand 20:34:51 CEST: Symcon 8.0; Manager 17004, Batterie 44234 und fuenf Ladepunkte Status 102; periodische Timer laufen. Pico 1 verbunden mit 0 W, Easee ca. 3485 W; andere drei Ladepunkte ohne Fahrzeug. Keine neuen Hardwaretests oder Bedienvorgaben. MC-Runtime-Metadaten: MC_ReloadModule(integer InstanceID,string Module), Module Control 44866, Modulordner Enelix-EMS. Ein isolierter Versuch gezielter direkter Create/Apply-Initialisierung im ENTWICKLUNGSKERNEL wurde vom Framework als ausserhalb des Create-Kontexts abgewiesen, Testinstanz entfernt; dieser Weg ist ungeeignet und darf NICHT auf der Anlage verwendet oder umgangen werden. Die eigentlichen 402 Release-Tests und 92 reinen Kernelpruefungen bleiben davon getrennt. Die temporaeren READ-ONLY-Probehooks wurden entfernt: 12555.ips.php wieder SHA256 c702a4947ae200b23c3eecccabeb843ad6a55e97509292584ca2de779d5e4940.
|
||||
|
||||
Naechster Schritt nach Antwort: Bei Freigabe kontrollierten, gesicherten Drei-Dateien-Austausch mit regulaerem Bibliotheksreload vorbereiten/ausfuehren, keine MC_UpdateModule/RevertModule-Aktion und kein pauschales Git-Pull im Live-Checkout. Danach Ladepunkte, Manager/Batterie, periodische Timer, Bedienwerte/Boost und unveraenderte Fremdquellen ueber mehrere Zyklen kontrollieren. Bei Timerblockade keinen eigenmaechtigen Dienstneustart und keinen Ersatz-Tick-Hook. V4-Testfreigaben sind nicht verlaengert.
|
||||
|
||||
## Ladestationskorrekturen installiert: 08.10.2026, 04:47 UTC; Nachkontrolle mit Blockaden
|
||||
|
||||
Dieser Abschnitt ersetzt die vorherige Angabe "vorbereitet, nicht installiert". Daniel hat mit "du darfst" den angefragten bibliotheksweiten Reload freigegeben, NICHT den Neustart von symcon.service.
|
||||
|
||||
- Host erneut mit Primaerconnector als iot-symcon01 bestaetigt. Drei Live-Quelldateien passten exakt zum vorbereiteten Stand; alle 110 unbeteiligten PHP-/JSON-Dateien unveraendert. Vor dem Eingriff alle elf EMS-Instanzen Status 102, keine offenen Konfigurationsaenderungen; Manager- und Batterietimer liefen. Aktuelle Konfiguration verwendet, keine Ruecksetzung auf den Vortag. Live-Git bleibt develop auf 3ce9af42440c240c03b37ac475c366b7c7c2693b mit bestehenden lokalen Anpassungen; kein Git-Update, Commit oder Push.
|
||||
- Um 06:47:21-06:47:23 CEST wurden ausschliesslich LadestationStandAlone/module.php, libs/LadestationAdapter.php und libs/LadestationRegler.php aus Release 58856816697e4720a57cac046ec1793c1325576b installiert. MC_ReloadModule(44866, 'Enelix-EMS') gab true zurueck. Kein MC_UpdateModule/RevertModule, kein Dienstneustart, keine V4-/SDL-/Boost-Bedienaktion und kein zusaetzlicher Hardwaretest.
|
||||
- Frische native Sicherung: /srv/agent/lihrenmoos-charger-fix-5885681/backup-native-20261008-044721. Ordner 0700, Dateien 0600; drei alte Quellen, aktuelle native Instanzkonfigurationen und settings.json, 3475706 Bytes, SHA256 bf55d4290e892c678e191131f91adb10a97d030d240ee73ad4e241a9d6497b54. Fruehere Sicherung erhalten. Die drei neuen Dateien sind SHA256-geprueft und Besitzer/Gruppe/Dateimodus nativ erhalten. Installer, begrenzte Nachkontrolle und vorbereiteter Ruecksetzweg syntaxgeprueft; Ruecksetzung nicht ausgefuehrt.
|
||||
- Echte Kernel-Nachkontrolle 06:48:06-06:50:36 CEST: 31 Stichproben ueber 150 Sekunden. Alle elf Konfigurationshashes, Bedienwerte inklusive Boost und 67 UI-Objekte unveraendert; V4-Schalter 46716 weiter false. Alle 110 Fremdquellen unveraendert. Symcon8.0, Dienst laut systemctl seit 06.10.2026 16:32:09 CEST aktiv, hier nicht neu gestartet.
|
||||
- Pico 1/2 und beide go-e Status 102; alle acht Status-/Meldetimer laufen. Alte go-e-Sollwerte 3680/10944 W wurden zu 0 bereinigt. Pico 1 weiterhin verbunden, 0 W Istleistung; unsichere alte Einphasigkeit jetzt korrekt unbekannt (0). Kein erfolgreicher physischer Ladestart nachgewiesen. Pico 2 und beide go-e ohne Fahrzeug. Diese Installation ist keine Feldabnahme aller Ladepunkte.
|
||||
- WICHTIG: Bekannte Batterietimerblockade ist NACH DIESEM Reload erneut aufgetreten. Alter Timer 243 bleibt Running=true mit unveraendertem LastRun 1791434840. Neue Batterie-Timer 304 (1-s-Rueckmeldung) und 306 (Meldezyklus) haben LastRun=0; auch neue verzoegerte Rueckmeldung/Timeout-/Freigabetimer laufen nicht. Instanzstatus 102 und sich weiter aendernde Werte sind keine Entwarnung. Alle sechs geprueften periodischen Managertimer laufen. Die nach Namen zusammengefassten Zwischenzaehler in verification.json koennen beim doppelten Timer verfalscht sein; finished.json wertet deshalb jeden Timer per TimerID aus und bestaetigt die Blockade.
|
||||
- Easee-Meldezyklus laeuft, aber Gateway 55829 bleibt Status203/Connected=false, Meldung "Easee-Ereignisverbindung wird aufgebaut."; WS-Parent45241 Status200, Ladepunkt46052 Status202 mit "Easee Gateway ist nicht verbunden." Das ist gegenueber dem Vorzustand nicht wiederhergestellt. Gateway-Wartungstimer laeuft; keine Zugangsdaten ausgegeben oder veraendert. Ursache der fehlenden Wiederverbindung nicht abschliessend bestimmt.
|
||||
- Verbindlicher Ergebnisbericht /srv/agent/lihrenmoos-charger-fix-5885681/finished.json: status=installed_runtime_issues_restart_permission_requested, runtimeHealthy=false. install-result.json belegt die Installation, verification.json den zeitlichen Verlauf. Keine erfolgreiche Gesamtabnahme behaupten.
|
||||
- Alle temporaeren Hooks entfernt; Beobachterskript12555 bytegleich SHA256 c702a4947ae200b23c3eecccabeb843ad6a55e97509292584ca2de779d5e4940. Kein externer Tick-Ersatz, kein Wiederanlauf-Hook. Install-/Preflight-Claims NICHT loeschen oder Installer blind wiederholen. rollback.php ist vorbereitet, nicht ausgefuehrt; Quell-Rollback behebt nicht nachgewiesen die Kernel-Timerblockade und wuerde einen weiteren Reload erfordern.
|
||||
- Daniel wurde ausdruecklich um einen zusaetzlichen kontrollierten Neustart des gesamten Symcon-Dienstes gebeten, weil weitere Anlagenfunktionen kurz betroffen sind. Diese Freigabe steht bei Abschluss noch aus. Erst nach klarer Antwort frische Sicherung/Statuspruefung, dann erlaubten Neustart versuchen; fruehere systemctl-Neustartversuche verlangten interaktive Authentifizierung. Keine Rechte umgehen. Danach Batterietimer und Easee samt Ladestationen/Manager erneut ueber mehrere Zyklen pruefen. V4-Testfreigabe vom 07.10. nicht erneuern oder reaktivieren.
|
||||
|
||||
|
||||
## Batterie-Timer: Veroeffentlichung 08.10.2026, 05:18 UTC
|
||||
|
||||
- Daniel Haefliger beauftragte Commit/Push unserer Timerkorrektur nach develop
|
||||
und beta, Autor dh_Agent, Zugang dh, danach Lihrenmoos-Update.
|
||||
- ENELIX/Enelix-EMS: Commit d42cfb334284a574ef160bde6d28b45a622129c7,
|
||||
fix(battery): keep native timer callbacks reload-safe. Autor und Committer
|
||||
dh_Agent <dh@belevo.ch>. Konfigurierter Login dh und authentifizierte
|
||||
Repository-Pushberechtigung geprueft; Profilabfrage mangels Token-Scope nicht
|
||||
verfuegbar. Normaler Push nach develop erfolgreich und per ls-remote bestaetigt.
|
||||
- beta NOCH NICHT aktualisiert: weiterhin 58856816697e4720a57cac046ec1793c1325576b.
|
||||
main unveraendert b6253f9e55c659913ebb43783fe2b6a72cfd180f.
|
||||
- Drei Produktionsdateien: alle sechs nativen Batterietimer gehen ueber den
|
||||
generierten ENELIX_BatterieTimerAktion-Wrapper; neue strikt cache-only
|
||||
Diagnose ENELIX_GetV4BatterieRueckmeldungCache. Keine neuen Tick-Hooks,
|
||||
keine erneuerten Zeitstempel, keine gelockerten Frische-/Schutzpruefungen.
|
||||
Bestehende APIs, Konfiguration, Energiezaehler und EV-/SDL-Aufteilung erhalten.
|
||||
- Tests und Migrationsgrenzen: tests/BatterieTimer/README.md. Vorher bestanden
|
||||
134 isolierte CLI-Pruefungen und insgesamt acht native Reloadtests, davon
|
||||
sechs am 08.10.2026. git diff --check erfolgreich. Zusaetzliche PHPUnit-
|
||||
Einbindung der 28 Vertragspruefungen ist committed, aber der zusammengefuehrte
|
||||
aktuelle Gesamtstand hat noch keinen neuen vollstaendigen PHPUnit-Nachweis.
|
||||
- CI-Lauf 185 fuer d42cfb3 ist queued (auch die alten Laeufe 183/184 queued).
|
||||
https://git.belevo.ch/ENELIX/Enelix-EMS/actions/runs/185
|
||||
CLI-PHP fehlt auf ubuntu/enelix-services; Dockerzugriff denied. Eine separate
|
||||
grosse Source-/Testkopie nach iot-symcon01 wurde von der Sicherheitspruefung
|
||||
vor Uebertragung blockiert. Nicht als ausgefuehrten Test darstellen und diese
|
||||
Sperre nicht durch andere Uebertragungswege umgehen.
|
||||
- Sauberer develop-Releasecheckout /srv/agent/charger-fixes-20261007 wiederverwendet.
|
||||
Nur zehn eigene Dateien committed. Die vorher vorhandene composer.lock bleibt
|
||||
untracked und erhalten; kanonische schmutzige Repos nicht zurueckgesetzt.
|
||||
Sicherung /srv/agent/battery-timer-release-backup-20261008 auf ubuntu.
|
||||
- NICHT INSTALLIERT: kein weiterer Anlagenreload, kein Symcon-Neustart, keine
|
||||
Stellversuche. Die bekannte Reload-Blockade vom 08.10. 04:47 UTC und Easee-
|
||||
Stoerung sind historische Momentaufnahmen, nicht erneut live abgenommen.
|
||||
Systemctl zeigte weiterhin active/running seit 06.10.2026 16:32:09 CEST.
|
||||
- Fuer den robusten Erstwechsel wurde Daniel explizit um kontrollierten
|
||||
Stop/Installation/Start mit kurzer Unterbrechung ALLER Symcon-Ablaufe gebeten.
|
||||
Eine Antwort darauf liegt in diesem Stand noch nicht vor. Beim Rueckfall nur
|
||||
gesicherte betroffene Quellen, keine pauschalen Konfigurations-/Energie-Resets.
|
||||
Nach Freigabe aktuellen Zustand und Quellen erneut sichern/pruefen, bestehende
|
||||
Ladepunktkorrektur erhalten, dann automatische Timerfortschritte und frische
|
||||
bestaetigte Cachewerte messen. Status 102 reicht nicht. V4 bleibt unangetastet;
|
||||
die abgelaufene Stelltestfreigabe wird durch diesen Auftrag nicht erneuert.
|
||||
|
||||
## Symcon-Neustart am 08.10.2026 freigegeben, technisch abgewiesen
|
||||
|
||||
Daniel bestaetigte den angefragten kontrollierten Neustart ausdruecklich mit "top ja gerne, kannst du". Der normale Dienstneustart wurde ueber den primaeren Connector auf dem verifizierten Host iot-symcon01 versucht, vom Betriebssystem aber mit "Interactive authentication required" abgewiesen (Exit 1). Keine Rechteausweitung, kein Umweg ueber andere Connectoren oder einen privilegierten Kernelaufruf. Es fand KEIN Neustart statt: ActiveEnterTimestamp bleibt 06.10.2026 16:32:09 CEST und InvocationID 91626b4f92de4d9d8831691c75060685. Dienst weiter active/running.
|
||||
|
||||
Frische Sicherung 08.10.2026 07:39:21 UTC: /srv/agent/lihrenmoos-charger-fix-5885681/backup-restart-20261008-073921. 150 Dateien (EMS-Quellen, settings.json und urspruenglicher Beobachter), Ordner 0700/Dateien 0600, inhaltlich rueckgelesen/gehasht. Settings 3478937 Bytes, SHA256 a2c2c16a6380e523f5022a9fd61a81e1d537492471cd7c3a82f1c085b3b7c072. Zusaetzlich aktuelle native Konfigurationen aller elf EMS-Instanzen geschuetzt gesichert. Die drei Ladestationskorrekturen weiterhin exakt Release 5885681, alle 110 unbeteiligten Quellen unveraendert. Kein Modul-/Git-Update oder Push.
|
||||
|
||||
WICHTIGE NEUE BEOBACHTUNG: Schon die native Vorpruefung um 09:39:41 CEST zeigte wieder laufende Batterie-Timer 304/306, keinen alten haengenden Timer 243 mehr und Easee55829 Connected=true/Status102. Die bisherige Blockade und fehlende Easee-Verbindung haben sich bis dahin ohne einen von uns ausgefuehrten Neustart aufgeloest. Zeitpunkt und Ursache der Erholung sind nicht bestimmt. Die historische Blockade um 06:50 CEST bleibt belegt; nicht als aktuellen Dauerzustand wiederholen und die Erholung nicht dem abgewiesenen Neustart zuschreiben.
|
||||
|
||||
Der vorliegende Auftrag betrifft den Dienstneustart, nicht die in der getrennten Uebergabe dokumentierte neue Batterietimer-Veroeffentlichung d42cfb3. Deren Installation, Beta-Freigabe und weitere Tests wurden hier NICHT vorgenommen. V4-Schalter bleibt aus; keine abgelaufene Stelltestfreigabe erneuert.
|
||||
|
||||
Abgeschlossene reine Kernel-Nachkontrolle 09:42:36-09:45:11 CEST: 32 Stichproben ueber 154.998 Sekunden. Alle 18 explizit geprueften periodischen Timer bestanden, darunter Batterie-Sampler304 und Meldezyklus306, acht Pico/go-e-Status-/Meldetimer, Easee-Meldetimer, Gateway-Wartung und sechs Manager-Timer. Batterie-Meldetimer28 und Sampler31 beobachtete Fortschritte. Kein doppelter haengender Batterietimer mehr vorhanden. Alle elf EMS-Instanzen Status102 ohne offene Konfigurationsaenderungen; Easee verbunden mit einem Abonnement und leerem Fehlertext. Alle elf Konfigurationshashes, Bedienwerte einschliesslich Boost und 67 UI-Objekte unveraendert, ebenso die drei Releasequellen und 110 Fremdquellen. V4 weiter false. Dies belegt den aktuellen stabilen Beobachtungszeitraum, keine dauerhafte Behebung der Reload-Ursache.
|
||||
|
||||
Belege im Ordner /srv/agent/lihrenmoos-charger-fix-5885681: restart-prepared.json, restart-before.json, restart-attempt.json und restart-runtime-check.json (done=true, passed=true, mode=verification_without_restart). Fuer den Dienstneustart bleibt die technische Voraussetzung ein berechtigtes Administratorkonto; Benutzerfreigabe war vorhanden. Keine erneute Rueckfrage nur zur selben Freigabe noetig, aber vor einem spaeteren Versuch Zustand und Sicherung aktualisieren.
|
||||
|
||||
Temporare restartcheck-/restartverify-Beobachtung entfernt, Skript12555 wieder SHA256 c702a4947ae200b23c3eecccabeb843ad6a55e97509292584ca2de779d5e4940. Kein Tick-Ersatz oder aktiver Wiederanlauf-Hook. Letzte gemessene Leistung aller fuenf Ladepunkte 0 W; ein echter Ladestart oder die urspruengliche Pico-1-Ursache ist dadurch NICHT abgenommen. Pico1 und Easee melden ein verbundenes Fahrzeug, die anderen drei keines. Naechste fachliche Abnahme waere ein kontrollierter Ladeversuch mit bekanntem Fahrzeug und zeitgleichem Status-/Sollstromtrace; nicht aus dieser Neustartfreigabe eigenstaendig weitere Hardwaretests ableiten.
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
# Gemeinsame Veroeffentlichung 08.10.2026
|
||||
|
||||
## Freigabe und Umfang
|
||||
|
||||
Daniel Haefliger hat den aktuellen Projektstand einschliesslich weiterer
|
||||
unveroeffentlichter Aenderungen fuer develop und beta freigegeben.
|
||||
Autor und Committer: dh_Agent <dh@belevo.ch>; authentifizierter Git-Zugang: dh.
|
||||
main bleibt unveraendert. Keine Anlageninstallation, kein Reload/Neustart
|
||||
und keine erneuerte Stell- oder Testfreigabe.
|
||||
|
||||
Die Quellbasis enthaelt Batterie-Timer d42cfb3, Ladestationen 5885681,
|
||||
PHP-8.0-Kompatibilitaet 86834bb und die parallel veroeffentlichte Energy-Pie-
|
||||
Gesamtbilanz: EMS af69151 und Utils 6f44e76. Dazu kommen der gepruefte
|
||||
V4-Zwei-Schalter-Workflow in EMS und die bisherigen Dokumentationsaenderungen
|
||||
beider Bibliotheken. Historische Betriebsnotizen bleiben datiert erhalten.
|
||||
|
||||
## Abgrenzung
|
||||
|
||||
Alte Arbeitskopien bleiben unangetastet. Bereits enthaltene oder ersetzte
|
||||
Zwischenstaende werden nicht erneut angewendet. Ausgeschlossen sind
|
||||
Testhilfsdateien, lokal erzeugte composer.lock sowie zwei unvollstaendige
|
||||
alte Portal-Snapshots ausserhalb der versionierten Integrationspakete.
|
||||
Der frueher verworfene measurement_pipeline-Entwurf wird nicht integriert:
|
||||
Ein accountingEvidenceId darf keine ungepruefte Messgrenze bestaetigen.
|
||||
|
||||
## Pruefung und Migration
|
||||
|
||||
Vor Veroeffentlichung: Quellvergleich, Geheimnissuche, git diff --check,
|
||||
PHP-Syntax/PHPUnit, Dokumentationsvertrag sowie die betroffenen Node-,
|
||||
Python- und Browserpruefungen. Exakte Ergebnisse und Commit-/Remote-Nachweise
|
||||
liegen im Releaseprotokoll /srv/agent/release-all-20261008 auf ubuntu.
|
||||
Die Gitea-Tests des veroeffentlichten develop-Commits pruefen PHP 8.0;
|
||||
beta wird erst nach erfolgreichem Abschluss weitergefuehrt.
|
||||
|
||||
Ein spaeterer Anlagenrollout benoetigt eine eigene Sicherung, Driftpruefung
|
||||
und Freigabe. Fuer die Energy-Pie-Gesamtbilanz zuerst Utils, dann EMS
|
||||
aktualisieren. Farbwerte, Quellen und Archivdaten nicht zuruecksetzen.
|
||||
V4-Migration und Grenzen: EMS docs/prognose-v4-workflow.md.
|
||||
|
||||
## PR-Kurztext
|
||||
|
||||
Fuehrt Workflow und Modul-/Bedienungsdokumentation auf dem aktuellen
|
||||
Batterie-, Ladepunkt- und Energy-Pie-Stand zusammen. Bewahrt parallele
|
||||
Arbeitskopien und lokale Schutzpruefungen. Veroeffentlichung ist keine
|
||||
Betriebsfreigabe; Hardware- und Symcon-GUI-Abnahme bleiben separat.
|
||||
@@ -1,5 +1,8 @@
|
||||
# Batterie
|
||||
|
||||
Die Referenz gilt für `develop` und `beta`; `main` enthält noch kein
|
||||
installierbares Batteriemodul. [Kanalstand und bekannte Grenzen](../../../README.md).
|
||||
|
||||
> Status: implementiert. Zielplattform ist IP-Symcon ab Version 8.0,
|
||||
> Nachrichtenvertrag 4.0.
|
||||
|
||||
@@ -128,3 +131,42 @@ Transport und gemeinsame Felder folgen
|
||||
- BatterieModulstrukturTest: Metadaten, Formular, Ereignismodell und Manager-ID
|
||||
- Symcon/modules/Batterie.php: reale Modulinstanz und Registeraktionen unter
|
||||
IP-Symcon 8.0
|
||||
|
||||
## Weitere Diagnosevariablen und V4-Kompatibilität
|
||||
|
||||
| Ident | Typ / Zugriff | Bedeutung |
|
||||
| --- | --- | --- |
|
||||
| `LadezustandGueltig` | Boolean / Diagnose | Ladezustandsquelle ist vorhanden, aktuell und im zulässigen Bereich. |
|
||||
| `HystereseAktiv` | Boolean / Diagnose | Die Ladezustandshysterese beschränkt das aktuelle Leistungsangebot. |
|
||||
|
||||
Der frühere separate V4-Formularbereich ist entfernt; vorhandene Properties,
|
||||
Methoden und Kennungen bleiben kompatibel. Dies entfernt weder Schutzprüfungen
|
||||
noch historische Daten. Die Bedienung liegt im
|
||||
[Prognosebereich des Managers](../Manager/README.md).
|
||||
|
||||
| Property | Typ / Standard | Bedeutung |
|
||||
| --- | --- | --- |
|
||||
| `NetzfahrplanV4RegeltestErlaubt` | Boolean / `false` | Lokale Batteriefreigabe für den begrenzten Regeltest. |
|
||||
| `NetzfahrplanV4AktivtestErlaubt` | Boolean / `false` | Zusätzliche Freigabe für den ausdrücklich befristeten Aktivtest. |
|
||||
| `NetzfahrplanV4WatchdogVerzichtErlaubt` | Boolean / `false` | Nur dokumentierte Testanlagen-Ausnahme; keine allgemeine Empfehlung oder Dauerfreigabe. |
|
||||
| `NetzfahrplanV4GeraeteWatchdogNachweis` | String / leer | Nachweiskennung des unabhängigen Geräte-Ausfallschutzes. Ein Symcon-Timer ersetzt diesen Nachweis nicht. |
|
||||
| `NetzfahrplanV4RueckmeldungKonfiguration` | String/JSON / `{}` | Geprüfte physische Messquellen, Vorzeichen und Rückmeldezuordnung. Anlagenspezifisch, keine universelle Musterkonfiguration. |
|
||||
|
||||
Bestätigter Geräteabruf, Variablenpublikation und Sammlerzeit sind verschieden.
|
||||
Die Rückmeldung verwendet erfolgreiche Geräte-Lesevorgänge und einen kurzlebigen,
|
||||
quellengebundenen Cache. Ungültige/veraltete Bestätigungen verhindern den Test;
|
||||
ein unveränderter Messwert darf nicht künstlich frisch geschrieben werden.
|
||||
|
||||
Bekannte Betriebsgrenze: Am 6. Oktober 2026 wurden nach Modul-Reload erneut
|
||||
blockierte Batterie-Timer beobachtet. Die spätere Nachkontrolle vom 7. Oktober
|
||||
meldet laufende periodische Timer, aber keine geklärte Ursache oder physische
|
||||
V4-Abnahme. Status `102` allein beweist keine laufende Rückmeldung oder
|
||||
Watchdog-Ausführung. Automatischen Timerlauf, physisches Tracking, mehrere
|
||||
Planerneuerungen und bestätigten Null-Stopp gesondert nachweisen. Die frühere
|
||||
Testfreigabe endete am 7. Oktober und wird nicht erneuert. Keine externen
|
||||
Timer-Ersatzaufrufe und kein automatischer Aktivstart aus dieser Anleitung.
|
||||
|
||||
Beim Verwerfen einer gültigen Manager-Vorgabe wird seit `5437f3f` auch
|
||||
`Sollleistung` auf 0 W gesetzt. Das ist die Bereinigung der Vorgabe, kein
|
||||
Versprechen, dass lokale Schutz-/Nachladefunktionen und Istleistung sofort null
|
||||
werden. Der bestehende Batteriemanagement- und Gerätepfad bleibt massgeblich.
|
||||
|
||||
@@ -192,6 +192,7 @@ Nur mit `DiagnosevariablenAnzeigen=true` sichtbar:
|
||||
| `Stoerung` | Sammelstatus fuer Konfigurations- und Kommunikationsfehler. |
|
||||
| `Stoertext` | Letzte verstaendliche Fehlerbeschreibung. |
|
||||
| `Geraetehinweis` | Pico-Autorisierung und historisches letztes Ereignis, getrennt vom aktuellen Fehler. |
|
||||
| `FahrzeugMaximalstrom` | Integer in A / Anzeige. Erkannte Fahrzeuggrenze nach `FahrzeugstromErkennungszeit`; kein manuell zu setzender Ladestrom. |
|
||||
| `LetzterGeraetebefehl` | Letzter Steuerbefehl mit HTTP-Methode und URL ohne Zugangsdaten; Statusabfragen ueberschreiben ihn nicht. |
|
||||
| `LeistungsangebotDiagnose` | Aktuelles Leistungsangebot als JSON-Liste in W. |
|
||||
|
||||
@@ -199,6 +200,43 @@ Die Regellogik speichert ihren Zustand unabhaengig von der Sichtbarkeit der
|
||||
Diagnosevariablen. Das Ein- oder Ausblenden veraendert daher nicht das
|
||||
Regelverhalten.
|
||||
|
||||
## Beispiele zur Diagnose
|
||||
|
||||
`FahrzeugMaximalstrom` ist eine Integer-Diagnosevariable in A. Beispiel:
|
||||
Ein erkanntes Fahrzeuglimit von 10 A bleibt auch bei höherem Anlagenbudget
|
||||
wirksam; Angebot und Zuteilung dürfen es nicht umgehen. Die Konfiguration
|
||||
`FahrzeugstromErkennungszeit` bestimmt die Beobachtungszeit.
|
||||
|
||||
Bei unbekannten Phasen bietet die Station im freigegebenen PV-Solarbetrieb
|
||||
`[0,4104] W` an. Sind nur 3000 W zuteilbar, bleibt sie aus; die 6-A-Probe darf
|
||||
nicht am Manager vorbei starten. Bei 4104 W passender Vorgabe und frischen
|
||||
Geraetedaten kann die Probe beginnen. Eine anschliessende Messung von 0 W
|
||||
beweist keine Einphasigkeit. Im Peak-Solarbetrieb bleibt das Angebot `[0]`.
|
||||
|
||||
Pico mit `State=6` wartet auf Autorisierung und bietet `[0]`. Ein altes
|
||||
`LastWarningOrError` allein ist kein aktueller Ladefehler. Frisches `LastSeen`
|
||||
bei altem `ValueDate` reicht bei positiver Ladeleistung dagegen nicht aus:
|
||||
das Modul meldet einen Fehler und wartet auf vollstaendige frische Daten.
|
||||
|
||||
Sicheres Lesebeispiel fuer die Symcon-Schnellausfuehrung. Eine bestehende
|
||||
Stand-Alone-Instanz einsetzen; optionale, nicht angelegte Diagnosen werden
|
||||
uebersprungen. Es werden weder Zugangsdaten gelesen noch Stellbefehle gesendet.
|
||||
|
||||
```php
|
||||
<?php
|
||||
$stationId = 0; // Vorhandene Ladestation-Stand-Alone-Instanz einsetzen.
|
||||
if ($stationId <= 0 || !IPS_InstanceExists($stationId)) {
|
||||
throw new RuntimeException('Vorhandene Ladestations-ID erforderlich.');
|
||||
}
|
||||
foreach (['FahrzeugVerbunden', 'FahrzeugGeladen', 'Phasenzahl',
|
||||
'Ladestrom', 'FahrzeugMaximalstrom', 'LeistungsangebotDiagnose'] as $ident) {
|
||||
$id = @IPS_GetObjectIDByIdent($ident, $stationId);
|
||||
if ($id !== false && IPS_VariableExists($id)) {
|
||||
echo $ident . ': ' . json_encode(GetValue($id), JSON_THROW_ON_ERROR) . PHP_EOL;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Managerkommunikation
|
||||
|
||||
Das Modul implementiert
|
||||
@@ -271,6 +309,11 @@ abgeglichen am 07.10.2026.
|
||||
|
||||
## Migration der Korrektur vom 07.10.2026
|
||||
|
||||
Seit `5437f3f` wird beim Verwerfen einer Manager-Vorgabe auch die gespeicherte
|
||||
und sichtbare `Sollleistung` bereinigt. Lokale Freigaben, Mindestzeiten und
|
||||
physische Fahrzeugreaktion bleiben davon getrennt. Gesendete Steuerbefehle
|
||||
bleiben in der Diagnose erhalten. [Kanalstand und Fehlerkorrekturen](../../../README.md).
|
||||
|
||||
Vor Installation laufende Moduldateien und Konfiguration sichern und fremde
|
||||
Anpassungen vergleichen. Beim ersten `ApplyChanges` mit Erkennungsversion 2
|
||||
werden alte, moeglicherweise aus 0 W abgeleitete Phasen verworfen. Ein alter
|
||||
|
||||
@@ -464,3 +464,159 @@ oder Stellbefehl ist Teil dieser Quellcode-Aenderung.
|
||||
- Anbieterformate für Prognose und Störüberwachung festlegen.
|
||||
- Produktive signierte Lizenz-Leases nach Abschluss des Entwicklungsvertrags integrieren.
|
||||
- Verhalten und Messabgrenzung bei Untermanagern im Anlagentest bestätigen.
|
||||
|
||||
## Ergänzungen zum Kanalstand vom 8. Oktober 2026
|
||||
|
||||
Diese Referenz gilt für Testing (`develop`) und Beta mit Quellbasis `5885681`.
|
||||
Stable (`main`, Quellbasis `b6253f9`) enthält noch keinen installierbaren Manager.
|
||||
Die Kanalnamen sind keine Anlagenabnahme. Die [Kanalübersicht](../../../README.md)
|
||||
trennt Funktionen, Fehlerkorrekturen und noch offene Betriebsnachweise.
|
||||
|
||||
### Prognosebedienung und Netzfahrplan V4
|
||||
|
||||
Im Bereich **Prognose / Forecast** sind Topologie, Empfang, Vorschau und bewusste
|
||||
Start-/Stoppbedienung zusammengeführt. `PrognoseAktiv` schaltet Telemetrie und
|
||||
Topologiesynchronisation ein, startet aber keine V4-Regelung. `NetzfahrplanAktiv`
|
||||
gehört weiterhin zum bisherigen Netzfahrplanregler. Bei eingerichteter V4-
|
||||
Konfiguration wird dessen ausgeschalteter Altschalter verborgen; ein aktiver
|
||||
Altregler bleibt zum Ausschalten sichtbar. Beide Regler nicht parallel starten.
|
||||
|
||||
Die neue Bedienung `FormNetzfahrplanSchalten` prüft gespeicherte Konfiguration,
|
||||
Lizenz und lokale Testfreigaben erneut. Ausschalten bleibt bei Lizenzverlust
|
||||
möglich. Der Stopp widerruft die Testsitzung und kann danach eine frisch
|
||||
berechnete normale EMS-Zuteilung auslösen. Er ist kein anlagenweiter Not-Aus
|
||||
und löscht keinen unabhängigen SDL-Auftrag.
|
||||
|
||||
V4 ist ein begrenzter Testpfad, kein freigegebener Dauerregler. Ein vorhandener
|
||||
Plan, `optimal`, `shadow_seen` oder eine erfolgreiche Befehlsquittung belegt
|
||||
weder physische Leistungsnachführung noch Einsparungen. Nach dem Modul-Reload
|
||||
vom 6. Oktober wurde eine Batterietimerblockade dokumentiert. Die spätere
|
||||
Nachkontrolle vom 7. Oktober meldet laufende periodische Timer, keine physische
|
||||
V4-Abnahme. Ursache und Wiederholbarkeit des Reload-Problems bleiben offen;
|
||||
nach Updates Timer erneut prüfen. Watchdog, Planwechsel und sicherer Stopp
|
||||
bleiben separat abzunehmen. Die frühere befristete Testfreigabe endete am
|
||||
7. Oktober 2026. Diese Dokumentation erneuert sie nicht; Schutzprüfungen dürfen
|
||||
nicht umgangen werden.
|
||||
|
||||
| Property | Typ / Standard | Zweck und Grenze |
|
||||
| --- | --- | --- |
|
||||
| `NetzfahrplanV4SchattenAktiv` | Boolean / `false` | Versand nativer Betriebsdaten für die Schattenplanung; allein keine Stellbefehle. |
|
||||
| `NetzfahrplanV4EmpfangAktiv` | Boolean / `false` | Planempfang und lokale Vorschau; Empfang ist keine Ausführung. |
|
||||
| `NetzfahrplanV4NetzladenErlaubt` | Boolean / `false` | Netzladen in den Planungsrandbedingungen erlauben; ersetzt keine lokale Freigabe. |
|
||||
| `NetzfahrplanV4BatterieOptionen` | String/JSON / `{}` | Batteriebezogene Planungsoptionen, gebunden an die Asset-ID der Topologie. |
|
||||
| `NetzfahrplanV4MessnachweisVariableID` | Integer / `0` | Stringvariable mit geprüftem JSON-Messnachweis, keine Leistungsvariable. |
|
||||
| `NetzfahrplanV4BezugszaehlerQuellen` | String/JSON / `[]` | Separate Bezugszählerquellen für Viertelstunden-/Monatspeaknachweise. Keine Übernahme eines ungeprüften Altzählers. |
|
||||
| `NetzfahrplanV4MessdatenAktiv` | Boolean / `false` | Rohmessaufnahme alle 30 s mit Originalzeitstempeln, lokaler Outbox und bestätigtem Versand. |
|
||||
| `NetzfahrplanV4ArchivAktiv` | Boolean / `false` | Optionale lokale Archivierung bestätigter Messdaten; kein Ersatz für externe Sicherungen. |
|
||||
| `NetzfahrplanV4Messkonfiguration` | String/JSON / `{}` | Validierte Quellen-/Messgrenzenzuordnung, an Installation und Manager gebunden. |
|
||||
| `NetzfahrplanV4Datensatz` | String / leer | Datensatzkennung, 1 bis 80 Buchstaben, Ziffern, `_` oder `-`. |
|
||||
| `NetzfahrplanV4RegeltestErlaubt` | Boolean / `false` | Lokale Freigabe des begrenzten Regeltests; weitere Server-/Batteriegates bleiben erforderlich. |
|
||||
| `NetzfahrplanV4AktivtestErlaubt` | Boolean / `false` | Zusätzliche Freigabe des ausdrücklich begrenzten Aktivtests, keine Produktionsfreigabe. |
|
||||
| `NetzfahrplanV4WatchdogVerzichtErlaubt` | Boolean / `false` | Nur dokumentierte Testanlagen-Ausnahme, niemals Ersatz für einen Geräte-Watchdog im Dauerbetrieb. |
|
||||
|
||||
Komplexe Messkonfigurationen müssen aus den tatsächlichen Quellen abgeleitet
|
||||
werden. Leere Standardwerte sind nicht ausführbare Musterkonfigurationen.
|
||||
Vorhandene Datenkennungen, Outbox-Cursor und Bestätigungen nicht manuell ändern.
|
||||
Normaler Rohdatenversand erfolgt im 60-s-Abstand; ein bestätigter Rückstand kann
|
||||
schneller abgearbeitet werden, Fehler warten mindestens 60 s. `scheduled`
|
||||
bezeichnet daher nicht automatisch einen Fehler. Die letzte Quittung ist
|
||||
entscheidend. Ein HTTP-429 beim Planempfang behält seinen Backoff.
|
||||
|
||||
| Variable | Typ / Zugriff | Inhalt |
|
||||
| --- | --- | --- |
|
||||
| `NetzfahrplanV4Vorschau` | String/HTML / Anzeige | Geprüfte Planvorschau ohne Stellfreigabe. |
|
||||
| `NetzfahrplanV4VorschauJSON` | String/JSON / Diagnose | Plan-, Eingangs- und Ablehnungsdiagnose. |
|
||||
| `NetzfahrplanV4Datenstatus` | String/JSON / Diagnose | Aufnahme, Versand, Datensatz und letzte Bestätigung; `controlEnabled=false` bezieht sich auf diesen Datenweg. |
|
||||
| `NetzfahrplanV4Aktivtest` | Boolean / bedienbar | Bestehender Schalter für den begrenzten Testbetrieb; kein automatischer Start beim Update. |
|
||||
|
||||
Die Idents bleiben für bestehende Verknüpfungen erhalten. Die separaten
|
||||
V4-Diagnosevariablen sind im integrierten Stand verborgen; die Bedienung erfolgt
|
||||
im Prognosebereich. Verborgene Diagnosen sind nicht gelöscht.
|
||||
|
||||
### Weitere Properties und Diagnosewerte
|
||||
|
||||
| Property | Typ / Standard | Beschreibung |
|
||||
| --- | --- | --- |
|
||||
| `StoerueberwachungAktiv` | Boolean / `false` | Optionale Übertragung des Störungszustands ans Portal. |
|
||||
| `StoerungsSendeintervall` | Integer / `300` | Sendeintervall der Störungsüberwachung in Sekunden. |
|
||||
| `DiagrammPVModus` | Integer / `0` | `0` gesamt, `1` einzeln, `2` gesamt und einzeln. |
|
||||
| `DiagrammBatterieModus` | Integer / `0` | `0` gesamt, `1` einzeln, `2` gesamt und einzeln. |
|
||||
| `LadestationenSeparatAnzeigen` | Boolean / `true` | Ladestationen in neu aufgebauten Darstellungen separat führen. |
|
||||
| `VerbraucherSeparatAnzeigen` | Boolean / `true` | Weitere Verbraucher separat führen. Hausdarstellung wird entsprechend abgegrenzt. |
|
||||
| `EnergieflussLeistungseinheit` | Integer / `0` | `0` W, `1` kW; interne Regelungswerte bleiben W. |
|
||||
| `PrognosePVVariableID`, `PrognoseHausverbrauchVariableID`, `PrognoseSOCVariableID` | Integer / `0` | Verdeckte Altproperties; neue Messquellen über die Anlagentopologie pflegen. |
|
||||
| `MessungPVLeistungVariableID`, `MessungHausverbrauchLeistungVariableID`, `MessungBatterieleistungVariableID` | Integer / `0` | Verdeckte frühere Messquellen, nicht als zweite aktive Topologie konfigurieren. |
|
||||
| `MessungPVLeistungsfaktor`, `MessungHausverbrauchLeistungsfaktor`, `MessungBatterieleistungsfaktor` | Float / `1.0` | Zugehörige frühere Normierungsfaktoren. |
|
||||
| `LizenzAnschluss` | String/JSON / `{}` | Verdeckte Altproperty; aktuelle Aktivierung über `Lizenzcode`. Keine Zugangsdaten in Beispielen. |
|
||||
|
||||
| Variable | Typ / Einheit | Beschreibung |
|
||||
| --- | --- | --- |
|
||||
| `NichtGeregelteGeraete` | String/JSON | Diagnose nicht geregelter Geräte. |
|
||||
| `Monatsgrenzen` | String/JSON | Diagnose der Monatsgrenzen; gleichnamige Property ist die Konfiguration. |
|
||||
| `EnergieFunFacts` | String/HTML | Optionale Energy-Facts-Anzeige. |
|
||||
| `SDLLeistungArchiv` | Float / W | Separate signierte SDL-Leistung. |
|
||||
| `SDLSOCArchiv` | Float / % | Separater SDL-Ladezustand. |
|
||||
| `SDLLadenEnergie`, `SDLEntladenEnergie` | Float / kWh | Getrennte integrierte SDL-Richtungen. |
|
||||
| `EnergieflussPV`, `EnergieflussNetz`, `EnergieflussHaus`, `EnergieflussBatterie` | Float / W oder kW | Verborgene Anzeigequellen des Energieflusses, keine Stellregister. |
|
||||
| `EnergieflussSDL` | Float / W oder kW | Optionaler separater SDL-Knoten; verwendet die Einheit des Energieflusses. |
|
||||
| `EnergieflussIst_<InstanzID>`, `EnergieflussSoll_<InstanzID>` | Float / W oder kW | Darstellungswerte je separat geführtem Verbraucher. |
|
||||
| `DiagrammHausLeistung`, `DiagrammHausEnergie` | Float / W bzw. kWh | Haus ohne separat dargestellte Verbraucher. |
|
||||
| `DiagrammPVLeistung_<Hash>`, `DiagrammPVEnergie_<Hash>` | Float / W bzw. kWh | Einzel-PV-Quellen aus der Topologie. |
|
||||
| `DiagrammBatterieLeistung_<Hash>`, `DiagrammBatterieLaden_<Hash>`, `DiagrammBatterieEntladen_<Hash>` | Float / W bzw. kWh | Einzelbatterie und richtungsgetrennte Energie. |
|
||||
| `DiagrammVerbraucherLeistung_<InstanzID>`, `DiagrammVerbraucherEnergie_<InstanzID>` | Float / W bzw. kWh | Einzelverbraucher und integrierte Energie. |
|
||||
|
||||
Die dynamischen Variablen entstehen nur bei passenden Quellen und aktivierter
|
||||
Darstellung. `<Hash>` ist eine vom Modul berechnete stabile Kennung, keine
|
||||
einzutragende Objekt-ID. Bestehende individuelle Energieflussknoten, Diagramm-
|
||||
reihen und Energy-Pie-Messquellen bleiben erhalten. Anzeigeoptionen bei einer
|
||||
Migration nicht zum Erzwingen eines Neuaufbaus aus- und wieder einschalten.
|
||||
|
||||
### SDL und Energieanteile: Beispiel
|
||||
|
||||
Bei 10 kW PV, 2 kW Netzbezug, 3 kW Batterieladung und 4 kW separat abgegrenzter
|
||||
SDL-Ladung ergibt sich `max(0, 10 + 2 - 3 - 4) = 5 kW` Hauslast. Ein Faktor
|
||||
`1000` wandelt eine kW-Quelle in W um. Eine bereits in der Batteriemessung
|
||||
enthaltene SDL-Leistung darf nicht ein zweites Mal abgezogen werden.
|
||||
|
||||
Bei aktiver SDL lässt sich aus dem gemeinsamen Netzbezug nicht eindeutig
|
||||
bestimmen, welcher Hausverbrauch aus PV stammt. Der Manager setzt deshalb
|
||||
`EnergieanteileBerechenbar=false` am eigenen Energy Pie. Zähler bleiben sichtbar;
|
||||
Autarkie und Eigenverbrauch werden als nicht bestimmbar statt als null angezeigt.
|
||||
Zuerst Utils aktualisieren: Erkennt ein altes Utils diese Property nicht, blendet
|
||||
EMS den eigenen Energy Pie aus und protokolliert den Aktualisierungsbedarf.
|
||||
Die Regelung wird dadurch nicht gestoppt.
|
||||
|
||||
### Sicheres Lesebeispiel
|
||||
|
||||
In der Symcon-Schnellausführung zuerst eine vorhandene Manager-ID einsetzen.
|
||||
Das Beispiel liest nur ausgewählte Werte, keine Lizenzdaten, und gibt keine
|
||||
Stellbefehle aus. Fehlende optionale Diagnosevariablen werden übersprungen.
|
||||
|
||||
```php
|
||||
<?php
|
||||
$managerId = 0; // Vorhandene Manager-Instanz eintragen.
|
||||
if ($managerId <= 0 || !IPS_InstanceExists($managerId)) {
|
||||
throw new RuntimeException('Vorhandene Manager-ID erforderlich.');
|
||||
}
|
||||
foreach (['Aktiv', 'Betriebsart', 'Netzleistung', 'SDLStatus'] as $ident) {
|
||||
$id = @IPS_GetObjectIDByIdent($ident, $managerId);
|
||||
if ($id !== false && IPS_VariableExists($id)) {
|
||||
echo $ident . ': ' . json_encode(GetValue($id), JSON_THROW_ON_ERROR) . PHP_EOL;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## V4-Zwei-Schalter-Workflow (08.10.2026)
|
||||
|
||||
Diese Bedienung ersetzt die historische separate V4-Testbedienung; Altangaben
|
||||
weiter unten erteilen keine Freigabe fuer den neuen Workflow.
|
||||
|
||||
| Property | Typ / Standard | Wirkung |
|
||||
| --- | --- | --- |
|
||||
| `PrognoseAktiv` | Boolean / `true` | Prognose lernen; Uebertragung erfordert Lizenz und gueltige Messzuordnung. |
|
||||
| `NetzfahrplanRegelungAktiv` | Boolean / `false` | Explizite lokale Regelanforderung. Kein Aktivstatus ohne frischen Plan, gueltige Rueckmeldung und lokale Schutzpruefung. |
|
||||
|
||||
Vorhandene Spezialzuordnungen bleiben erhalten. Alte Testschalter werden nicht
|
||||
in eine Regelanforderung umgedeutet. Bei ungueltigen Daten bleibt der normale
|
||||
lokale Regelpfad massgeblich. Eine Portalbestaetigung ist kein physischer
|
||||
Soll-/Ist-Nachweis. [Einrichtung, Migration und Grenzen](../../prognose-v4-workflow.md).
|
||||
|
||||
+12
-6
@@ -1,9 +1,7 @@
|
||||
# EMS-Module und Modulentwürfe
|
||||
|
||||
> Manager, Warmwassererwaermer, Pufferspeicher, Batterie, Verbraucher 1-Stufig,
|
||||
> Waermepumpe, Ladestation Stand-Alone, Easee Gateway und Ladestation Gateway
|
||||
> sind als installierbare IP-Symcon-Module umgesetzt. Die weiteren Ordner
|
||||
> enthalten Besprechungsgrundlagen.
|
||||
> Alle neun unten aufgeführten Module sind in Testing und Beta implementiert.
|
||||
> Stable enthält sie noch nicht. [Kanalstand und Fehlerstatus](../../README.md).
|
||||
|
||||
Alle steuerbaren Verbraucher verwenden die gemeinsamen Datenpunkte aus der
|
||||
[EMS-Schnittstelle](../Schnittstelle.md). In den Modul-READMEs stehen deshalb
|
||||
@@ -24,5 +22,13 @@ nur zusätzliche Properties, Variablen, Zustände und offene Punkte.
|
||||
## Review-Regel
|
||||
|
||||
`0*` bezeichnet einen noch nicht eingerichteten Anlagenwert. Offene Punkte
|
||||
werden nicht durch Annahmen ersetzt. Erst nach Freigabe wird aus einem Entwurf
|
||||
ein Ordner mit `module.json`, `form.json`, `module.php` und Unit-Tests.
|
||||
werden nicht durch Annahmen ersetzt. Properties sind gespeicherte Einstellungen;
|
||||
Variablen sind Laufzeitwerte. Nur ausdrücklich bedienbare Variablen dürfen als
|
||||
Aktion verwendet werden. Diagnosen und dynamische Darstellungen entstehen teils
|
||||
erst bei aktivierter Option und passenden Quellen. Interne Attribute sind
|
||||
keine frei zu bearbeitenden Benutzer-Variablen.
|
||||
|
||||
Der Abgleich vom 8. Oktober 2026 erfasst die festen Property-/Variablenkennungen
|
||||
der Module und eingebundenen Traits; dynamische Manager-Anzeigen stehen in der
|
||||
Manager-Referenz. Beispiele verwenden Platzhalter und schalten ohne ausdrückliche
|
||||
Beschreibung keine Geräte. Eine nachgewiesene Anlagenabnahme bleibt getrennt.
|
||||
|
||||
@@ -87,3 +87,22 @@ Die Rückmeldung ist verpflichtend: entweder eine numerische Leistungsmessung
|
||||
oder ein Boolean-Betriebsstatus. Bei ungültiger Konfiguration, fehlgeschlagenem
|
||||
Schalten oder widersprüchlicher Rücklesung setzt das Modul seinen Status auf
|
||||
Fehler und meldet sich dem Manager als nicht verfügbar.
|
||||
|
||||
## Vollständige Sperr- und Laufzeitdiagnose
|
||||
|
||||
`DiagnosevariablenAnzeigen` ist eine Boolean-Property mit Standard `false`.
|
||||
Sie ergänzt bei Bedarf folgende reine Anzeigevariablen:
|
||||
|
||||
| Ident | Typ / Einheit | Bedeutung |
|
||||
| --- | --- | --- |
|
||||
| `AnlaufAusstehend` | Boolean | Ein angeforderter Anlauf ist noch nicht abgeschlossen. |
|
||||
| `WiederholsperreAktiv` | Boolean | Erneuter Anlauf ist wegen der Wiederholsperre gesperrt. |
|
||||
| `SperrerholungAktiv` | Boolean | Sperrerholung beeinflusst den aktuellen Betriebszustand. |
|
||||
| `RestMindestlaufzeit` | Integer / s | Noch verbleibende Mindestlaufzeit. |
|
||||
| `RestMindestsperrzeit` | Integer / s | Noch verbleibende Mindestsperrzeit. |
|
||||
|
||||
Beispiel: Eine ausstehende Schaltung bei `RestMindestsperrzeit=120` ist zunächst
|
||||
eine einzuhaltende Schutzzeit, kein Anlass zum Umgehen des Sperrkontakts.
|
||||
Die Wärmepumpe besitzt mit `heat_pump` ein eigenes Lizenzkontingent; eine
|
||||
Boilerlizenz ersetzt es nicht. Eine Portal-Bestelloberfläche ist erst nach
|
||||
passendem Backend-Rollout nutzbar, nicht allein durch Veröffentlichung im Git.
|
||||
|
||||
@@ -404,3 +404,15 @@ Wesentliche Unterschiede:
|
||||
Manager.
|
||||
- Die neue Modul-ID erfordert eine neue Instanz; eine automatische Umwandlung
|
||||
des Enelix-1-Objekts findet nicht statt.
|
||||
|
||||
## Plausibilitätsgrenzen der Temperatur
|
||||
|
||||
| Property | Typ / Standard | Bedeutung |
|
||||
| --- | --- | --- |
|
||||
| `TemperaturUntergrenze` | Float / `0.0` | Untere zulässige Messwertgrenze in °C. |
|
||||
| `TemperaturObergrenze` | Float / `100.0` | Obere zulässige Messwertgrenze in °C. |
|
||||
|
||||
Diese Grenzen prüfen die Temperaturquelle; sie ersetzen nicht die Soll- oder
|
||||
Mindesttemperatur. Beispiel: Eine Quelle mit 45 °C liegt innerhalb der
|
||||
Standardgrenzen. Ein Sensorfehler von -127 °C ist kein gültiger Kaltwasserwert.
|
||||
Grenzen nur passend zum realen Sensor und zur Anlage konfigurieren.
|
||||
|
||||
@@ -0,0 +1,97 @@
|
||||
# V4-Prognose und lokale Batterieregelung
|
||||
|
||||
## Ziel und Bedienung
|
||||
|
||||
Der Prognosebereich des Managers hat zwei Schalter:
|
||||
|
||||
1. **Netzdaten senden und Prognosen lernen**: bei neuen Instanzen vorausgewaehlt;
|
||||
Datenerfassung und Versand beginnen erst mit gueltiger Netzfahrplanlizenz und
|
||||
vollstaendiger Messzuordnung. Empfang und Planungsdatenversorgung sind integriert.
|
||||
2. **Batterie nach Netzfahrplan regeln**: standardmaessig aus. Erst bei gueltigem
|
||||
Modell, Plan, frischen lokalen Messungen und erfuellten Schutzbedingungen bereit.
|
||||
Ein angeforderter Schalter bleibt auch bei Fehlern abschaltbar.
|
||||
|
||||
Die normalen Symcon-Konfigurationseinstellungen werden mit Uebernehmen gespeichert.
|
||||
Die Zustaende sind Aus, Daten sammeln, Lernen, Bereit, Aktiv und Unterbrochen.
|
||||
Der Grund einer Sperre wird angezeigt. Die Servermeldung Aktiv setzt eine frische
|
||||
lokale Bestaetigung voraus; sie ist kein Nachweis physisch ausgefuehrter Leistung.
|
||||
|
||||
## Verantwortlichkeiten
|
||||
|
||||
- Der V4-Dienst lernt die bereinigte Lastprognose und berechnet den Netzfahrplan.
|
||||
PV-Prognose, Wetter- und Tarifversorgung bleiben bestehende Eingangsdienste.
|
||||
- Der Manager misst die Abweichung zum V4-Netzziel und korrigiert ausschliesslich
|
||||
eine eindeutig zugeordnete Batterie. Andere Verbraucher behalten ihre normale
|
||||
Zuteilung; deren gemessene Leistungsveraenderung wird genau einmal beruecksichtigt.
|
||||
- Das Batteriemodul bleibt der einzige Geraetetreiber. BMS-/SOC-Grenzen,
|
||||
Leistungsangebote, lokale Zeitueberwachung und Geraeteschutz bleiben wirksam.
|
||||
- Lizenzportal und Manager verwenden denselben Workflow. PV/Haus, Bezugs- und
|
||||
Einspeisepreise, Netzziel, Batterie, SOC und Kosten stammen aus dem jeweiligen
|
||||
eingefrorenen Plan. Historische Daten bleiben getrennt erhalten.
|
||||
|
||||
## Neue Installation
|
||||
|
||||
Manager, Netzleistungsmessung, Wirkenergie-Bezugszaehler, PV-/Batterietopologie und
|
||||
zugeordneten Batterieregler konfigurieren. Leistungseinheiten und Vorzeichen muessen
|
||||
zum bestehenden Batterieregler passen. Die normale Lizenz an genau diese Installation
|
||||
binden; es werden keine festen fremden Anlagen- oder Objektkennungen uebernommen.
|
||||
|
||||
Die automatische Ersteinrichtung unterstuetzt eindeutig getrennte AC-PV- und
|
||||
Batteriemessungen aus den bereits unterstuetzten M-Bus-/ModBus-Adaptern. Die
|
||||
physische Batterie wird einmal abgezogen, kein virtueller Speicher oder SDL-Kanal
|
||||
erfunden. Die bestaetigte physische Rueckmeldung wird fuer diese Topologie ohne
|
||||
zusatzlichen V4-Konfigurationsschalter zugeordnet. Individuelle bestehende
|
||||
Rueckmeldungs- und Messkonfigurationen haben Vorrang.
|
||||
|
||||
Fuer das erste Modell gelten mindestens 24 nutzbare aequivalente Messstunden,
|
||||
95 Prozent Fensterabdeckung und maximal 5 Sekunden unbedeckte Zeit pro Fenster.
|
||||
Das ist keine Garantie fuer Bereitschaft nach genau 24 Stunden. Fehlende Daten,
|
||||
Preise, unklare Topologie oder eine fehlende Geraeteschutzpruefung bleiben Sperrgruende.
|
||||
Neue Anlagen duerfen gekennzeichnete Peak-/Viertelstundenschaetzungen aus echten,
|
||||
lueckenlos passenden Zaehlerdaten verwenden. Das erzeugt keinen Abrechnungsnachweis.
|
||||
|
||||
Vor normaler aktiver Regelung ist insbesondere der separat dokumentierte
|
||||
unabhaengige Geraete-Watchdog erforderlich. Ein alter Testverzicht, eine modellierte
|
||||
virtuelle Batterie oder eine abgelaufene Testfreigabe werden nicht in eine
|
||||
Produktionsfreigabe umgewandelt. Spezialanlagen mit SDL, geteiltem Speicher oder
|
||||
Hybrid-/DC-Bilanz benoetigen weiterhin ihre explizite fachliche Zuordnung.
|
||||
|
||||
## Migration und Rueckfall
|
||||
|
||||
- Alte Netzfahrplan-Einstellungen und Archive bleiben gespeichert, werden aber
|
||||
nicht mehr zum Abruf oder zur Regelung des alten Fahrplans verwendet.
|
||||
- Eine alte Netzfahrplan- oder Testfreigabe aktiviert den neuen Schalter niemals.
|
||||
- Datensatzkennungen sind an Installation und Messzuordnung gebunden. Eine
|
||||
Aenderung der Zuordnung stoppt die automatische Einrichtung zur Pruefung;
|
||||
vorhandene Rohdaten, Cursor und individuelle Servereinstellungen bleiben erhalten.
|
||||
- Lernen ausschalten stoppt Versand und serverseitiges Lernen. Der aktive
|
||||
Netzfahrplan benoetigt weiterhin eingeschaltetes Lernen und frische Daten.
|
||||
- Bei fehlendem oder ungueltigem Plan erfolgt keine neue V4-Korrektur. Die normale
|
||||
lokale Managerregelung bleibt erhalten. Ein normaler Batteriebefehl kann daher
|
||||
weiterhin ungleich null sein; Fahrplan aus bedeutet nicht Batterie gesperrt.
|
||||
- Ein abgelehnter Verbraucher-Stellbefehl wird nicht bestaetigt. Die korrigierte
|
||||
Batterie wird zuletzt uebergeben; bei vorherigem Fehler gilt ihre normale Zuteilung.
|
||||
- Empfangsquittungen sind keine Ausfuehrungsquittungen. Die urspruengliche
|
||||
Empfangszeit einer behaltenen Planhuelle wird niemals erneuert.
|
||||
|
||||
## Auslieferung und Abnahme
|
||||
|
||||
Backend, authentifizierte Portal-Bridge, Prognose-Publisher, Portal-Assets sowie
|
||||
Manager und neue Hilfsklassen gemeinsam ausliefern. Neue Datentabellen sind additiv;
|
||||
vor einer produktiven Umstellung konsistente Datenbanksicherung mit geprueftem
|
||||
Ruecksetzweg erstellen. Alte Installationsskripte nicht blind wiederverwenden.
|
||||
|
||||
Dieses Aenderungspaket ist Entwicklungsarbeit, kein ausgefuehrter Anlagenrollout.
|
||||
Die parallel laufenden Batterie-/Neustartarbeiten in Lihrenmoos bleiben unberuehrt.
|
||||
Vor einem spaeteren Rollout gegen den dann aktuellen Batteriestand abgleichen,
|
||||
Quellen und Konfiguration sichern und zuerst passiv pruefen. Ein echter Stelltest
|
||||
braucht eine aktuelle ausdrueckliche Freigabe und eine separate Abnahme von
|
||||
Tracking, Planwechsel, Kommunikationsausfall und sicherem Rueckfall.
|
||||
|
||||
## Pull-Request-Kurztext
|
||||
|
||||
Vereinheitlicht V4-Prognose, Ersteinrichtung und lokale Batteriekorrektur zu einem
|
||||
Zwei-Schalter-Workflow. Erhaelt bestehende Daten und Schutzgrenzen, entfernt den
|
||||
alten Fahrplan aus der aktiven Managerregelung und zeigt im Portal dieselben
|
||||
eingefrorenen Planungsgrundlagen. Keine Aktivierung, Installation oder Erneuerung
|
||||
einer Testfreigabe durch das Aenderungspaket.
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user