Projektueberblick - BeGiBue/home-assistant-water-leak-guard GitHub Wiki
Projektüberblick
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).
Identität
| Eigenschaft | Wert |
|---|---|
| Deutscher Name | Wasserwächter |
| Englischer Name | Water Leak Guard |
| Technische Domain | water_leak_detection |
| Plattform | Home Assistant |
| Integrationstyp | Service-Integration |
| Aktueller Release | 2.0.0 (stabil) |
| Repository | BeGiBue/home-assistant-water-leak-guard |
| Fokus | Backend-Integration |
| Sprache | folgt der in Home Assistant eingestellten Sprache; Deutsch und Englisch enthalten |
Problemstellung
Ein einzelner Grenzwert reicht für eine brauchbare Wasserleck-Erkennung nicht aus.
Ein Durchfluss von 7 L/h ist in einem Haushalt klein, kann über Stunden aber eindeutig auf einen dauerhaften Verlust hindeuten. Ein Durchfluss von 600 L/h kann beim Duschen oder Befüllen einer Badewanne normal sein, über lange Zeit aber auffällig werden. Ein plötzlicher Sprung auf mehrere Tausend Liter pro Stunde ist wiederum eine völlig andere Gefahrenklasse.
Der Wasserwächter behandelt diese Fälle daher nicht als einen Alarm mit vier Schwellen, sondern als vier unabhängige Zustandsautomaten mit eigenen Regeln.
Primäre Messquellen
Erforderlich: Durchfluss
Es wird ein Durchflusssensor benötigt.
Intern wird jeder unterstützte Wert auf Liter pro Stunde (L/h) normiert.
Unterstützte typische Einheiten sind unter anderem:
- L/h
- L/min
- L/s
- m³/h
- m³/min
- m³/s
Optional: kumulierter Gesamtverbrauch
Ein Gesamtverbrauchssensor ist optional, aber empfohlen.
Intern wird dieser Wert auf Liter normiert.
Er verbessert insbesondere:
- Ereignisvolumen
- High-Flow-Mengenbewertung
- Ereignisstatistik
Ist kein Gesamtverbrauch verfügbar, kann die Integration Volumen aus Durchfluss und Zeit abschätzen.
Referenzinstallation
Die Entwicklung wurde unter anderem für eine typische Hausinstallation mit folgenden Referenzwerten ausgelegt:
- Hausanschluss etwa DN25 / 1"
- statischer Druck etwa 3,5 bar
- Durchflusssensor mit effektiver Auflösung etwa 1 L/h
Diese Werte sind keine Voraussetzung. Rohrdurchmesser und Druck können in den Experteneinstellungen angepasst werden.
Funktionsblöcke
Der Wasserwächter besteht funktional aus sechs Schichten:
- Messwerterfassung und Normalisierung
- Leckage-Zustandsautomaten
- Adaptives Lernmodell
- Hydraulische Plausibilisierung
- Alarmierung und Quittierung
- Water-Shut-Off-Anforderung
Leitprinzipien
Erkennung ist nicht Quittierung
Wenn ein Benutzer einen Alarm gesehen hat, ist das physische Wasserproblem nicht automatisch verschwunden.
Darum beeinflusst eine Quittierung nicht den Detektor.
Water Shut Off ist nicht Alarmstatus
Eine Absperranforderung ist eine eigene Sicherheitsentscheidung.
Sie kann aktiv bleiben, obwohl eine Benachrichtigung quittiert wurde.
Burst hat Vorrang
Ein Burst Leak darf nicht durch den High-Flow-Bypass unterdrückt werden.
Lernen darf Gefahren nicht normalisieren
Verdächtige High-/Burst-Situationen und High-Flow-Bypass-Zeiten werden nicht als normales Nutzungsverhalten in das Lernmodell aufgenommen.
Unbekannt ist nicht Null
Ein nicht verfügbarer Durchflusssensor wird niemals als 0 L/h interpretiert.
Dadurch kann ein Sensorausfall keinen aktiven Alarm künstlich „wegresetten“.
Detektorpriorität
Wenn mehrere Detektoren gleichzeitig aktiv sind, bestimmt die höchste aktive Klasse den sichtbaren Gesamtstatus:
Slow Leak < Low Flow < High Flow < Burst Leak
Die niedrigeren Detektoren dürfen intern weiter aktiv bleiben. Das ist wichtig, weil ihre physische Ursache durch einen höher priorisierten Wasserverbrauch nicht zwingend verschwunden ist.
Versionsentwicklung
0.1 – Kern
- Messquellen
- Slow / Low / High / Burst
- Entitäten und Events
- High-Flow-Bypass
- Water-Shut-Off-Request
- Persistenz
0.2 – Benachrichtigungen
- mehrere Companion-Empfänger
- persönliche Stummschaltung
- globale Quittierung
- Home-Zone-Autorisierung
- stationäre Home-Geräte
- erneute Alarmierung bei Heimkehr
0.3 – Adaptives Modell
- kontinuierliches Lernmodell
- Confidence-Stufen
- Kurz-/Langzeitreferenzen
- hydraulische Plausibilisierung
- statische High- und adaptive Burst-Grenzen
- Burst-Erkennung über schnellen Durchflussanstieg
Betriebsstand 2.0.0
2.0.0 (15. Oktober 2026) ist der stabile Stand: hydraulische Erkennung (Slow, Low, High, Burst), Benachrichtigungen, die mitgelieferte Dashboard-Karte 0.6.2 mit Gerätekopplung und Wanddisplay sowie externe Lecksensoren. Die frühere Beta-Einschränkung auf Installationen ohne externe Sensoren entfällt, weil F04-FSR-H01 in 2.0.0 behoben ist (Details). Die Integration betätigt selbst kein Ventil. Nicht auf jeder echten Hardware geprüft. Release Notes.
Die folgenden Abschnitte „Betriebsstand Beta.3“ und „Betriebsstand 2.0.0-beta.1“ sind historisch.
Betriebsstand Beta.3 (historisch)
PR #15 liefert Logo/Bildmaterial und eine vorbereitete manuelle Lovelace-Karte 0.1.0; PR #16 behebt die verzögerte erste MQTT-Messung; PR #17 ergänzt Hydraulische Überwachung. Die Zustände Aktiv / Warte auf Messung / Gesperrt sind von Alarmen unabhängig. Gesperrt bleibt als nutzbarer Sensorzustand sichtbar; bestehende ACTIVE-Ereignisse und Shutoff-Beiträge bleiben erhalten. Entitäten · Diagnose.
Die Beta war auf hydraulische Erkennung/Benachrichtigungen ohne konfigurierte externe Sensoren oder gespeicherte externe Alarmdatensätze beschränkt. F04-FSR-H01 (beschädigte gespeicherte Daten konfigurierter externer Melder) ist in 2.0.0 behoben (Details). Softwaretests und der am 14. Oktober 2026 vom Benutzer bestätigte erfolgreiche Hydrus-Neustart mit Beta.3 sind getrennte Nachweise; der Einzeltest belegt nicht sämtliche Ausfall-/Neustartszenarien. Beta-Chronologie. Kartendokumentation.
Betriebsstand 2.0.0-beta.1 (historisch)
Die Dashboard-Karte wird seit 2.0.0-beta.1 mit der Integration geladen. Sie zeigt Alarm und hydraulische Überwachung getrennt und bietet gekoppelten Geräten Stummschalten, globale Quittierung und externen Reset an, jeweils nur wenn das Backend es erlaubt. Erkennung, Alarm- und Absperrlogik sind unverändert. Der Beta-Umfang blieb damals ohne externe Lecksensoren.