4.6 KiB
Batterie: Timer-Lebenszyklus
Korrektur vom 08.10.2026
Alle sechs nativen Batterietimer verwenden den generierten Modulwrapper
ENELIX_BatterieTimerAktion statt eines weiteren IPS_RequestAction-Dispatchs.
Der Wrapper ruft die bestehende Instanzmethode auf und erhaelt Ident, Werttyp,
Intervalle, Sperren und den bestehenden Melde-/Stellpfad. Keine neuen Timer,
Properties, Energiezaehler-Resets oder Aenderungen der EV-/SDL-Aufteilung.
ENELIX_GetV4BatterieRueckmeldungCache ermoeglicht rein passive Diagnose.
Die Methode liest nur den bereits bestaetigten Cache mit den unveraenderten
Frische- und Identitaetspruefungen. Sie startet keine Geraeteabfrage und erneuert
keinen Zeitstempel. Die bisherige Rueckmelde-API bleibt erhalten.
Ursache und Beleggrenzen
Im isolierten Symcon-8.0-Kernel liess sich beim Bibliotheksreload waehrend eines
laufenden IPS_RequestAction-Timers eine alte laufende Timergeneration mit
unstartenden neuen Timern reproduzieren. Das Ende des inneren Callbacks inklusive
finally/Semaphore-Freigabe wurde erreicht, das nachfolgende Ende des aeusseren
Timerskripts nicht. Damit ist der Fehler auf die native Dispatch-/Reload-Grenze
eingegrenzt; eine konkrete C++-Kernelursache ist nicht bewiesen. Status 102 ist
kein Laufnachweis. Das hardwarefreie Gegenbeispiel benoetigt weder Modbus noch
Manager oder Stellbefehle.
Der Modulwrapper bestand zuerst zwei und am 08.10.2026 weitere sechs native Reloads: drei waehrend des Samplers und drei waehrend des Melders. Beide Timer liefen anschliessend automatisch weiter, ohne zusaetzliche Timergenerationen. Die sechs Wiederholungen liefen 04:34:29 bis 04:35:48 UTC. Bestehende Instanzen und Konfigurationshashes blieben unveraendert; die Testbibliothek wurde entfernt. Dies ist ein Entwicklungskerneltest, keine Anlagenabnahme.
Ein separates ApplyChanges waehrend gehaltener Batteriesperre kann weiterhin
mit Timeout abbrechen. Bereits laufende Timer liefen im Test weiter. Erfolgreiche
Initialisierung unter jeder Last oder die Reparatur einer bereits blockierten
Altgeneration sind durch diesen Patch nicht bewiesen.
Regressionen
php tests/BatterieTimer/lifecycle_checks.php: 28 isolierte Vertragspruefungen.composer check: Syntax und regulaere Suite, einschliesslich isolierter PHPUnit-Einbindung dieser 28 Pruefungen.native-fixture/undreload-six-20261008.py: exakt getestete, hardwarefreie native Regression. Nicht Bestandteil des normalen Unit-Testlaufs.
Der native Treiber ist bewusst an den geprueften Entwicklungsserver ubuntu,
Symcon 8.0, lokale RPC-Adresse und Modul-Control 34135 gebunden. Vor erneuter
Ausfuehrung Serverregeln lesen, Testfreigabe einholen und aktuelle Zuordnungen
pruefen. Die Fixture unter /srv/agent/battery-timer-native-20261007/fixture
bereitstellen; der Treiber validiert deren exakte Hashes, verweigert vorhandene
Testreste und laedt ausschliesslich seine eigene Testbibliothek neu.
Nicht auf einer Anlage oder mit veraenderten IDs blind ausfuehren. Die enthaltene
optionale Destroy-Drain-Diagnose ist kein Produktionsloesungsweg.
Installation und Rueckfall
Eine laufende alte IPS_RequestAction-Generation wird nicht durch eine neue
Quelldatei repariert. Ein zufaellig beobachtetes Ruhefenster garantiert keinen
racesicheren Erstwechsel. Vor Anlageninstallation Quellen, aktuelle Instanz-
konfigurationen und Bedieneinstellungen sichern; parallele Aenderungen erhalten.
Fuer den ersten Wechsel ist ein separat freigegebener kontrollierter Stop/Start
mit Installation waehrend des Stillstands der robuste Weg. Keine externen Ticks,
Create-Umgehungen, wiederholten Blind-Reloads oder gelockerten Frischepruefungen.
Danach automatische LastRun-Fortschritte des 5-s-Melders und 1-s-Samplers, Originalzeitstempel frischer bestaetigter Cachewerte und fehlende alte doppelte Timer pruefen. Manager und Ladepunkte mitbeobachten. Keine V4-Aktivierung oder Stellversuche ableiten. Der zuletzt dokumentierte Anlagenreload vom 08.10.2026 04:47 UTC blockierte erneut Batterietimer und liess Easee getrennt; dieser historische Befund muss vor Eingriffen erneut live geprueft werden.
Rueckfall nur auf gesicherte betroffene Quelldateien, nicht pauschal auf alte Konfigurationen oder Energiezustaende. Ein Quellrollback allein beseitigt keinen bereits blockierten Kernelzustand. Veroeffentlichung, Installation und tatsaechlich gemessener Kernelbetrieb sind getrennte Nachweise.
Pull-Request-Kurztext
Timerdispatch fuer Batterie auf den generierten Modulwrapper umgestellt; bestehende Aktionsvertraege und Schutzpruefungen unveraendert. Rein passive Cache-Diagnose hinzugefuegt. Offline-Regressionen und isolierte native Reload-Reproduktion dokumentieren Ursache, Korrektur und Migrationsgrenzen.