# 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/` und `reload-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.