Stand: 15. Oktober 2026 – stabiler Release 2.0.0. Historische Versions-/Korrekturrunden bleiben als solche bezeichnet. F02, F08 und F04 V3 sind implementiert; externe Lecksensoren werden unterstützt (F04-FSR-H01 in 2.0.0 behoben, siehe F04 V3).

Ein Home-Assistant-Neustart darf einen aktiven Wasserfehler nicht stillschweigend in einen unkritischen Ausgangszustand verwandeln.

Gleichzeitig dürfen unsichere, unvollständige Beobachtungen nicht nach einem Neustart als sichere Evidenz weitergerechnet werden.

---

Jeder Config Entry verwendet einen eigenen Home-Assistant-Store.

Schlüssel sinngemäß:

water_leak_detection.runtime.<entry_id>

Gespeichert werden unter anderem:

• Detection-Engine-Runtime
• High-Flow-Bypass-Endzeit
• Quittierungszustände
• zugelassene Lernwerte

---

Bestätigte active-Zustände werden persistiert.

Dazu gehören unter anderem:

• Phase
• Startzeit
• Erkennungszeit
• Event-ID
• Volumenbezug
• Reset-/Quiet-Kontext
• Burst-Grund

Damit bleibt ein ernstes Ereignis über einen Neustart erhalten.

---

Die Engine kann Runtime-Zustände speichern, behandelt fehlende Messwerte aber konservativ.

Wenn die Quelle nicht verfügbar ist:

• normaler bestätigter Slow/Low/High-Monitoring-Fortschritt derselben Quelle bleibt erhalten; unbestätigte Burst-Kandidaten und Low-Stabilität werden unterbrochen
• laufende Quiet-/Resetintervalle werden verworfen

Warum?

Zeit ohne Messwert darf weder als Leck-Beweis noch als Null-Durchfluss-Beweis zählen.

---

Bereits bestätigte aktive Ereignisse bleiben aktiv.

Ein unbekannter Sensorzustand darf kein aktives Ereignis zurücksetzen.

Das ist die Konsequenz des Grundsatzes:

unknown != 0 L/h

---

Gespeichert wird der absolute Endzeitpunkt.

Nach einem Neustart:

• liegt der Zeitpunkt noch in der Zukunft → Bypass wird wiederhergestellt
• ist er bereits abgelaufen → Bypass bleibt aus

Dadurch kann ein Neustart einen Bypass nicht unbegrenzt verlängern.

---

Der Quittierungszustand wird pro Event-ID gespeichert.

Gespeichert werden:

• globale Quittierung
• welches Gerät global quittiert hat
• Zeitpunkt
• persönliche Mutes

Beim physischen Event-Ende wird der Quittierungszustand dieser Event-ID entfernt.

---

Persistiert werden ausschließlich bereits zugelassene, abgeschlossene normale Episoden.

Nicht gespeichert wird:

• eine gerade laufende, noch nicht abgeschlossene Lern-Episode

Eine Episode, die direkt vor einem Neustart oder Sensorausfall abbricht, kann nicht zuverlässig als normal bewertet werden.

Darum wird sie verworfen statt nachträglich „fertiggedacht“.

---

Wenn kein Gesamtverbrauchssensor zur Verfügung steht, wird Volumen aus Durchfluss und Zeit integriert.

Nach einer großen Zeitlücke wird die rückwirkende Integration begrenzt.

Damit wird nicht angenommen, dass der letzte bekannte Durchfluss während einer beliebig langen HA-Ausfallzeit unverändert weiterlief.

---

Bei einem Konfigurations-Reload:

1. alter Manager wird sauber entladen
2. aktueller Store wird gespeichert
3. neuer Manager lädt den Zustand
4. Quellenlistener und 10-Sekunden-Tick werden neu registriert
5. aktuelle Quellen werden sofort neu ausgewertet

---

Persistenz soll zwei gegensätzliche Fehler vermeiden:

Ein aktiver Burst darf nach Neustart nicht einfach verschwinden.

Ein unvollständig beobachteter Messzeitraum darf nicht als vollständiger Leak- oder Lernbeweis gelten.

Darum sind aktive Events langlebig, unbestätigte Zeitfenster bei fehlender Evidenz dagegen konservativ.

Sicherheitsübergänge werden mit einer festen Frist von 1 s gespeichert; Mess-/Lernupdates mit 10 s ab dem ersten vorgemerkten Update. Weitere Samples verschieben die Frist nicht. Event-Loop-Blockaden und Speicherfehler können diese Fristen überschreiten. Pro Event und Empfänger wird die erfolgreiche Annahme durch den Notify-Service persistiert. Nicht verfügbare/fehlgeschlagene Dienste werden erneut versucht; Quittierungen bleiben wirksam. Ein Absturz zwischen Versand und Speicherung kann eine doppelte Meldung verursachen.

Negative, nicht endliche und überalterte Messungen sind keine Ruhe-Evidenz. last_reported unterscheidet neue identische Meldungen von eingefrorenen Zuständen; die frühere automatische Meldekadenz wurde später entfernt: Option 0 setzt heute keine künstliche Max-Gap-Grenze (siehe aktuelle Regeln unten). Laufzeitintervalle verwenden eine monotone Uhr; Neustarts setzen unbestätigte Intervalle zurück. Zählerreset, unplausibler Sprung und Quellenwechsel lösen den alten Volumenbezug. Aktive Leckage und Absperranforderung bleiben dabei erhalten. Eingefrorene oder fehlende Totalwerte werden durch Durchflussintegration ersetzt. Die fachlichen Findings Auf dem Branch feature/f02-static-high-flow ist F02 fachlich geschlossen; diese Änderung ist noch nicht Bestandteil von 1.0.3. F04/F08 und die Rapid-Rise-Definition bleiben für eine separate Spezifikation offen.

Interne Ticks bestätigen weder Detektions- noch Quiet-Intervalle. Neue Meldungen werden unabhängig von UTC-Rückstellungen nach State-Identität/Meldung erkannt. Einzelne eingefrorene Werte können deshalb keinen Timer allein bestätigen. Der historische Kadenz-Anlauf aus Runde 2 wurde in Runde 6 entfernt; der aktuelle Mess-Evidenz-Vertrag steht unten. Die Engine-Zeitachse und laufende Bypass-Dauer sind monoton. Beim Speichern wird die UTC-Bypassfrist aus der verbleibenden Laufzeit neu projiziert. Persistierte aktive Laufzeit zählt Offline-Zeit nicht als bestätigte Laufzeit.

Zählerfortschritt nutzt einen gemeinsamen Referenzzeitraum über mehrere Flow-Reports; keine feste 1-Liter-Auflösung wird angenommen. Noch nicht unterstützte positive Sprünge bleiben vorgemerkt; eingefrorene Totals blockieren Flow-Integration nicht.

Notify-Aufgaben sind pro Event/Empfänger isoliert. Ein normaler Service-Return bedeutet HA-Annahme, keine bestätigte Telefonzustellung. Laufende Calls werden nicht nach 5 Sekunden als fehlgeschlagen abgebrochen und erneut gesendet. Beim Unload unterbrochene bereits laufende Übergaben sind unklar und werden nicht automatisch wiederholt. Beschädigte Runtime-Felder löschen ein anhand verbleibender Bestätigungsdaten klar erkennbares aktives Ereignis nicht. Unbestätigtes Monitoring bleibt verwerfbar.

Die historische Kadenzqualifikation aus Runde 3 wurde in Runde 6 entfernt. Interne Ticks zählen weiterhin weder Leak- noch Ruhezeit.

Steuerungsänderungen werden vor der Frischeprüfung angewendet. Deaktivieren von Slow/Low und Einschalten des High-Flow-Bypass greifen sofort nach den bestehenden Regeln; Burst bleibt unabhängig. Bypass-Ende erzeugt aus einem alten State kein Event.

Ein verworfener Totalwert braucht für erneute Akzeptanz einen neuen Totalreport oder echten Wertfortschritt. Bloßes Flow-Aufholen bestätigt einen eingefrorenen Zählersprung nicht. Quantisierte Fortschritte behalten ungenutzte Flow-Evidenz. Der Mengenvergleich enthält keinen pauschalen Faktor 1,5 mehr.

Notify-Status und laufende Aufgaben beziehen sich auf Event, Empfänger-ID und den konkret verwendeten Notify-Service. Ein unterbrochener alter Service sperrt keinen neu konfigurierten Versandweg. Event-Ende cancelt und erwartet nur dessen lokale Aufgaben. Bereits an HA übergebene Calls können weiterhin nicht zurückgerufen werden.

Alle vier Klassen restaurieren bestätigte Sicherheitsereignisse nach derselben Regel. reason ist optional. Neue Stores enthalten redundant confirmed_active; Altdaten bleiben lesbar. Aktionsunsichere Event-IDs werden ersetzt, ohne eine alte Quittierung zu übernehmen. Fehlen in Altdaten sämtliche Bestätigungsinformationen, kann daraus kein bestätigtes Ereignis erfunden werden.

Lern-Episoden messen Laufzeit monoton. Persistierte Lern-Samples erhalten dagegen die echte UTC des Abschlusses; das Rolling Window arbeitet ebenfalls mit realer UTC. Wiki-Dateien dieser Runde werden nur lokal gepflegt, nicht veröffentlicht.

Die Integration bewertet frische gültige Messmeldungen. Sie versucht im Automatikbetrieb nicht mehr, die Meldekadenz statistisch zu erraten. Erst der zweite Report bestätigt das abgeschlossene Intervall; während des Wartens erzeugen Ticks immer null Sekunden Evidenz. Bestätigte Monitoring-Zeit wird akkumuliert.

„Maximal anrechenbarer Abstand zwischen zwei Messwertmeldungen“ ist optional: 0 bedeutet keine künstliche Grenze. Bei einer positiven Grenze zählt Gleichheit; eine größere Lücke fügt null Sekunden hinzu und löscht keinen bisherigen Fortschritt. Weitere normale Intervalle zählen sofort wieder. Fachliche Resetregeln bleiben erhalten.

Beobachtetes unknown/unavailable oder ein ungültiger Flow unterbricht die Messkette und erzeugt weder Leak- noch Ruhe-Evidenz. Unbestätigte Monitoring-/Quiet-Fenster werden nach den bestehenden Ausfallregeln verworfen; aktive Leaks bleiben aktiv. Der erste gültige Report danach startet mit null Evidenz eine neue Messkette.

Ohne explizite Max-Gap-Einstellung lassen sich eine legitime langsame Meldekadenz und ein stiller Kommunikationsausfall zwischen zwei gültigen Reports nicht unterscheiden. Ein späterer gültiger Report kann daher ein langes Intervall bestätigen. Die Grenze wird niemals automatisch aus Reportmustern abgeleitet.

Der veröffentlichte Beta.3-Stand verwendet HA-Store-/Learning-Schema 2 mit atomarer Legacy-Learning-Quarantäne. ACTIVE, ACK und Shutoff bleiben erhalten. Externe Lifecycles, generationsgebundene Nonces und getrennte Lernkanäle sind beschrieben in F04 V3. Ein fehlgeschlagener Reset-Schreibvorgang gibt keinen Sicherheitsbeitrag frei. Die frühere F04-Roadmap bleibt historischer Kontext.

Die neue Anzeige wird nicht aus einem früheren „Aktiv“ restauriert, sondern aus aktuellen Manager-Entscheidungen neu abgeleitet. Start/Quellenwechsel wartet auf eine gültige Messung; eine explizit unverfügbare Quelle oder abgewiesene Messung zeigt Gesperrt. Cached/retained/replayed Werte können nach Restart gesperrt sein, obwohl zuvor ein Alarm bestätigt war. Dieser ACTIVE-Alarm bleibt erhalten.

Vor Store-I/O wird die tatsächliche Setupzeit erfasst. Nach Restore bindet MqttProvenance.bind_startup() die Grenze einmal an das Maximum aus gespeicherter Grenze und Setupbeginn. Neue Quellengenerationen werden ebenfalls explizit initialisiert. Die Prüfzeit des ersten Reports verschiebt die Grenze nicht. Retained, Replay, Out-of-Order, Zukunft, Messalter, echte Unterbrechungen und Persistenzfehler bleiben geschützt. Erster gültiger Report: null Sekunden; interne Ticks erzeugen weder Verbrauchs- noch Ruhe-Evidenz.

Aktuelle Round7-Regel: Normaler bestätigter Slow/Low/High-Monitoring-Fortschritt bleibt bei Unterbrechung derselben Quelle erhalten; Quiet-Fenster, Low-Stabilität und unbestätigte Burst-Kandidaten werden unterbrochen. Ein tatsächlicher Quellenwechsel verwirft unbestätigten Fortschritt, übernimmt aber keine Entwarnung für bestätigte ACTIVE-Alarme. Diagnose. Die historischen Korrekturrunden oben sind keine abweichende aktuelle Kadenz- oder Resetregel.

Am 14. Oktober 2026 wurde Home Assistant mit installierter 1.2.0-beta.3 und einem realen Hydrus-Wasserzähler neu gestartet. Der Benutzer bestätigte:

Prüfung	Beobachtung
Fehlalarm beim Neustart	Keiner
Home-Assistant-Reparaturmeldung	Keine
Hydraulische Überwachung	Zunächst 11 Sekunden „Gesperrt“
Anschließender Zustand	Automatisch „Aktiv“
MQTT-Messherkunft	verified_original_measurement

Dieser konkrete Neustarttest wurde erfolgreich bestanden. Die vorübergehende Sperre ist mit der sicherheitsgerichteten Freigabe vereinbar; die Quelle wurde anschließend automatisch für hydraulische Erkennung freigegeben. Das ist ein Benutzerbefund, kein von Codex selbst ausgeführter Hardwaretest. Keine zusätzlichen Payloads, Logeinträge oder technischen Ablehnungsgründe werden daraus erfunden.

Die 11 Sekunden sind ein beobachteter Einzelwert, keine garantierte Startdauer. Nicht sämtliche Neustart-, Funk-, Replay-, MQTT-Ausfall- oder Recovery-Szenarien wurden damit geprüft. Vorhandene Schutz-/Resetregeln bleiben uneingeschränkt.

Die Anzeige Hydraulische Überwachung beschreibt die Betriebsfreigabe:

• Aktiv (active): gültige hydraulische Messwerte dürfen verarbeitet werden.
• Warte auf Messung (waiting_for_measurement): nach Start/Quellenwechsel fehlt die erste gültige Messung, ohne ausdrücklich festgestellte Sperre.
• Gesperrt (blocked): die Quelle/Auswertung ist ausgeschlossen; Attribute geben den konkreten Grund an. Die Entität bleibt bei laufender Integration sichtbar.

Dies ist nicht der Alarmzustand: „Kein Alarm“ beweist keine aktive Überwachung, und Gesperrt ist weder ein Leckalarm noch ein ACK oder physischer Reset. Ein vor Quellenverlust bestätigter ACTIVE-Alarm mit Shutoff-Beitrag bleibt nach seinen bestehenden Regeln bestehen. Diagnose.