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.