Enelix-EMS/docs/NETPLAN_V4_AGENT_HANDOFF.md

# 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`.
Portal-Assets sind auf license.enelix.ch im vorhandenen Prognosebereich aktiv
und ueber HTTPS hashgleich geprueft. Vollstaendige forecastPoints benoetigen noch
das vorbereitete Backend-Image-Update durch einen Administrator. agent hat keine
Docker-Socketrechte; keine Umgehung, kein ausgefuehrtes Backend-Deployment.

Testanlage: Utils und EMS aus gesichertem Kandidat geladen, SDL-Messung und
Anzeigen eingerichtet, individuelle Reihen/Knoten und Historien erhalten.
Alte Diagnoseanzeigen und die zwei V4-Diagnosekategorien verborgen, nichts
geloescht oder deren Beobachter abgeschaltet. Hook 12555 wiederhergestellt.
Nach Reload haengt erneut alter Batterietimer 70; neue Batterie-Meldetimer
laufen nicht. Kontrollierter Symcon-Neustart und Nachkontrolle erforderlich.
Schalter 46716 bleibt false; keine neue Stellprobe, keine Fristverlaengerung.
Unbefristete Steuerung ist ohne unabhaengigen Ausfallschutz nicht freigegeben.
Die automatisierten Softwaretests und responsive Chromium-Pruefung sind gruen;
dies ist ausdruecklich keine erfolgreiche physische Anlagenabnahme.

## Integration 06.10.2026: Freigabe fuer develop und beta, kein Anlagenrollout

Daniel hat nach der Bedienintegration Merge, Commit und Push auf **develop und
beta** ausdruecklich beauftragt. Der getestete Integrationsstand verbindet die
22 lokalen V4-Commits bis ce525a1 mit origin/develop bis 5437f3f und den
zugehoerigen V4-/Formularkorrekturen. Originalarbeitsverzeichnisse bleiben
unangetastet; Integration in /srv/agent/prognose-integration-20261006/repo auf
ubuntu. Keine Feature-Branches, kein Force-Push, main bleibt unveraendert.

Die Bedienung liegt im bisherigen Bereich Prognose / Forecast; der separate
V4-Bereich entfaellt. Einzelheiten und verbleibender Umfang stehen in
docs/prognose-bedienintegration.md. Es bleibt der vorhandene begrenzte Testpfad,
kein regulaerer Dauerbetrieb. Keine Laufzeitordner geloescht, keine Dienste
neu gestartet, keine Module geladen und kein neuer Stellversuch ausgefuehrt.
Die unten dokumentierte Batterietimerblockade bleibt offen. Die ausdrueckliche
Branchfreigabe ersetzt keine physische Anlagenabnahme oder Stellfreigabe.

Isoliert bestanden: 357 PHPUnit-Tests / 1758 Assertions, Syntax aller 150 PHP-
Dateien, 310 Backend-Tests, 16 Portal-Tests und die Bedien-/V4-Einzelchecks.
Kein neuer Symcon-Kernel-/GUI-Test, weil Docker im Agentzugang nicht nutzbar war.
Eine lokale Backend-Aenderung, die ungepruefte Messkonfigurationen automatisch
mit accountingEvidenceId versah, wurde nach fehlgeschlagenem Schutztest nicht
uebernommen; Originalarbeitskopie und laufendes Backend bleiben erhalten.

Commit-Autor ist gemaess bestehender Teamklarstellung dh_Agent <dh@belevo.ch>,
konfiguriertes Gitea-Konto dh. Die Repository-Abfrage bestaetigte Pushrecht;
die Profilabfrage war mangels read:user-Scope nicht verfuegbar. Fuer den
tatsaechlichen Veroeffentlichungsstand die Remote-Refs und den Merge-Commit
pruefen, nicht historische Ahead-/Behind-Angaben weiter unten verwenden.

## Kontext-Sicherung 06.10.2026: Lesereihenfolge und Quellen

Auf Daniels ausdruecklichen Wunsch wird der Arbeitsstand dauerhaft verlinkt.
Fuer den Laufzeitstand ist der unmittelbar folgende Abschnitt **06.10.2026,
12:01 UTC** massgeblich, nicht die aelteren Abschnitte 1, 10, 11 oder 15.
Insbesondere ist der bestaetigte Geraeteabruf bereits implementiert/installiert;
der naechste Schritt ist die dort belegte instanzbezogene Batterietimerblockade.
Der Abschlussnachweis `/srv/agent/v4-recovery-20261006/finished.json` auf
iot-symcon01 wurde erneut gelesen, aber kein neuer Stellversuch ausgefuehrt.

Git-Nachkontrolle in dieser Kontext-Sicherung: nach erfolgreichem Fetch steht
das Server-89-develop **22 Commits vor / 3 hinter origin/develop**; Remote-Stand
bei Fetch `58f91e4`. Kein sicherer Fast-Forward. Bestehende fremde/lokale
Aenderungen bleiben erhalten; kein Merge, Projekt-Commit oder Projekt-Push.
Das ist vom anderen Checkout auf ubuntu und dessen separat dokumentierter
Manager-Leistungsverteilung zu unterscheiden.

Die mitgesendeten Screenshots haben kein bestaetigtes Aufnahmedatum und sind
historische Anschauung, kein neuer Laufzeitnachweis. Der Aktualisierungsdialog
ist keine Freigabe, lokale Modulaenderungen zu verwerfen. Es wurden keine
Module aktualisiert, Dienste neu gestartet oder Anlagenfreigaben veraendert.

## Fortsetzung 06.10.2026, 12:01 UTC: Code installiert, Batterietimer blockieren Live-Abnahme

- Daniel hat nach der ausdruecklichen Rueckfrage den Test ohne zusaetzliches +/-5-kW-Limit bestaetigt. Dynamische Geraetegrenzen (hier bis 39 kW), SOC- und Netzgrenzen bleiben verbindlich. Die urspruengliche Freigabe endet unveraendert am 07.10.2026 um 17:38:07 Europe/Zurich (1791387487). Kein Neustart der 48-h-Frist. Der fehlende unabhaengige Hardware-Watchdog bleibt nur durch die bereits genehmigte Testanlagen-Ausnahme abgedeckt.
- Zusaetzliche allgemeine Arbeitsfreigabe: Routinemaessige Schreibzugriffe auf Lihrenmoos, tunel100 und Server89 benoetigen keine erneute Rueckfrage. Das hebt Sicherheitsgrenzen, technische Berechtigungen, Git-Regeln und konkrete Anlagenfreigaben nicht auf.
- Der vorstehend beschriebene Kandidat wurde inzwischen installiert und getestet. Weitere eng begrenzte Korrekturen dieser Fortsetzung: (1) Batteriebefehl meldet den konkreten Ablehnungsgrund; (2) physische Geraeteabfrage aus dem Batterie-Stellmutex getrennt, eigenstaendiger 1-s-Samplingtimer mit nicht wartender Lesesperre; (3) Stellpfad nutzt nur unveraenderten bestaetigten Cache, maximal 2 s alt nach Wand- und monotoner Zeit, mit Konfigurations-/Quellenbindungspruefung; (4) passendes Server-Pending fuehrt auch vor Aktivstart zu 15-s-Retry statt zum Verpassen des fertigen Plans, HTTP-429 behaelt normalen Backoff. Cache-90-s-Grenze und physische Zeitstempel wurden nicht verlaengert oder erfunden.
- Live-Installationen mit SHA-256-Pruefung und Backups: Fehlerdiagnose 11:31:18 UTC; Sampler 11:38:43 UTC; Empfang um 11:50 UTC. Arbeits- und Sicherungsordner: /srv/agent/v4-recovery-20261006 auf iot-symcon01. Berichte deployed.json, sampler-deployed.json, receiver-deployed.json und test-results.json. Geaenderte Quellen und Tests sind auch im bestehenden develop-Arbeitsverzeichnis auf enelix-services, fremde Aenderungen sind erhalten.
- Letzter Aktivversuch: 11:50:52 UTC, Session 13395dbe-0dbb-42b8-9063-511bd7166f41. Manager meldete danach controller_command_sent (seq 5, 18693 W); Batterie wurde wegen feedback_confirmed_cache_stale_or_invalid gestoppt. Danach Managerabbruch wegen ungueltiger lokaler Betriebsdaten, controllerStopAccepted=true. Kein belastbarer Nachweis von physischem Tracking oder >90-s-Dauerbetrieb. Ein gesendeter Befehl ist ausdruecklich keine Anlagenabnahme.
- KONKRETE OFFENE BLOCKADE: Saemtliche Timer der Batterieinstanz 44234 zeigen LastRun=0. Meldezyklus (5000 ms) und neuer Rueckmeldungstimer (1000 ms) sind lange ueberfaellig, Running=false. Manager- und uebrige Anlagentimer laufen. Instanzstatus 102; Instanz und alle Elternobjekte nicht deaktiviert; keine dauerhaft belegten Skriptthreads nachgewiesen. IPS_ApplyChanges(44234) bei bestaetigtem Null-Stopp um 11:57:31 UTC gab TRUE zurueck, hat die Timer aber nicht repariert. Die Ursache ist NICHT geklaert. Auch der Batterie-Watchdog hat bisher keinen automatischen Lauf nachgewiesen. Deshalb kein weiterer Aktivstart und keine Umgehung durch einen externen Tick-Hook.
- Weitere beobachtete Abbruchbedingung: Durch Reloads/Messluecken fehlte zeitweise laufende Viertelstundenenergie; der Planner verwirft Luecken >120 s weiterhin korrekt. Nach einem Quartalswechsel wurden wieder optimale Plaene empfangen. Zum Schluss meldete der Betriebssender zudem veraltete Verbraucher-Rueckmeldung, passend zum nicht laufenden Batterie-Meldezyklus. Keine Energiestaende, Cursor oder Datenbankwerte wurden in dieser Fortsetzung umgeschrieben.
- Endzustand 12:01:11 UTC: Schalter 46716=false, alter Netzfahrplan=false, Batterie status=stopped, EV-Sollwert 19651=0 W. SDL-Sollwert war 7600 W aus dem unabhaengigen bestehenden Betrieb und wurde nicht auf null gezwungen. Kein physischer V4-Regelungsnachweis. Verbindlicher Abschlussbericht: /srv/agent/v4-recovery-20261006/finished.json.
- Alle temporaeren Start-, Deploy- und Diagnosehooks wurden aus 12555.ips.php entfernt. Original aus /srv/agent/12555.ips.php.v4hook-backup wiederhergestellt, SHA-256 c702a4947ae200b23c3eecccabeb843ad6a55e97509292584ca2de779d5e4940. Nur v4viewsRun des urspruenglichen getrennten Beobachters verbleibt. Inhaltsuche in /var/lib/symcon/scripts fand keine Verweise auf die V4-Recovery-/Continuation-Hooks. Keine unbeobachtete Wiederanlaufautomatik hinterlassen.
- Tests erneut erfolgreich: 96 Regel-/Cache-/Lockpruefungen, 32 Empfangspruefungen, 8 Rueckmeldungs-Empfangspruefungen, 9 Geraeteabrufpruefungen und 1 Test der echten Registermethode mit synthetischen Aktionen, insgesamt 146. Syntaxpruefungen erfolgreich; git diff --check sauber. Das sind automatisierte Tests, kein Hardwareabnahmetest.
- Git bleibt develop, ahead 22 / behind 1 gegen origin/develop, kein sicherer Fast-Forward. Keine Projekt-Commits, Merges oder Pushes. Konto nicht fuer Schreibaktion verifiziert; weder beta noch main geaendert. Die fehlende Live-Abnahme schliesst eine Beta-Freigabe zusaetzlich aus.
- Naechster fachlicher Schritt: Instanzbezogene Symcon-Timerblockade beheben, automatische Sampler-/Melde-/Watchdog-Ausfuehrung belegen und erst dann einen kontrollierten Neustart des V4-Tests versuchen. Ein etwa erforderlicher Symcon-Dienstneustart betrifft weitere Anlagenfunktionen und wurde hier NICHT ausgefuehrt. Danach physisches Tracking, Planwechsel >90 s und bestaetigten Null-Stopp nachweisen. Alte Startmarker oder Installationshooks keinesfalls einfach loeschen/reaktivieren.

## Fortsetzung 06.10.2026: gepruefter Kandidat, Live-Eingriff noch gesperrt

- Daniel hat die Fortsetzung und die Aufhebung der 5-kW-Testgrenze beauftragt. Die bestehende 48-h-Frist, SOC-/Netz-/Geraetegrenzen und der bereits bekannte fehlende unabhaengige Hardware-Watchdog bleiben unveraendert.
- Aktuell auf iot-symcon01 gelesen: Refresh-Deployment 07:43:14 UTC; Full-Power-Deployment 08:46:59 UTC. Diese waren schon vor dieser Fortsetzung installiert. Snapshot 09:30:41 UTC: Schalter AUS, Batterie disabled, Manager stopped_fallback_pending wegen ungueltiger lokaler Betriebsdaten. Keine physische V4-Regelung belegt.
- Neuer Kandidat korrigiert ignorierte FALSE-Rueckgaben von IPS_RequestAction/RequestAction (Start, Command, Stop und Register), den Vor-I/O-Zeitvergleich beim Batterie-Scharfschalten und den blockierenden HTTP-Refresh im Regel-Tick. Separater Empfangstimer: 10 s Prueftakt, aktiver Abruf fruehestens nach 45 s, Fehler-Retry 15 s; Cache-Lebensdauer und Serverzeit bleiben maximal 90 s.
- Kandidat liegt auf develop im Arbeitsverzeichnis und isoliert unter /srv/agent/v4-continuation-20261006 auf Lihrenmoos. 87 Regeltest-, 29 Empfangs-, 8 Rueckmeldungspruefungen plus 1 echter Modulmethoden-Test mit synthetischen Aktionen bestanden; 5 geaenderte Live-PHP-Dateien syntaxgeprueft. Keine Hardwaretests daraus ableiten. Testbericht: test-results.json im Stage.
- Neue Tests decken insbesondere FALSE ohne Exception, Sekundengrenze beim Start, bytegleich behaltenen aktiven Cache, 15-s-Retry, 90-s-Ablauf und zukuenftige Empfangszeit ab. git diff --check erfolgreich.
- Die automatische Sicherheitspruefung hat die Ausfuehrung von /srv/agent/activate_v4_continuation.py abgelehnt, weil diese Live-Installation und Aktivstart koppelt. Der Benutzer wurde um ausdrueckliche Freigabe fuer Installation und Start ohne 5-kW-Limit bis zum bisherigen Ende (07.10.2026 17:38 Europe/Zurich) gebeten. NICHT ueber andere Werkzeuge umgehen. Die Aktivierung wurde nicht ausgefuehrt; 12555.ips.php ist unveraendert.
- Achtung: Der bestehende temporaere v4_direct_battery_command_hook.php sendet alle 30 s den letzten Managerbefehl erneut. Das kann den Replay-Schutz ausloesen. Vor freigegebenem Neustart kontrolliert entfernen. Vorbereitete Aktivierung sichert den alten Timer und ersetzt alte Schreib-/Diagnosehooks durch eine einmalige gesicherte Installation, genau einen Startversuch und reine Beobachtung. Sie ist noch nicht ausgefuehrt. Bei Live-Drift abbrechen.
- Git nach erfolgreichem Fetch: develop ist 22 Commits vor und 1 Commit hinter origin/develop (fremder Commit 37addf4). Fremde Lade-/GUI-Aenderungen sind erhalten. Kein Fast-Forward moeglich; kein Commit, Merge oder Push in dieser Fortsetzung. Kandidatenpatch: /srv/agent/v4-continuation-20261006.patch auf enelix-services.
- Naechster Schritt erst nach Freigabe: Stage/Live-Hashes und Zustand erneut pruefen, Kandidat installieren, genau einen Startversuch beobachten und dessen echte Batterie-Antwort pruefen. Danach >90 s mit Planwechsel, reale Leistungs-/Netzreaktion und sicheren Nullstell-Stopp nachweisen. Erst anschliessend regulaeren Testlauf belassen und temporaere Hooks entfernen. Kein stabiler Aktivbetrieb zugesichert.

Übergabe erstellt am 04.10.2026 auf ausdrücklichen Wunsch von Daniel Häfliger (BELEVO AG). Sie fasst die Anforderungen, Entscheidungen, Fehlerbehebungen und den zuletzt belegten Stand dieses Gesprächs zusammen. Sie ist **kein wörtliches Chatarchiv, keine neue Stellfreigabe und kein Nachweis der Produktionsreife**.

**Zeitbezug:** Die letzten hier belegten Betriebsberichte stammen vom **03.10.2026, ca. 14:02 Uhr Europe/Zurich**. Am 04.10. wurden für diese Übergabe die genannten Berichte und der Git-Stand erneut gelesen, aber keine neue Anlagenabnahme durchgeführt. Alte Messzahlen deshalb niemals als heutige Live-Werte ausgeben.

**Fortsetzung Prognose am 04.10.2026:** Der aktuelle Runtime-Stand wurde gelesen, ohne die alten Diagnose- oder Installationsschritte zu wiederholen. Der abgeleitete Datensatz `lihrenmoos-physical-published-v2` ist `model_ready` und erfüllt mit mehr als 24 nutzbaren äquivalenten Stunden die Trainingsschwelle. Die V4-Einstellungen stehen seit Revision 2 in `shadow` auf `forecastSource=corrected_profile` und `measurementDataset=lihrenmoos-physical-published-v2`; `liveEnabled` und Stellfreigabe bleiben aus. Der erste echte Lauf zeigte einen kompatibilitätsbedingten Stopp bei mikrosekundengenauen `observedAt`-Zeitstempeln. Die Korrektur rundet ausschliesslich die kausale Verfügbarkeit von Prognoseereignissen auf die nächste volle Sekunde auf; Rohmessungen bleiben streng ganzsekündlich. 310 Python- und 16 Portal-Tests sind erfolgreich. Repository und Runtime-Build-Kontext enthalten bytegleich den geprüften Fix; der laufende Container enthält ihn noch nicht, weil beide Agentzugänge weder Docker-Socket noch `sudo` erhalten. Der vorbereitete, syntaktisch geprüfte Root-Rollout liegt unter `/home/agent/services/netplan-v4-shadow/commissioning/finish_corrected_forecast_rollout.sh` und baut/testet vor dem Austausch, hält das vorige Image als Rollback fest und ändert keine Stellfreigabe. Daniel hat danach einen Aktivbetrieb angefragt; der aktuelle V4-Kern ist jedoch technisch `shadow-only`, und die weiterhin unbelegte Rückmeldung (`feedback_source_skew`, `usableForTrial=false`, `canDispatch=false`) verbietet ein blosses Umstellen. Keine Live-Freigabe wurde erteilt oder eingebaut. Git-Klarstellung durch Daniel: Commit-Autor `dh_Agent <dh@belevo.ch>`, Gitea-Konto `dh`; Commit/Push auf `develop` und `beta` am 04.10.2026 ausdrücklich freigegeben. Der Agentzugang besitzt derzeit keine HTTPS-Schreibanmeldung für `dh`.

**Fortsetzung bestätigte Rückmeldung am 04.10.2026:** Daniels Freigabe des modellierten `virtual_split` gilt für den ausdrücklich begrenzten Feldtest. Die physische Rückmeldung wurde um synchrone, durch den Gerätetreiber bestätigte Lesevorgänge erweitert: M-Bus verwendet `MBUS_UpdateValues`, ModBus Device und ModBus Address verwenden `ModBus_RequestRead`. Nur ein erfolgreicher Geräteaufruf erzeugt `confirmedAt`; `VariableUpdated` bleibt getrennte Herkunftsinformation. Die Regeltest-Gates verlangen `deviceReadConfirmed=true`. Das reproduzierbare inkrementelle Paket liegt auf der Testanlage unter `/srv/agent/netplan-v4-confirmed-feedback-20261004`; 18 Paketprüfsummen, 37 Rückmeldetests, 7 Geräteabruf-Tests und 71 Regeltest-Prüfungen sind erfolgreich. Es ist noch **nicht im IP-Symcon-Kernel installiert**, weil der lokale JSON-RPC-Zugang ohne Anmeldung mit HTTP 401 antwortet. Die Installation selbst lässt alten Netzfahrplan und beide Regeltestfreigaben aus. Ein realer Stellversuch bleibt zusätzlich durch den nicht belegten unabhängigen Geräte-Watchdog und die fehlende Serverfreigabe blockiert; der vorhandene Symcon-`VorgabeTimeout` ist kein unabhängiger Hardware-Nachweis. Auf `enelix-services` und der Testanlage ist kein nutzbarer Git-HTTPS-Credential-Helper hinterlegt; die Prüfung des Tunnel-Servers lief zweimal in eine externe Connector-Freigabezeitüberschreitung. Tokeninhalt wurde weder gelesen noch ausgegeben. Der Commit des Folgepakets ist lokal mit der vereinbarten Identitaet `dh_Agent <dh@belevo.ch>` erstellt. Der atomare Push auf `develop` und `beta` scheiterte ohne Teilaktualisierung, weil fuer `https://dh@git.belevo.ch` kein Passwort/Token bereitstand.

**Fortsetzung Aktivbereitschaft am 04.10.2026:** Die reale Stellkette wurde in den gespeicherten Testanlagen-Settings bis zu den Aktionszielen geprüft. Die ENELIX-Batterieinstanz 44234 schreibt über das Aktionsskript 31800 auf den EV-Sollwerteingang 19651 des Gateways 58448. Dieses Gateway verteilt im Zwei-Sekunden-Takt auf zwei GoodWe-Pfade über reine SetValue-Aktionsskripte und auf drei SolarEdge-Modbus-Adressen. Der ENELIX-`VorgabeTimeout` setzt bei laufendem Symcon nach 30 Sekunden auf 0 W zurück. Weder im Gateway noch in den drei GoodWe-Aktionsskripten wurde jedoch ein vom Symcon-Kernel unabhängiger Geräte-Watchdog gefunden; auch die SolarEdge-Modbus-Konfiguration weist nur Poll-/Write-Parameter, keinen Geräte-Timeout aus. Ein unbeaufsichtigter 1-2-Tage-Stellbetrieb bleibt deshalb gesperrt. Beide lokalen Regeltestfreigaben sind weiterhin aus, es wurde kein Stellbefehl ausgelöst. Der bestätigte Rückmeldeinstaller ist für einen gestoppten Kernel vorbereitet und geprüft, konnte mangels privilegierter `systemctl`-Berechtigung des Connector-Benutzers aber noch nicht ausgeführt werden. Auf `tunel100` ist ein Credential-Helper für das Konto `dh` vorhanden und ein `develop`-Dry-Run war erfolgreich; die danach nötige Connector-Freigabe lief erneut ab, bevor der lokale 19-Commit-Stand übertragen und veröffentlicht werden konnte.

## 1. Zuerst lesen: Wo wir tatsächlich stehen

- Daniel möchte die **fertige, produktionsgeeignete Anwendung**, nicht weitere isolierte Sammler, Diagnosekategorien oder wiederholte Bestätigungsrunden. Er hat die fortlaufende Umsetzung mehrfach beauftragt. Probleme im Code selbst beheben, Tests und Auslieferung bündeln; ihn nur für wirklich notwendige Root-/Symcon-Ausführung oder echte Anlagenfreigaben einbeziehen.
- Datenaufnahme, bestätigter Versand, historische Aufbereitung, Modellaufbau, V4-Optimierer, Planempfang und ein ausdrücklich begrenzter Regeltest sind implementiert. Der zuletzt installierte Teil verbindet korrigierte physische Rückmeldung mit Vorschau und dem **begrenzten** Test-Stellpfad.
- Der Versandblocker durch `100.0`/`100` ist **behoben und der Nachversand hat aufgeholt**. Nicht erneut beim Cursor oder der alten Kennungsdiagnose anfangen.
- Die letzte Feedback-Installation ist **erfolgreich abgeschlossen**, nicht mehr `waiting_for_registration`. Bericht: `corrected_feedback_installed_trial_disabled`, Rückmeldung `unavailable`, Grund **`feedback_source_skew`**.
- **Nächster konkreter Entwicklungsauftrag:** bestätigte, zum tatsächlich gelesenen Wert passende Geräte-Lesezeitpunkte an den lokalen Rückmeldepfad anschliessen. Bisher wird `VariableUpdated` als Live-Zeitbasis verwendet; unveränderte Modbus-Werte werden aber nicht zwingend bei jedem erfolgreichen Abruf erneut publiziert. Geräteabruf, Variablenpublikation und aktueller Lesezugriff müssen auseinandergehalten werden.
- Keine künstliche Zeitstempelverjüngung, pauschale Toleranzerhöhung, Nullersetzung, historische Interpolation als Live-Messung oder Rückkehr zum festgehaltenen virtuellen EV-Wert.
- **Weiterhin keine produktive V4-Batterieausführung:** alter intelligenter Netzfahrplan AUS; beide lokalen Regeltestfreigaben AUS; kein gestarteter Stellversuch. Bestehende lokale Regelung und SDL laufen unabhängig weiter.
- Ein uneingeschränkter Produktions-Dauerregler ist **noch offene Umsetzung**, nicht nur ein fehlender Haken. Automatik, reale Modellqualität, Geräteausfallverhalten und Mehranlagenfreigabe haben ebenfalls verbleibende Grenzen.
- Letzter fachlicher EMS-Commit: **`9878197`**, `develop`, bei Übergabeprüfung sauber und **15 Commits vor lokalem `origin/develop`**. Kein Remote-Fetch in dieser Prüfung. Vorherige Pushversuche scheiterten an Authentifizierung. Dokumentations-Commits dieser Übergabe können danach folgen.

## 2. Arbeitsweise und Freigaben

Daniel ist technisch versiert, will aber keine unnötige manuelle Kleinarbeit. Deutsch, Schweizer Schreibweise, konkrete nutzbare Befehle. Ein abgeschlossener Test ist nicht automatisch Installation, Installation nicht Stellfreigabe, `optimal` nicht reale Einsparung. Immer getrennt berichten: implementiert / isoliert getestet / Zielcontainer getestet / installiert / im Kernel geprüft / am Gerät erprobt / veröffentlicht.

**Nicht wieder in die alte Schleife zurückfallen:**

1. Keine neuen Diagnosekategorien als Ersatz für die eigentliche Integration.
2. Keine erneuten Fragen nach bereits bestätigten EV-Kapazitäten oder pauschal immer wieder nach Wechselrichtertypen. Bestehende Quellen nutzen. Eine tatsächlich fehlende sicherheitsrelevante Eigenschaft darf trotzdem nicht erfunden werden.
3. Nicht einfach „24 Stunden warten“, solange ein Software- oder Übertragungsfehler das Training verhindert.
4. Keine alten Einzelinstaller erneut ausführen; neueren Quellstand und parallele GUI-Arbeit nicht überschreiben.
5. Nicht behaupten, im Hintergrund weiterzuarbeiten. Nur tatsächlich ausgeführte Arbeit und belegte Ergebnisse berichten.
6. Die Regel „ein einziger konkreter Punkt“ betraf Einträge in **Offene Punkte**, nicht Entwicklungsaufträge. Implementierungsaufträge dürfen zusammenhängende Anforderungen bündeln.

**Git:** Keine Feature-Branches. Entwicklung auf `develop`; nach Tests `beta`; nach Feldtest `main`. Daniel hat im Gespräch Commit/Push für `develop` und damals auch `beta` ausdrücklich freigegeben. Diese Freigabe nicht als Auftrag interpretieren, einen aktuell ungetesteten Kandidaten blind auf `beta`/`main` zu schieben. `develop`-Push ohne erneute Nachfrage im bestehenden Rahmen erlaubt. Nicht force-pushen, nicht unzusammenhängende Änderungen übernehmen, keine Zugangsdaten verlangen/ausgeben. Historische Agenten-Commitidentität war `ENELIX Agent <agent@enelix.invalid>`; keine globale Git-Konfiguration ungeprüft ändern.

Die aktuelle Nachricht beauftragt **Kontextübergabe**. Sie erteilt keine zusätzliche Anlagen-, Runtime- oder Stellfreigabe. Bei späterer Fortsetzung greifen die bestehenden Sicherheits- und Branchregeln weiter.

## 3. Ursprüngliches fachliches Ziel

### 3.1 Prognosefamilien und Erweiterbarkeit

Im GUI manuell eine Familie wählen oder `auto`:

| Familienschlüssel / Fahrplan | PV | Last | Fahrplanvariable |
|---|---|---|---|
| `3` | `prog_var_1` | `prog_var_2` | `prog_var_3` |
| `13` | `prog_var_10` | `prog_var_11` | `prog_var_13` |
| `23` | `prog_var_21` | `prog_var_22` | `prog_var_23` |

Die neun Zahlen sind nicht neun unabhängige Fahrplanmodelle. Daniel akzeptierte die Auswahl der vollständigen Modellfamilie. Registry und Datenadapter so gestalten, dass weitere Familien und später weitere flexible Anlagen ergänzt werden können. Nicht behaupten, drei bereits vorhandene Lastmethoden seien identisch mit den neu aufgebauten physischen Profilen; Datenquelle und Modellversion müssen sichtbar sein.

`auto` soll jene Familie wählen, die in der jüngeren Vergangenheit **wirtschaftlich am besten abgeschnitten hätte**, mit gleichen Anfangsbedingungen, Tarifen, SOC-/Restenergiebewertung und Randbedingungen. Keine Auswahl allein nach R², keine Zukunftsinformation im historischen Replay. Mindestabdeckung, Mindestdauer, Rückblick und Wechselmarge verhindern häufige/schlecht belegte Wechsel.

### 3.2 Netzfahrplan / Optimierung

- Bis zu **48 Stunden**, grundsätzlich **5-Minuten-Schritte** (höchstens 576), rollende Neuberechnung.
- Ausgangsverlauf: korrekt abgegrenzte Verbraucherlast minus PV plus separat berücksichtigte externe Flüsse. Darauf flexible Verbraucher optimieren; aktuell EV-Batterie, später Ladestationen, Boiler usw.
- Batterie: aktueller virtueller EV-SOC, dessen zugehörige EV-Gesamtkapazität, aktuelle maximale Lade-/Entladeleistung, Min-/Max-SOC, Reserve, Hysterese, Verfügbarkeit und lokale Einschränkungen. Keine zukünftige Energie vor dem Laden nutzen.
- **90 % Roundtrip-Wirkungsgrad**, nicht zweimal 90 %. Implementierung verteilt Verluste mit `sqrt(0.9)` auf Laden/Entladen.
- Netzladen ist ausdrücklich erlaubt/gewünscht, wenn freigegeben und wirtschaftlich sinnvoll. Nicht generell Nachtbezug verbieten oder tagsüber Entladung verbieten.
- Kosten pro Intervall: Bezugsenergie mal Bezugspreis minus Einspeiseenergie mal Einspeisepreis. Leistungswerte in W/kW korrekt über Zeit in kWh umrechnen. Gesamtkosten minimieren, nicht mathematisch auf exakt null zwingen; negative Kosten sind möglich, nicht garantiert.
- Statische oder dynamische, in der Anlage konfigurierte Bezugspreise und Einspeisevergütungen verwenden. GUI-Preisänderungen speichern und Neuberechnung anfordern. PV-Vergütung, Netzladekosten, Verluste und Peakpreis gehören in dieselbe Wirtschaftlichkeitsbetrachtung.
- Wenn dynamische Preise noch nicht veröffentlicht sind, den **ausführbaren wirtschaftlichen Horizont auf den bekannten Preisbereich begrenzen** (`published_only`); kein frei erfundener Preis für den Rest der 48 h. Volle Prognose und ausführbaren Preishorizont unterscheiden; Ende passend zur vollständigen Abrechnungsviertelstunde.
- Restenergie am Horizont fair bewerten/absichern, damit die Batterie nicht am Planende oder zu fast wertlosen Mittagstarifen grundlos leerverkauft wird.
- Bezug/Einspeisung sowie Laden/Entladen nicht als unphysikalische gleichzeitige Arbitrage zulassen.
- Einspeisebegrenzung, zulässige Abregelung/entgangene Vergütung und lokale harte Netzgrenzen berücksichtigen. Einen unerreichbaren Plan nicht als eingehalten darstellen.

### 3.3 Monatspeak

- Leistungstarif auf den relevanten **15-Minuten-Netzbezug**; persistenter Monatsmaximalwert, nicht momentane Spitzenleistung. Für den laufenden Monat zusätzliche Kosten nur für Erhöhung über den bereits erreichten Peak; Monatswechsel korrekt behandeln.
- Bereits verstrichene Energie der aktuellen Viertelstunde mitnehmen. Fehlende Messbasis nicht durch eine konfigurierte Grenze ersetzen.
- Am Monatsanfang nicht künstlich jede Aktivität verhindern: Restmonatsbewertung/empirische Aussicht ist vorgesehen, mit ausgewiesener Unsicherheit. Ein erwarteter künftiger Peak ist **keine bereits bezahlte kostenlose Freigabe**.
- Anlagen können **keine feste Bezugsgrenze** haben. Falls im Manager statische oder monatliche Peakgrenzen konfiguriert sind, diese zusätzlich respektieren.
- Tarifeinheiten und tatsächliche Abrechnungsdefinition prüfen; gemessene, geschätzte und nur konfigurierte Peakwerte getrennt kennzeichnen.

### 3.4 Training, Reaktion und Validierung

Tägliches oder wöchentliches Nachtraining nach GUI-Einstellung; Parameter-/Preisänderungen sollen Neuberechnung auslösen. Getrennte versionierte Historien und Modelle, keine alten belasteten Daten als bereinigt umbenennen. Ein Cold-Start-Modell nach Mindestdatenbasis ist noch keine validierte Feldprognose. Vergleich gegen die bisherige Batterie-Betriebsweise, nicht nur gegen „Anlage ohne Batterie“.

## 4. Lihrenmoos: bestätigte Anlage und massgebliche Korrekturen

- Installation: **`e3a08f9e-af12-4695-99bd-8b51c0520021`**.
- Symcon Manager **`17004`**, ENELIX-Batterieinstanz **`44234`**, virtuelles Asset **`anlage01-virtual-ev`**, bestehendes EV-/SDL-Gateway **`58448`**.
- **Massgeblich bestätigt: EV-Kapazität `161.44 kWh`, EV-Leistung `39 kW`.** Die vorher genannten `160 kWh`, `30 kW` und „je 10 kW pro WR“ hat Daniel ausdrücklich als Erinnerungskorrektur zurückgenommen. Daraus keine neue Verteilung auf Einzelgeräte ableiten.
- Virtueller EV-SOC und die EV-Kapazität bilden ein gemeinsames Energiekonto. Keine SOC-/Energie-Resets oder Umrechnung auf 322 kWh. **SDL-Reserve ist bereits ausgegliedert** und darf nicht nochmals von EV abgezogen werden.
- Vom Nutzer genannte physische Ausstattung: zwei GoodWe à **50 kW AC**, je **156 kWh** Batterie; SolarEdge **10 kW AC / 10 kWh** Batterie. Summe physische Kapazitäten rechnerisch 322 kWh, nicht die EV-Kapazität. AC-Nennleistung ist kein unabhängiger Nachweis jeder aktuell zulässigen Batterie-Ladeleistung.
- Dach-PV ungefähr **20 kWp Ost + 20 kWp West**.
- Exakte Gerätetypen/Firmware, jede AC-/DC-Messgrenze und autonomes Verhalten beim Befehlsausfall sind durch diese Nennwerte nicht automatisch bestätigt. Vorhandene Dokumente/Quellen verwenden, statt Angaben zu erfinden oder Daniel wiederholt pauschal zu befragen.
- Historischer Tarif-Snapshot: Bezug `CKW Dynamisch Home`, statischer Fallbackwert 0.246 CHF/kWh, Einspeisung „Preis selber eingeben“ 0.10 CHF/kWh, Peakparameter 5.0. **Nicht als aktuelle Tarifvorgabe neu setzen**, vor Verwendung aktuelle Konfiguration lesen.

## 5. Bilanzierung und SDL: nicht wieder die alte Fehlerquelle einbauen

Der alte Prognosesender verwendete sinngemäss `PV + Netz − virtuelle EV-Batterieleistung`. Weil nur die virtuelle EV-Batterie in der Topologie stand, konnte **SDL als Hausverbrauch gelernt** werden. Zusätzlich hält das bestehende Gateway unter bestimmten Bedingungen gefilterte virtuelle EV-/SDL-Istleistungen fest und schreibt sie erneut. Neuer Variablenzeitstempel allein machte diese Werte nicht zur frischen physikalischen Messung.

**Neue Grundidee, bei passender elektrischer Messgrenze:**

`Verbraucherlast = Netzbezug + PV-Erzeugung − gesamte physische Batterieladung`

`Grundlast = Verbraucherlast − separat geplante flexible Verbraucher`

Grundlast bedeutet hier zeitabhängiger nicht separat geplanter Verbrauch, **keine Konstante**. Nicht separat geplante Boiler/Wallboxen bleiben vorerst darin. Später beim Übergang zu eigenständiger Planung genau einmal herausrechnen.

**SolarEdge-Sonderfall:** PV-Variable 20335 war bereits aus skaliertem AC-Ausgang plus Batterieleistung berechnet und auf null begrenzt. Neuer Lastadapter `solar_terminal_v1` verwendet den AC-Ausgang aus 37975/41853 direkt und zieht den SolarEdge-Batteriesaldo nicht nochmals ab. Herkunft, Vorzeichen, AC/DC und Null-Clipping beachten. Algebraischer Bilanzschluss allein ist kein unabhängiger Zählernachweis.

SDL wird **nicht vom V4-Flexibilitätsoptimierer gesteuert**. Bekannten externen Fahrplan berücksichtigen; bei unbekanntem Verlauf nicht still null einsetzen. Die vorhandene Schattenplanung kann den aktuellen SDL-Auftrag als ausdrücklich gekennzeichnete Fortschreibung verwenden. Das ist kein veröffentlichter Zukunftsfahrplan. Für Dauerproduktion sind belastbare externe Grenzen/Reservebehandlung und Konfliktauflösung noch zu prüfen. Ein aktueller SDL-Wert null garantiert keine SDL-freie kommende halbe Stunde.

Bestehendes Gateway: `/var/lib/symcon/modules/Symcon_Belevo_Energiemanagement_testing/Bat_EV_SDL_V4/module.php`. Aktionsbrücke historisch `scripts/31800.ips.php`. `State=false` war dort **kein nachgewiesener Nullstell-/Notstopp**. EV-Stopp darf nicht pauschal unabhängige SDL-Aufträge löschen. Virtuelle Energiekonten/Filter nicht ungeprüft umstellen.

## 6. Quellzuordnung für die nächste Arbeit

Werte/Identitäten mit aktueller Quellenkonfiguration abgleichen; Tabelle ist zuletzt geprüfte Zuordnung, keine Erlaubnis, Register umzulegen.

| Grösse | Variable | Ursprung/Umrechnung |
|---|---:|---|
| Original-Netzleistung | 40348 | Parent 11490, `Power_8`, kW ×1000 → W, Bezug positiv |
| Netz-Anzeige | 49301 | Abgeleitet; nicht mit Originalquelle verwechseln |
| GoodWe 1 PV | 48459 | Parent 19742, `A_3_3_35301`, W |
| GoodWe 2 PV | 53802 | Parent 57658, `A_3_3_35301`, W |
| GoodWe 1 Batterie physisch | 47725 | Parent 19742, `A_6_3_35182`, Faktor −1 → Laden positiv |
| GoodWe 2 Batterie physisch | 35724 | Parent 57658, `A_6_3_35182`, Faktor −1 |
| SolarEdge Batterie physisch | 21447 | Parent 30789, `Value`, Faktor +1 |
| SolarEdge abgeleitete PV | 20335 | Parent 36915; nicht unabhängige PV-Messung |
| SolarEdge AC-Rohwert | 37975 | Parent 35514, `Value`, ReadAddress 40083 |
| SolarEdge AC-Skalierung | 41853 | Parent 48996, `Value`, ReadAddress 40084 |
| Virtuelle EV-Istleistung | 52020 | Parent 58448, `Aktuelle_Leistung_EV`; Filterhaltewert möglich |
| Virtuelle SDL-Istleistung | 25085 | Parent 58448, `Aktuelle_Leistung_SDL` |
| EV-Auftrag | 19651 | Parent 58448, `Nennleistung_Soll_EV` |
| SDL-Auftrag | 38943 | Parent 58448, `Nennleistung_Soll_SDL` |
| Gateway aktiv | 23483 | Parent 58448, `State`; kein Gerätewatchdog-Nachweis |
| EV-SOC | 32871 | Parent 58448, `SoC_EV` |
| SDL-SOC | 23879 | Parent 58448, `SDL_Pos` |
| EV verfügbare Ladeleistung | 50230 | Parent 58448, `P_EV_laden` |
| EV verfügbare Entladeleistung | 43899 | Parent 58448, `P_EV_entladen` |
| GoodWe 1 / 2 / SolarEdge SOC | 27361 / 23109 / 51938 | Originalzuordnung siehe Capture-Konfiguration |
| Wirkenergie Bezug T1 | 59607 | Parent 11490, `Energy_0`, kWh |
| Wirkenergie Bezug T2 | 26620 | Parent 11490, `Energy_1`; Zählerarchivierung aktiviert |

**Nicht wieder 53476 als nachgewiesenen Bezugszähler verwenden:** Im Gespräch zeigte 53476 / Quelle 32797 (`Energy_6`) einen unplausibel anderen Verlauf gegenüber Netzleistung und T1. Alte Historie 53476 wurde bewusst nicht überschrieben. Archivinstanz 16207. Neuzeitlicher Peak muss aus geeigneter T1/T2-Summe bzw. ausdrücklich zugelassener vollständiger Viertelstundenschätzung stammen.

Poller laut zuletzt gelesenem Snapshot: GoodWe 1 Parent 19742 `60000 ms`, GoodWe 2 Parent 57658 `5000 ms`; SolarEdge Batterie Parent 30789 `2000 ms`, AC Parent 35514 `1000 ms`, Skalierung Parent 48996 `20000 ms`. M-Bus Parent 11490 hatte `Interval=0`, trotzdem laufend frische Originalwerte. Nicht daraus schliessen, die Erfassung sei aus; zusätzliche bestehende Aufrufwege prüfen. Poller nie allein als erfolgreichen Geräteabruf interpretieren.

## 7. Hosts, Code, Dienste und Berechtigungen

### enelix-services / Connector Server_89

- Host `enelix-services`, IPv4 `87.106.60.89`, Agentbenutzer `agent`. Erlaubte Wurzeln `/home/agent/services`, `/srv/agent`.
- Entwicklung: **`/srv/agent/repos/Enelix-EMS`**, Gitea `ENELIX/Enelix-EMS` auf `git.belevo.ch`. Weiteres Projekt `ENELIX/Enelix-Utils`; historische Referenz `dh/Symcon_Belevo_Energiemanagement_testing`. Andere Hosts/Klone nicht ohne Nachweis gleichsetzen.
- Versionierter neuer Servercode: **`services/netplan-v4/`** im EMS-Repo.
- Runtime/Build-Staging: **`/home/agent/services/netplan-v4-shadow`**, SQLite `data/netplan-v4.sqlite`, Compose `compose.yaml`, interner V4-Port 9100.
- Bisheriger Forecast/API-Dienst: `/home/agent/services/prognosis-manager-enelix2`; Forecast Engine interner Port 9000. Nicht durch neue V4-Arbeit unbemerkt ersetzen.
- Portal: `/home/agent/services/license`, `server.mjs`, `public/`, `compose.yaml`. Parallele GUI-Arbeit möglich. Unified-RC1 aktualisierte nur V4 und zugehöriges Planner-JS, nicht pauschal alle Portalprozesse.
- Vor Veränderungen `/srv/agent/AGENT_CONTEXT.md` lesen. Agent hatte zuletzt keinen Docker-Socket-/Root-Zugriff; den Nutzer Root-Ausführung nur für tatsächlich benötigte Deployment-Schritte erledigen lassen. Keine Berechtigungen auf Docker-Socket ausweiten.

### iot-symcon01 / Connector Testanlage_Lihrenmoos

- IP-Symcon 8.0, Dienst `symcon.service`, Kerneldateien `/var/lib/symcon`, Logs `/var/log/symcon`, Programme `/usr/share/symcon`.
- Installiertes EMS-Repo: `/var/lib/symcon/modules/Enelix-EMS`. Das ist produktionsnah laufender Code, nicht der Entwicklungscheckout auf Server_89.
- Staging, Tests, Diagnose: `/srv/agent/netplan-v4-...`.
- Hostregeln `/srv/agent/AGENT_CONTEXT.md` lesen. Keine allgemeinen Settings-/Credential-Exports. Für gezielte schreibgeschützte Zustandsprüfung nur erlaubte Felder extrahieren, niemals ganze secret-bearing Konfiguration ausgeben.
- **PHP mit IPS-Funktionen gehört in Symcon**, nicht in die Linux-Bash und nicht in gewöhnliches CLI-PHP. Isolierte CLI-Tests mit simulierten IPS-Funktionen umgekehrt niemals im echten Kernel ausführen.
- `MC_ReloadModule`/`IPS_ApplyChanges` können bestehende Initialisierungen und deren Nebenwirkungen ausführen. Nicht pauschal als ohne Auswirkungen versprechen. Code- und Settings-Sicherung, Hash-/Driftprüfung, Rücksetzweg nötig.
- Bei verzögerter Modulregistrierung wurde ein Wiederholen angefordert. Die letzte Installation ist inzwischen fertig: **jetzt nicht wiederholen**.

## 8. Installierter Daten-/Prognosepfad

1. Manager erfasst 23 numerische Quellen alle 30 s, mit originalen Zeitstempeln und Qualitätsmerkmalen. Keine zusätzlichen Modbus-Abfragen durch den bisherigen Sammler.
2. Lokale append-only Tagesdateien/Outbox. Versand regulär höchstens einmal/min, bis 120 Aufnahmen pro Batch; geordneter, bestätigter Cursor. Backoff bei Fehlern; Originale bleiben erhalten. `scheduled` kann reguläre Sendepause oder Backoff bedeuten; getrennte letzte erfolgreiche Bestätigung beachten.
3. Server-Datensatz **`lihrenmoos-physical-v1`** speichert Originalaufnahmen. Abgeleiteter Datensatz **`lihrenmoos-physical-published-v2`** referenziert dieselben Daten für die verbesserte historische Zeitbehandlung.
4. `equal_endpoint_v1`: begrenzte rückblickende Schätzung bei gleichen Werten an getrennten Originalzeitpunkten. Verfügbarkeit der späteren Bestätigung wird mitgeführt; keine Leckage in damalige Entscheidungen. Unterschiedliche Werte, lange Ausfälle, widersprüchliche Quellen oder Sammellücken nicht unbemerkt überbrücken. Live-Grenzen unverändert.
5. Worker verarbeitet im 5-Minuten-Takt. Mindestbasis 24 **verwertbare äquivalente Stunden**, nicht bloss seit Start verstrichene Zeit. Neue Tagesprofile, versionierte Modelle, konfigurierbare tägliche/wöchentliche Neubildung. Kaltstart/Validierung sind getrennt.
6. Neue Datenquelle muss als `corrected_profile` mit passendem `measurementDataset` gewählt werden, sobald verwendbar; zuletzt blieb **`forecastSource=legacy`, `family=3`**. Nicht bei Installation automatisch umgeschaltet. `optimal` auf der Legacy-Quelle ist kein Nachweis der neuen Prognosequalität.
7. Wirtschaftlicher Vergleich Unified-RC1 ist angeschlossen, aber v1 ist **eingefrorener Tagesplan + simulierte lokale Netzzielnachführung**, nicht vollständiges rollendes MPC-Replay. Eine netzladefähige Batterie; gleiche Anfangsbedingungen, Restenergie, Verluste und einmalige Monatspeakabrechnung. Historischer SDL-Auftrag als gekennzeichnete Schätzung. Vollständige Modellautomatik/Produktversprechen nicht über diesen Scope hinaus behaupten.
8. Archivierung ist implementiert, **AUS als Standard** (native `NetzfahrplanV4ArchivAktiv`, serverseitig `NETPLAN_V4_ARCHIVE_ENABLED`). Verifizierte komprimierte Archive ersetzen kein externes Backup und lösen keine unendliche Speicherkapazität. Keine unbestätigten Outbox-Daten löschen.

## 9. Behobene Fehler – nicht erneut aufrollen

- Früherer numpy-Fehler `assignment destination is read-only`, falscher Import `battery_optimizer_new`, Dateirechte im unprivilegierten Container: damalige Deployment-/Codefehler, nicht aktuelle Blocker.
- Direkt nach Start `Connection refused`, danach HTTP 409 „bereits ein Lauf aktiv“: Start-/Parallelitätszustand, nicht durch wiederholte Neustarts lösen.
- Native Betriebsdaten fehlten; anschließend Sender installiert. Tarifimporter und Portal-Rate-Limit wurden repariert. Alte 429-Meldungen nicht ohne neue Evidenz zur heutigen Ursache erklären.
- Klasse `NetzfahrplanV4Messaufnahme` doppelt aus Staging und Modulpfad geladen: Installer auf eindeutige installierte Bibliothek umgestellt. `require_once` verhindert nicht verschiedene Dateien mit derselben Klasse.
- Gemischter 120er-Block: 45 importierte/75 native Aufnahmen, keine doppelten/rückwärtslaufenden Zeiten, aber andere Kennung allein durch `splitToleranceW:100.0` vs `100`. Normalisierung korrigiert; beide vollständigen Konfigurationen exakt geprüft. Kompatibilität nur für diese anlagen- und datensatzgebundene Gleichwertigkeit registriert; Ursprungskennung/Evidence gespeichert. Keine Hashs in Originaljournalen ersetzt, kein Cursor-Sprung.
- **Nachweis der Reparatur:** am 03.10. 12:58 Schweizer Zeit 1'782 statt 1'320 Aufnahmen, jüngste Aufnahme 12:58:09, 25 s alt, vollständiger ehemals blockierter Batch vorhanden, Manager `acknowledged`/Fehlerzahl 0. Quelle `[F]` unten. Keine Garantie über den danach liegenden Zeitraum ableiten.
- Historische Datenqualität verbesserte sich von 0 brauchbaren Fenstern auf 104/8.66 h, nach Nachversand 130/10.82 h; zuletzt Worker 140/11.65 h. Prozentangaben zur zeitlichen Abdeckung sind **keine Messgenauigkeit und keine Prognosegüte**.

## 10. Installierter Rückmelde- und begrenzter Stellpfad

Gemeinsamer Code: `NetzfahrplanV4Rueckmeldung.php`, `BatterieNetzfahrplanV4RueckmeldungTrait.php`, `ManagerNetzfahrplanV4EmpfangTrait.php`, `ManagerNetzfahrplanV4TestTrait.php`, `BatterieNetzfahrplanV4TestTrait.php`, `NetzfahrplanV4Regeltest.php`, Manager-/Batterie-Module.

- Zweifaches Lesen mit Identitäts- und Originalzeitprüfung; momentan Live-Alter maximal 60 s, Quellenversatz maximal 30 s.
- Modus in Lihrenmoos **`virtual_split`**, **`allowEstimatedForTrial=false`**. Auch gültige Rückmeldung oder Vorschau erteilt keine Freigabe.
- Wenn SDL-Auftrag exakt null, physische Batteriesumme statt gefilterter virtueller EV-Anzeige verwenden; unveränderter Nullauftrag ist Zustand, kein Messgeräte-Heartbeat. Eine neue EV-Vorgabe bedeutet noch keine sofortige physische Reaktion.
- Bei SDL ungleich null: zeitliche Abdeckung von Auftragsänderung, Tracking-Toleranz und explizite Schätzkennzeichnung. Gegenläufige EV-/SDL-Flüsse sind nicht eindeutig identifizierbar und bleiben für diesen Test gesperrt.
- Netzziel wird in **Gesamt-Batterieleistung**, nicht zusätzlichen Ladeauftrag übersetzt. Erwartete Änderungen anderer Verbraucher genau einmal berücksichtigen.
- Separate interne Server-Testsitzung, leere Default-Allowlist `NETPLAN_V4_CONTROL_TRIAL_PLANTS`, manuelle Familie, Anlagen-/Asset-/Instanz-/Revisionsbindung, beide lokalen Freigaben `NetzfahrplanV4RegeltestErlaubt`, bewusster lokaler Start, gültiger Plan, Bilanz- und Gerätewatchdog-Nachweis.
- Test max. 30 min / 5 kW je Richtung; Serverauthority maximal 90 s; Batteriebefehl maximal 10 s; Batterie-Softwarewatchdog 1 s, Manager-Testtakt 2 s. Nicht einfach Limits für Produktion hochsetzen.
- Batterie liest vor Ausgabe unabhängig neu und prüft SOC, Reserve, Hysterese, Verfügbarkeit, Sperrzeiten und Netzgrenzen. Unmögliches Netzziel → Testabbruch, keine Erfolgsbehauptung.
- Abbruch widerruft Sitzung vor Nullstellversuch; Stoppfehler bleibt sichtbar. Danach maximal eine **frisch berechnete** normale Zuteilung, keine Rückkehr zu gecachtem Test-/Vor-Testwert. Keine Wiederbelebung nach Neustart oder doppeltem Befehl.
- `shadow_seen` bedeutet Empfang, **nicht ausgeführt**. `canDispatch=false` in Vorschau bedeutet keine Vorschau-Freigabe. Bei einer separat gestarteten Testsitzung wäre `runMode=shadow` alleine trotzdem kein hinreichender Nachweis für null Stellbefehle.
- Softwarewatchdog funktioniert nur bei laufendem Kernel/Kommunikation. Kein Nachweis für Rechnerabsturz, Stromausfall oder unerreichbaren Wechselrichter. Bereits vorhandenes Verhalten prüfen, nicht erfinden und nicht Schutzgates entfernen.

## 11. Aktueller Blocker: bestätigter Geräteabruf statt falscher Zeitbasis

Letzter Installationsbericht `[A]`:

```
status: corrected_feedback_installed_trial_disabled
feedback.status: unavailable
feedback.reason: feedback_source_skew
batteryW: null
gridW: null
usableForTrial: false
canDispatch: false
```

Das ist **kein Installationsfehler**. Die Meldung „Modellanteil: nein“ im Installer ist im Fehlerfall irreführend: fehlendes Feld wird als false dargestellt, obwohl die Berechnung gar nicht erfolgreich war. Kleine UI-/Diagnosekorrektur mitnehmen.

Letzte Zeituntersuchung `[B]` (237 Aufnahmen / 2 h): 48 Aufnahmen mit Versatz >30 s. Netz median 1 s/max 2 s, GoodWe 1 median 1 s/max 48 s, GoodWe 2 median 1 s/max 46 s, SolarEdge median 12 s/max 59 s; SolarEdge in 223 Aufnahmen unter den ältesten Quellen. Keine der vier Quellen in genau diesem Zeitfenster über 60 s. Beispiel 13:58:38: drei Quellen neu, SolarEdge 31 s alt → Ablehnung. Frühere mehrminütige Lücken trotzdem nicht damit wegargumentieren.

**Nächste Umsetzung, ohne neue Diagnosekategorie:**

1. Installierten Gerätemodultyp und unterstützten Leseweg verifizieren. Im Gespräch wurde `ModBus_RequestRead()` als möglicher Ansatz genannt. API-/Erfolgs-/Zeitsemantik und Unterschied `ModBus Address` vs `ModBus Device` anhand offizieller aktueller Dokumentation und vorhandenem Code prüfen; nicht voraussetzen, dass ein boolescher Erfolg alle Register atomar aktualisiert oder einen unabhängigen Gerätezeitpunkt liefert.
2. Erfolgreiche vollständige Antwort mit genau den daraus stammenden Werten, Zuordnung, Status und Bestätigungszeit binden. `VariableUpdated`, Geräteabrufbestätigung und Sammlerzeit getrennt erhalten.
3. Begrenzte Abfragefrequenz, Timeout, Serialisierung, Kommunikationslast und Lesekohärenz berücksichtigen. Keine Netz-I/O in jedem Vorschau-/Regelcallback vervielfachen, keine blockierenden Abfragen unter dem Stellregler-Lock. Existierende erfolgreiche Polls nach Möglichkeit nutzen.
4. Wenn keine echte Bestätigung vorliegt, unsicher/gesperrt bleiben. Keine künstlichen `SetValue`-Herzschläge und keine permissive Freigabe bloss wegen des Pollerintervalls.
5. In bestehenden Batterie-/Managerpfad integrieren; Tests: unveränderte Werte mit erfolgreichem Abruf, fehlgeschlagene/partielle Antwort, Zeitversatz, Race, Wiederholung, Neustart, erneute unabhängige Batterieprüfung und Rückfall.
6. Zusammenhängenden Kandidaten bauen und testen; neue Runtime-Installation nur im bekannten gesicherten Verfahren. Bisherige Installer nicht nochmals ausführen.

Diese Arbeit wurde am Gesprächsende **noch nicht implementiert oder installiert**. Sie ist nicht durch die vorliegende Dokumentationsübergabe erledigt.

## 12. Produktionsreife: verbleibende echte Arbeiten

- Verlässlicher bestätigter Live-Messpfad wie oben; unklares AC/DC/externes SDL nicht durch Labels als verifiziert deklarieren.
- Neue Lastprofile mit tatsächlicher ausreichender Datenbasis/Validierung aufbauen und gezielt zur Schattenrechnung schalten. Aktuelle Einstellungen/Modelle vorher lesen, nicht alte Momentaufnahmen fortschreiben.
- **Dauerbetrieb** mit sauberem Authority-/Zustands-/Neustart-/Fallback-Verhalten implementieren. Bisher nur begrenzter Pilot, keine fertige kontinuierliche Produktionsfreigabe.
- Reale Callback-/Registerstrecke und separat freigegebener Stellversuch; korrekte Vorzeichen, verfügbare Leistungen, Netzziel/Peak-/Exportgrenzen, Abschalten/Verbindungsausfall, lokale Priorität und SDL-Konflikte prüfen.
- Modellautomatik über den deklarierten Frozen-Day-v1-Scope hinaus nur nach Erweiterung/Nachweis bewerben; Grenzen transparent halten.
- Lebenszyklus/Backups/Recovery/Observability, Mehranlagenisolierung und parametrisierte Inbetriebnahme. Einige Installer sind bewusst auf Lihrenmoos gebunden; für andere Anlagen nicht IDs blind übernehmen.
- Git-Authentifizierung/Veröffentlichung lösen; `develop` → geprüfte `beta` → Feldabnahme `main`. Browser-Login, Tailscale oder Portforwarding stellen nicht automatisch Git-Schreibauthentifizierung bereit. Keine Veröffentlichung behaupten, die nicht passiert ist.

## 13. Wichtige Meilensteine und nicht erneut auszuführende Installer

| Paket | Status bis Gesprächsende |
|---|---|
| V4-Schattenserver / Native Operation / Tarife | Installiert, Betrieb historisch belegt |
| Passiver Empfänger `/srv/agent/netplan-v4-receiver-stage/install.php` | Installiert, automatische `shadow_seen`-ACKs belegt |
| Rohsammler `/srv/agent/netplan-v4-data-capture-stage` | Separater früherer Sammler; Originaldateien erhalten |
| Leseexport `/srv/agent/netplan-v4-data-review-stage` | Einmaliger Export wegen restriktiver Originalrechte; heute keine erneute allgemeine Exportpflicht |
| Getrennter Beobachter `/srv/agent/netplan-v4-separated-observer-stage` | 23 Quellen, Dateien gezielt lesbar; weiterhin Originalbestand |
| Managerdaten `/srv/agent/netplan-v4-application-build/install.php` | Installiert, Klasse-/Kennungsfehler später behoben |
| `deploy_history_timing.py` | Installiert, neue Historienversion v2 |
| `deploy_unified_release.py --approve-numeric-mapping-compatibility` + `/srv/agent/netplan-v4-unified-release/install.php` | Installiert, Aliasfreigabe exakt registriert, Nachversand aufgeholt |
| `/srv/agent/netplan-v4-feedback-stage/install.php` | **Fertig installiert nach einmaliger Registrierungsschleife**, aktuell Zeitversatzprüfung |

Fachliche Commitfolge (lokales `develop`; nicht als Remote-/Runtime-Gleichstand missverstehen):
`b5c1fa6` Empfänger, `9394fe3` begrenzter Test, `e0e52d2` Bilanzierung, `76f8b06` Capture, `44362e4` getrennte Beobachtung, `fe3f46b` Datenanwendung, `6d9aba7` Klassenladen, `5890093` Historienzeit, `6c91d6b` Zahlennormalisierung, `8eb9688` Unified RC1, **`9878197` korrigierte Rückmelde-/Testkette**. Einige weitere Commits können dazwischenliegen; `git log` ist massgeblich.

## 14. Quellenindex und Tests – zuerst Nachweise lesen, nicht neu installieren

**[A] Letzte erfolgreiche Rückmeldeinstallation (Testhost):**
`/srv/agent/netplan-v4-feedback-stage/INSTALL_RESULT.json` – Ende `2026-10-03T11:59:58Z`. Der frühere `waiting_for_registration`-Bericht ist überholt. Die Sicherung stammt vom ersten Dateidurchlauf, nicht vom zweiten `already_installed`-Durchlauf.

**[B] Letzte Zeit-/Pipeline-Auswertung (Server):**
`/home/agent/services/qa/feedback-timing-20261003/TIMING_REVIEW.json` – `2026-10-03T12:02:13Z`, 140 brauchbare Fenster/11.646 h, Quelle v2 noch `collecting`.

**[C] Unified-Serverinstallation:**
`/home/agent/services/netplan-v4-shadow/unified-releases/20261003T105407.036202Z/REPORT.json`; Runtime `unified-rc1`, Mappingkompatibilität registriert, Einstellungen unverändert.

**[D] Unified-Managerinstallation (Testhost):**
`/srv/agent/netplan-v4-unified-release/INSTALL_RESULT.json`.

**[E] Historieninstallation:**
`/home/agent/services/netplan-v4-shadow/history-timing-releases/20261003T092245.175100Z/REPORT.json`.

**[F] Erfolgreiches Aufholen des Datenwegs:**
`/home/agent/services/qa/unified-release-20261003/FLOW-20261003T105834.324945Z.json`.

**[G] Installiertes und versioniertes Verhalten:**
`docs/netplan-v4-corrected-feedback.md`, `docs/netplan-v4-unified-release.md`, `docs/netplan-v4-history-timing.md`, `docs/netplan-v4-numeric-mapping-fix.md`, `docs/netplan-v4-application.md`, `docs/netplan-v4-controlled-trial.md`, `docs/netplan-v4-accounting.md`. Alte „noch nicht installiert“-Abschnitte dieser Entwicklungsdokumente durch aktuelle Installationsberichte einordnen; nicht mit echten Runtime-Nachweisen verwechseln.

**[H] Rückmelde-/Testsuite (Testhost):**
`/srv/agent/netplan-v4-feedback-stage/PREPARATION.json`, `TEST_RESULTS.txt`, `INSTALLER_TEST_RESULTS.json`, `ORDINARY_OFFER_TEST.json`, `MANIFEST.json`, `PACKAGE_HASHES.json`, `feedback-config.json`.
125 isolierte Funktionsprüfungen, 4 vollständige Modul-Linkageprüfungen, 10 Installationsszenarien, 13'824 übereinstimmende normale Leistungsangebotsfälle. Keine Aussage, dass dieselbe Zahl Tests im echten Kernel/Wechselrichter gelaufen sei.

**[I] Unified-Suite (Server):**
`/home/agent/services/qa/unified-release-20261003/PYTHON_TEST_RESULTS.txt`, `NODE_TEST_RESULTS.txt`, `PUBLICATION.json`, `DELIVERY_STATUS.json`.
306 Python- und 16 Portaltests; native separate Tests. Spätere Änderungen brauchen erneute relevante Tests, nicht bloss Übernahme dieser Zahlen.

**[J] Wiederaufbau und Code:**
EMS `examples/V4CorrectedFeedback/`, `examples/V4UnifiedRelease/`, `services/netplan-v4/commissioning/`. Staging ist nicht dieselbe Quelle wie das laufende Modul. Dateien, Hashs und Abhängigkeiten vor Änderungen vergleichen; Paralleländerungen abbrechen statt überschreiben.

**[K] Quellen-/Konfigurationsdiagnose (Testhost):**
`/srv/agent/netplan-v4-application-build/inspect_source_update_policy.py`, `inspect_delivery_state.py`, `MAPPING_IDENTITY_DIAGNOSIS.json`, `MAPPING_EQUIVALENCE.json`; `netplan-v4-feedback-stage/review_current_feedback_state.py`. Diese Skripte zuerst lesen; manche erzeugen nur einen Bericht, manche lesen gespeicherte statt live aktuelle Settings. Alte Settings-Snapshots können eine bereits installierte Eigenschaft noch nicht enthalten.

**Sicherheitsnotiz:** In einem alten Upload-Skript wurden Klartextzugangsdaten bemerkt. Nicht lesen, verbreiten, in Dokumentation/Git übernehmen oder für neue Integration verwenden. Separate autorisierte Rotation/Secret-Auslagerung bleibt Aufgabe; die Werte gehören nicht in diese Übergabe.

## 15. Übernahmeroutine für einen neuen Agenten

1. Host-`AGENT_CONTEXT.md`, Repo-`AGENTS.md` und diese Datei vollständig lesen; bei fehlendem Remote-Stand zuerst den Servercheckout prüfen.
2. `git status`/Branch/letzte Commits sowie `[A]`, `[B]`, `[C]` lesen. Zeitstempel nennen; keine alten Zähler als heutige Werte ausgeben. Diese Übernahme selbst ändert keine Anlage.
3. Nur notwendige gezielte Read-only-Prüfungen. Kein weiterer vollständiger Neustart der Analyse oder Wiederholung bereits erledigter Installer.
4. Bei Fortsetzungsauftrag direkt Abschnitt 11 umsetzen und anschliessend echte Restarbeiten aus Abschnitt 12 abarbeiten. Anforderungen, Testfall, Implementierung und Rollout in einem Paket halten.
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.