fix(battery): keep native timer callbacks reload-safe

2026-10-08 05:15:27 +00:00
parent 5885681669
commit d42cfb3342
10 changed files with 535 additions and 6 deletions
@@ -0,0 +1,83 @@
+# 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.