Getestet mit Home Assistant 2026.9 und dem Senvolon Füllstandmesser · Stand 22.09.2026

Eine volle Zisterne ist im Sommer ein gutes Gefühl. Im Herbst ist sie oft verschenktes Potenzial. Kündigt sich ein Regentag mit 15 Millimetern an und die Zisterne steht randvoll, läuft das Dachwasser direkt in den Überlauf.

Solche Tage sind keine Ausnahme. Der Klimaatlas NRW zählt im Landesmittel der Jahre 1991 bis 2020 rund 24 Tage pro Jahr mit mehr als 10 mm Niederschlag und sechs Tage mit mehr als 20 mm. An jedem davon nimmt eine volle Zisterne nichts mehr auf.

Das Prinzip dagegen heißt Regenrückhalt oder Retention. In Neubaugebieten schreibt der Bebauungsplan häufig Retentionszisternen mit fester Ablaufblende vor, die Dachwasser nur gedrosselt in den Kanal lassen. Kommerzielle Systeme gehen weiter und entleeren den Speicher vor einem angekündigten Regen um die Menge, die voraussichtlich nachkommt. Wer den Füllstand der Zisterne überwacht, kann das mit Home Assistant nachbauen. Die Prognose aus Teil 2 liefert bereits, wie viele Liter der Regen bringt. Neu ist die Entscheidung, ob das noch hineinpasst und wohin das Wasser vorher geht: ins Haus oder in den Garten, wo es genutzt wird, oder früh in Versickerung oder Kanal, damit es dort nicht mitten im Regen ankommt.

Wichtig zur Einordnung: Eine Zisterne mit korrekt angeschlossenem Überlauf nimmt bei Vollstand keinen Schaden. Gelegentliches Überlaufen ist sogar erwünscht, weil dabei die Schwimmschicht an der Wasseroberfläche ausgespült wird. Es geht in diesem Artikel also nicht darum, Überlauf zu verhindern, sondern darum, zu bestimmen, wann er stattfindet und wohin das Wasser vorher geht. Anders sieht es bei Behältern ohne Überlauf aus (IBC-Container, Regentonnen). Dafür gibt es am Ende einen eigenen Abschnitt.

Inhalt

Voraussetzungen

• Senvolon Füllstandmesser als WLAN-Füllstandsanzeige für die Zisterne, per MQTT in Home Assistant integriert, mit aktivierter „Home Assistant"-Option (MQTT Discovery). Wie das geht, zeigt die Anleitung Füllstandsensor in Home Assistant integrieren.
• Die Bausteine aus Teil 2 (Regenzufluss-Zähler, Ertragsfaktor und der trigger-basierte Prognose-Sensor in templates.yaml). Ohne den gelernten Ertragsfaktor lässt sich die Prognose nicht in Liter umrechnen.
• Optional der Trockenlaufschutz aus Teil 1, falls die Zisterne über die Gartenpumpe entleert wird
• Eine schaltbare Abgabe für das Wasser: ein Bewässerungsventil, die Gartenpumpe an einer smarten Steckdose oder eine Tauchpumpe, die in die Versickerung fördert
• Eine konfigurierte Wetter-Integration mit Tagesvorhersage (hier: Met.no)
• Folgende bestehende Entitäten:

Entität	Herkunft	Bedeutung
sensor.level_sensor_fluid	Sensor	Füllstand in Litern
sensor.level_sensor_alert	Sensor, genutzt in Teil 1	Alarm-Entität, MIN bedeutet Trockenlaufgefahr
sensor.zisterne_ertrag_pro_mm	Teil 2	Gelernter Liter-pro-mm-Faktor
weather.forecast_home	Wetter-Integration	Vorhersage-Entität
switch.bewaesserung	Ihr Setup	Schaltbare Wasserabgabe (Entity-ID anpassen, z. B. die Steckdose der Gartenpumpe)

Architektur im Überblick

Vier neue Bausteine:

1. Freie Kapazität: Nennvolumen minus aktueller Füllstand. Wie viele Liter passen noch rein?
2. Kurzfrist-Prognose: Regenertrag der nächsten 48 Stunden in Litern. Die 7-Tage-Prognose aus Teil 2 ist zum Planen gut, zum Handeln aber zu unscharf.
3. Zielstand und Risiko: Ein berechneter Zielfüllstand, auf den die Zisterne vor dem Regen abgesenkt werden soll, plus ein Binärsensor, der meldet, ob überhaupt Handlungsbedarf besteht.
4. Automation mit drei Reaktionsstufen: Push-Nachricht, Bewässerung vorziehen oder früh ablassen. Sie wählen, was zu Ihrem Setup passt.

Dazu kommt eine Notbremse, die das Ablassen unabhängig von allem anderen stoppt, sobald der Mindestfüllstand erreicht ist oder der Sensor ausfällt.

---

Baustein 1: Freie Kapazität

1.1 Nennvolumen und Mindestfüllstand hinterlegen

Zwei Helfer vom Typ Zahlenwert-Eingabe (Einstellungen → Geräte & Dienste → Helfer → + Helfer erstellen → Zahlenwert-Eingabe):

• Name: Zisterne Volumen, Minimum 0, Maximum 100000, Schrittweite 10, Maßeinheit L, Anzeigemodus Eingabefeld. Hier das nutzbare Volumen bis zur Überlaufkante eintragen, z. B. 6000.
• Name: Zisterne Mindestfüllstand, gleiche Einstellungen. Unter diesen Stand wird nie abgelassen, z. B. 1500.

Entity-IDs: input_number.zisterne_volumen und input_number.zisterne_mindestfullstand

Stolperstein: Home Assistant ersetzt Umlaute in der Entity-ID durch den Grundbuchstaben, nicht durch „ue“. Aus „Mindestfüllstand“ wird zisterne_mindestfullstand, aus „Regenrückhalt“ später zisterne_regenruckhalt_aktiv. Alle YAML-Beispiele in diesem Artikel verwenden diese Schreibweise. Wer seine Helfer anders benennt, prüft die IDs unter Entwicklerwerkzeuge → Zustände.

Der Anzeigemodus Eingabefeld ist bei einem Maximum von 100.000 Litern sinnvoll. Als Schieberegler lässt sich ein Wert wie 6000 kaum genau treffen.

Warum ein Mindestfüllstand? Wettervorhersagen irren. Wenn der angekündigte Regen ausbleibt, soll die Zisterne nicht leer sein, sondern eine Reserve behalten. Der Wert sollte deutlich über der MIN-Schwelle des Sensors aus Teil 1 liegen, damit die Pumpe nie in den Grenzbereich kommt.

1.2 Sensor für die freie Kapazität

Helfer → + Helfer erstellen → „Template" → Sensor-Template

• Name: Zisterne freie Kapazität
• Zustand:

{% set volumen = states('input_number.zisterne_volumen') | float(0) %}
{% set fluid = states('sensor.level_sensor_fluid') | float(0) %}
{{ [volumen - fluid, 0] | max | round(0) }}

• Maßeinheit: L
• Geräteklasse: Gespeichertes Volumen, Zustandsklasse: Messwert

Das [..., 0] | max fängt den Fall ab, dass der Sensor durch Wellenbewegung oder eine großzügig eingestellte Tankgeometrie kurzzeitig mehr als das Nennvolumen meldet.

Stolperstein: Die naheliegende Geräteklasse Wasser lässt sich nicht mit der Zustandsklasse Messwert kombinieren, Home Assistant verweigert dann das Speichern. Wasser ist für Zähler gedacht, die nur hochlaufen. Für einen Bestand wie Füllstand oder freie Kapazität ist Gespeichertes Volumen die passende Klasse.

Mit der Geräteklasse Gespeichertes Volumen zeigt Home Assistant zwei Nachkommastellen an, obwohl das Template auf ganze Liter rundet. Wer das nicht möchte, öffnet die Entität, klickt auf das Zahnrad und stellt die Anzeigegenauigkeit auf ganze Zahlen.

---

Baustein 2: Kurzfrist-Prognose (48 Stunden)

Der Sensor aus Teil 2 (sensor.zisterne_regenertrag_7d) lebt in templates.yaml in einem trigger-basierten Block. Dort kommt ein zweiter Sensor dazu, der denselben Wetterabruf nutzt und nur die ersten zwei Tage der Vorhersage summiert. Der komplette Block sieht danach so aus:

- trigger:
    - trigger: time_pattern
      hours: "/1"
  action:
    - action: weather.get_forecasts
      target:
        entity_id: weather.forecast_home
      data:
        type: daily
      response_variable: forecast_data
  sensor:
    - name: "Zisterne Regenertrag 7d"
      unique_id: zisterne_regenertrag_7d
      unit_of_measurement: L
      icon: mdi:weather-pouring
      state: >
        {% set forecast = forecast_data['weather.forecast_home'].forecast %}
        {% set regen_mm = forecast[:7] | map(attribute='precipitation') | map('float', 0) | sum %}
        {% set ertrag_pro_mm = states('sensor.zisterne_ertrag_pro_mm') | float(30) %}
        {{ (regen_mm * ertrag_pro_mm) | round(0) }}
      attributes:
        regen_mm_7d: >
          {% set forecast = forecast_data['weather.forecast_home'].forecast %}
          {{ (forecast[:7] | map(attribute='precipitation') | map('float', 0) | sum) | round(1) }}

    - name: "Zisterne Regenertrag 48h"
      unique_id: zisterne_regenertrag_48h
      unit_of_measurement: L
      icon: mdi:weather-lightning-rainy
      state: >
        {% set forecast = forecast_data['weather.forecast_home'].forecast %}
        {% set regen_mm = forecast[:2] | map(attribute='precipitation') | map('float', 0) | sum %}
        {% set ertrag_pro_mm = states('sensor.zisterne_ertrag_pro_mm') | float(30) %}
        {{ (regen_mm * ertrag_pro_mm) | round(0) }}
      attributes:
        regen_mm_48h: >
          {% set forecast = forecast_data['weather.forecast_home'].forecast %}
          {{ (forecast[:2] | map(attribute='precipitation') | map('float', 0) | sum) | round(1) }}

Ein Neustart ist nicht nötig. Unter Entwicklerwerkzeuge → YAML → Konfiguration prüfen kontrollieren, dann bei den YAML-Konfigurationen neu laden auf Template-Entitäten klicken. Das übernimmt auch trigger-basierte Templates.

Zur nächsten vollen Stunde erscheint der neue Sensor unter Entwicklerwerkzeuge → Zustände mit dem Attribut regen_mm_48h:

Stolperstein: forecast[:2] enthält den heutigen und den morgigen Tag. Der heutige Eintrag der Tagesvorhersage umfasst je nach Wetterdienst nur die noch verbleibenden Stunden. Wer morgens um 8 Uhr nachschaut, sieht also die nächsten 40 Stunden, nicht 48. Für die Entscheidung „Platz schaffen oder nicht" ist das unkritisch, weil der Sensor stündlich neu rechnet.

Stolperstein: Der neue Sensor steht nach dem Neuladen auf unbekannt und bekommt erst zur nächsten vollen Stunde einen Wert. Wer sofort testen will, stellt den Trigger kurzzeitig auf minutes: "/2" (danach zurückstellen und erneut neu laden, sonst ruft Home Assistant die Wetter-API unnötig oft ab).

---

Baustein 3: Zielstand und Überlaufrisiko

3.1 Zielstand berechnen

Der Zielstand ist der Füllstand, bei dem der erwartete Regen gerade noch hineinpasst, mit 20 Prozent Sicherheitsaufschlag auf die Prognose. Er darf aber nie unter den Mindestfüllstand fallen.

Helfer → + Helfer erstellen → „Template" → Sensor-Template

• Name: Zisterne Zielstand vor Regen
• Zustand:

{% set volumen = states('input_number.zisterne_volumen') | float(0) %}
{% set minimum = states('input_number.zisterne_mindestfullstand') | float(0) %}
{% set prognose = states('sensor.zisterne_regenertrag_48h') | float(0) %}
{% set ziel = volumen - (prognose * 1.2) %}
{{ [ziel, minimum] | max | round(0) }}

• Maßeinheit: L
• Geräteklasse: Gespeichertes Volumen, Zustandsklasse: Messwert

Die Vorschau unten im Dialog zeigt sofort, welchen Zielstand das Template mit Ihren Werten berechnet:

Beispiel: 6000 L Volumen, 1500 L Mindestfüllstand, Prognose 1800 L. Zielstand = 6000 minus 2160 = 3840 L. Steht die Zisterne aktuell bei 5200 L, müssen 1360 L weichen.

Der Faktor 1,2 ist bewusst konservativ gewählt. Wer seinen Ertragsfaktor über einen ganzen Sommer kalibriert hat und der Prognose vertraut, kann auf 1,1 gehen. Wer den Faktor lieber im Dashboard anpassen möchte, legt dafür einen weiteren Zahlenwert-Helfer an und ersetzt die 1.2 im Template durch states('input_number.zisterne_sicherheitsfaktor') | float(1.2).

3.2 Überlaufrisiko als Binärsensor

Helfer → + Helfer erstellen → „Template" → Binärsensor-Template

• Name: Zisterne Überlaufrisiko
• Zustand:

{% set fluid = states('sensor.level_sensor_fluid') | float(0) %}
{% set ziel = states('sensor.zisterne_zielstand_vor_regen') | float(0) %}
{% set regen_mm = state_attr('sensor.zisterne_regenertrag_48h', 'regen_mm_48h') | float(0) %}
{{ regen_mm >= 8 and fluid > ziel + 200 }}

• Geräteklasse: Problem

Entity-ID: binary_sensor.zisterne_uberlaufrisiko

Zwei Schutzbedingungen stecken im Template:

• regen_mm >= 8: Bei Nieselregen soll nichts passieren, auch wenn die Zisterne randvoll ist. Der Schwellwert von 8 mm entspricht einem ordentlichen Regentag, kein Starkregen. Wer nur bei echten Ereignissen reagieren will, setzt 15 oder 20.
• fluid > ziel + 200: Eine Hysterese von 200 Litern. Ohne sie würde der Sensor um den Zielstand herum ständig ein- und ausschalten, sobald die erste Ablassaktion den Stand knapp unter das Ziel drückt und die nächste Prognose ihn wieder knapp darüber setzt.

---

Baustein 4: Die Automation

4.1 Freigabeschalter

Ein Helfer vom Typ Umschalter: Zisterne Regenrückhalt aktiv (Entity-ID input_boolean.zisterne_regenruckhalt_aktiv). Damit lässt sich die Logik im Winter, bei Abwesenheit oder zum Testen abschalten, ohne die Automation anzufassen.

4.2 Reaktionsstufe wählen

Stufe 1: Nur melden. Eine Push-Nachricht nennt Prognose, Zielstand und die Menge, die weichen müsste, den Rest entscheiden Sie. Wer WC oder Waschmaschine aus der Zisterne versorgt, nimmt die Nachricht als Hinweis, in den nächsten zwei Tagen bevorzugt dort Wasser zu verbrauchen. Das schafft Platz und spart Trinkwasser, ohne dass etwas abgelassen wird. Stufe 1 ist außerdem der richtige Einstieg, um die Prognose ein paar Wochen zu beobachten.

Stufe 2: Bewässerung vorziehen. Die Automation öffnet das Ventil oder startet die Gartenpumpe, bis der Zielstand erreicht ist. Am meisten bringt das nach einer Trockenphase, wenn der Boden das Wasser aufnehmen kann. Steht ohnehin kräftiger Regen an, hat der Garten wenig davon, der Platz in der Zisterne ist trotzdem gewonnen. Im Herbst lohnt eine zusätzliche Bedingung, dass der Boden nicht schon gesättigt ist, etwa über einen Bodenfeuchtesensor.

Stufe 3: Früh ablassen. Eine Tauchpumpe fördert das Wasser dorthin, wohin auch der Überlauf führt, in die Versickerung oder in den Kanal, aber vor dem Regen statt mittendrin. Bei einer Mischkanalisation kann das mehr bewirken, als es klingt: Läuft der Kanal bei Starkregen voll, gelangt verdünntes Abwasser über Entlastungsbauwerke ungeklärt in Bäche und Flüsse. Jeder Liter, der schon vorher abgeflossen ist, fehlt in dieser Spitze. Bei der Versickerung gilt dasselbe mit einer Einschränkung: Hängt dort auch der Überlauf, trifft der Regen auf schon nassen Boden, ein separater Sickerbereich oder eine Mulde bringt mehr. Ob Sie gezielt in den Kanal pumpen dürfen, regelt die Entwässerungssatzung Ihrer Gemeinde.

Die Automation unten ist für Stufe 2 geschrieben. Für Stufe 3 tauschen Sie den Schalter gegen die Pumpe, für Stufe 1 behalten Sie die erste Push-Nachricht und löschen alles danach.

4.3 Automation anlegen

Am schnellsten geht es mit den beiden Blueprints. Ein Blueprint ist eine Automation mit Platzhaltern: Home Assistant fragt beim Anlegen in einem Formular, welcher Sensor, welcher Schalter und welche Wetter-Entität gemeint sind, und Sie müssen keine Entity-ID im YAML anpassen.

Zisterne Platz schaffen vor Regen

Zisterne Ablassen stoppen (Notbremse)

Nach dem Import unter Einstellungen → Automationen → Blueprints den Blueprint anklicken und die Entitäten aus den Bausteinen 1 bis 3 auswählen. Wer die Logik sehen oder erweitern möchte, legt die Automation direkt als YAML an:

Einstellungen → Automationen → Automation erstellen → In YAML bearbeiten

alias: Zisterne Platz schaffen vor Regen
description: >
  Senkt den Füllstand vor einem angekündigten Regenereignis auf den
  berechneten Zielstand ab. Meldet vorher per Push und stoppt bei
  Zielstand, Zeitüberschreitung oder wenn die Prognose zurückgeht.
triggers:
  - trigger: state
    entity_id: binary_sensor.zisterne_uberlaufrisiko
    to: "on"
    for:
      minutes: 30
conditions:
  - condition: state
    entity_id: input_boolean.zisterne_regenruckhalt_aktiv
    state: "on"
  - condition: time
    after: "08:00:00"
    before: "20:00:00"
  - condition: numeric_state
    entity_id: weather.forecast_home
    attribute: temperature
    above: 3
  - condition: not
    conditions:
      - condition: state
        entity_id: sensor.level_sensor_alert
        state: MIN
actions:
  - variables:
      fluid: "{{ states('sensor.level_sensor_fluid') | float(0) | round(0) | int }}"
      ziel: "{{ states('sensor.zisterne_zielstand_vor_regen') | float(0) | round(0) | int }}"
      ablassen: "{{ fluid - ziel }}"
      regen_mm: "{{ state_attr('sensor.zisterne_regenertrag_48h', 'regen_mm_48h') | float(0) }}"
      prognose_l: "{{ states('sensor.zisterne_regenertrag_48h') | float(0) | round(0) | int }}"
  - action: notify.mobile_app_ihr_smartphone
    data:
      title: "Zisterne: Platz schaffen"
      message: >
        In 48 h werden {{ regen_mm }} mm Regen erwartet, das sind rund
        {{ prognose_l }} L für die Zisterne. Aktuell {{ fluid }} L,
        Zielstand {{ ziel }} L. Bewässerung startet und lässt
        {{ ablassen }} L in den Garten.
  - action: switch.turn_on
    target:
      entity_id: switch.bewaesserung
  - wait_template: >
      {{ states('sensor.level_sensor_fluid') | float(0)
         <= states('sensor.zisterne_zielstand_vor_regen') | float(0)
         or state_attr('sensor.zisterne_regenertrag_48h', 'regen_mm_48h') | float(0) < 8 }}
    timeout:
      hours: 4
    continue_on_timeout: true
  - action: switch.turn_off
    target:
      entity_id: switch.bewaesserung
  - action: notify.mobile_app_ihr_smartphone
    data:
      title: "Zisterne: Bewässerung beendet"
      message: >
        {% set fluid = states('sensor.level_sensor_fluid') | float(0) %}
        {% set ziel = states('sensor.zisterne_zielstand_vor_regen') | float(0) %}
        Füllstand jetzt {{ fluid | round(0) | int }} L.
        {% if not wait.completed %}Zeitlimit von 4 h erreicht, bitte Ventil und Sensor prüfen.
        {% elif fluid <= ziel %}Zielstand von {{ ziel | round(0) | int }} L erreicht.
        {% else %}Regenprognose zurückgenommen, Absenken nicht mehr nötig.{% endif %}
mode: single

notify.mobile_app_ihr_smartphone durch den eigenen Notify-Dienst ersetzen (Entwicklerwerkzeuge → Aktionen → nach notify. filtern), switch.bewaesserung durch den eigenen Schalter.

Die Bedingungen und Grenzen im Einzelnen:

• for: 30 Minuten: Ein einzelner Prognose-Ausreißer löst nichts aus.
• 8 bis 20 Uhr: Die Pumpe läuft nur, wenn jemand es bemerkt, falls etwas schiefgeht.
• Über 3 °C: Gefrorener Boden nimmt kaum Wasser auf, und eine laufende Leitung bei Frost ist ein eigenes Risiko. Gemeint ist die Außentemperatur der Wetter-Entität, nicht die Gehäusetemperatur des Sensors.
• Alarm nicht auf MIN: Dann hat der Trockenlaufschutz aus Teil 1 die Pumpe gesperrt.
• wait_template mit vier Stunden Zeitlimit: Schluss ist, wenn der Zielstand erreicht ist oder die Prognose unter 8 mm fällt, spätestens aber nach vier Stunden, falls ein Ventil klemmt oder der Sensor ausfällt. Die Schlussnachricht nennt den Grund selbst, weil wait.completed nur sagt, dass die Bedingung erfüllt wurde, nicht welcher Teil.
• mode: single: Zwei parallele Ablassvorgänge ließen sich nicht mehr sauber stoppen.

Stolperstein: Naheliegend wäre, das Warten zu beenden, sobald das Überlaufrisiko auf off geht. Wegen der Hysterese passiert das aber schon bei Zielstand plus 200 Liter, im Test stoppte die Bewässerung so 85 Liter zu früh. Deshalb prüft das wait_template den Füllstand direkt.

4.4 Notbremse

Eine zweite Automation, unabhängig von der ersten:

alias: Zisterne Ablassen stoppen (Notbremse)
description: >
  Schaltet die Wasserabgabe ab, sobald der Mindestfüllstand unterschritten
  wird oder der Sensor ausfällt. Prüft auch beim Einschalten, damit unter
  dem Mindestfüllstand niemand gießt.
triggers:
  - trigger: numeric_state
    entity_id: sensor.level_sensor_fluid
    below: input_number.zisterne_mindestfullstand
  - trigger: state
    entity_id: sensor.level_sensor_fluid
    to:
      - unavailable
      - unknown
    for:
      minutes: 5
  - trigger: state
    entity_id: switch.bewaesserung
    to: "on"
conditions:
  - condition: state
    entity_id: switch.bewaesserung
    state: "on"
  - condition: or
    conditions:
      - condition: numeric_state
        entity_id: sensor.level_sensor_fluid
        below: input_number.zisterne_mindestfullstand
      - condition: state
        entity_id: sensor.level_sensor_fluid
        state:
          - unavailable
          - unknown
actions:
  - action: switch.turn_off
    target:
      entity_id: switch.bewaesserung
  - action: notify.mobile_app_ihr_smartphone
    data:
      title: "Zisterne: Notbremse"
      message: "Mindestfüllstand erreicht oder Sensor nicht erreichbar, Wasserabgabe gestoppt."
mode: single

Sie greift in drei Fällen: wenn der Füllstand unter den Mindestfüllstand fällt, wenn der Sensor fünf Minuten lang keinen Wert liefert (sonst liefe die Bewässerung bis zum Zeitlimit), und wenn jemand die Bewässerung einschaltet, während die Zisterne schon unter dem Minimum steht. Den dritten Trigger braucht es, weil numeric_state nur im Moment des Unterschreitens feuert. Die Bedingungen prüfen jedes Mal, ob wirklich ein Grund vorliegt, ein normales Einschalten bleibt unberührt.

Stolperstein: Die Notbremse greift auch, wenn Sie dasselbe Ventil von Hand oder über eine andere Bewässerungs-Automation einschalten. Das ist beabsichtigt, unter dem Mindestfüllstand soll niemand gießen.

---

Wechselwirkung mit dem Verbrauchszähler aus Teil 2

Der Verbrauchszähler aus Teil 2 addiert jeden Füllstandsabfall. Ein Ablassvorgang von 1360 Litern taucht dort also als Verbrauch auf und drückt die berechnete Reichweite nach unten.

Für Stufe 2 ist das korrekt, denn das Wasser ist im Garten gelandet. Für Stufe 3 (früh ablassen in Versickerung oder Kanal) verfälscht es die Statistik. Wer das sauber trennen will, kann einen dritten Hilfszähler Zisterne Retention abgegeben anlegen und in der Automation „Zisterne Verbrauch tracken" aus Teil 2 die Bedingung, dass switch.bewaesserung (bzw. die Tauchpumpe) gerade aus ist, ergänzen (nicht Teil dieses Tests). Für den Einstieg reicht es, den Effekt zu kennen.

---

Wenn die Zisterne keinen Überlauf hat

IBC-Container und Regentonnen haben oft keinen geregelten Überlauf. Dort läuft das Wasser bei Vollstand über den Rand oder staut sich im Fallrohr zurück. In diesem Fall ist Stufe 1 (Push-Nachricht) mit deutlich niedrigerer Schwelle sinnvoll. Als Ausgangswert, nicht eigens getestet: regen_mm >= 3 im Binärsensor, Sicherheitsfaktor 1,5 im Zielstand, und die Meldung reicht früh genug, um den Zulauf per Regenrohrklappe umzustellen oder die Tonne von Hand zu leeren. Wer eine Tauchpumpe in der Tonne hat, nutzt Stufe 3 wie beschrieben.

---

Dashboard

Ergänzung für das Zisternen-Dashboard aus Teil 2, als weitere Section:

      - type: grid
        cards:
          - type: heading
            heading: Regenrückhalt
            heading_style: title
          - type: entities
            title: Vor dem Regen
            entities:
              - entity: input_boolean.zisterne_regenruckhalt_aktiv
                name: Regenrückhalt aktiv
              - entity: binary_sensor.zisterne_uberlaufrisiko
                name: Handlungsbedarf
              - entity: sensor.zisterne_regenertrag_48h
                name: Erwarteter Ertrag (48 h)
              - type: attribute
                entity: sensor.zisterne_regenertrag_48h
                attribute: regen_mm_48h
                name: Regen (48 h)
                suffix: " mm"
              - entity: sensor.zisterne_freie_kapazitat
                name: Freie Kapazität
              - entity: sensor.zisterne_zielstand_vor_regen
                name: Zielstand vor Regen
              - entity: input_number.zisterne_volumen
                name: Nennvolumen
              - entity: input_number.zisterne_mindestfullstand
                name: Mindestfüllstand

---

Einlaufphase und Herbst-Effekt

Die Logik ist sofort einsatzbereit, wenn der Ertragsfaktor aus Teil 2 bereits gelernt ist. Wer Teil 2 erst jetzt einrichtet, fährt die ersten Wochen mit dem Platzhalterwert von 30 L/mm und sollte in dieser Zeit bei Stufe 1 bleiben.

Ein Punkt verdient im Herbst besondere Aufmerksamkeit. Der Ertragsfaktor aus Teil 2 ist ein Lebenszeit-Durchschnitt. Laub in der Regenrinne, ein verstopfter Filterkorb oder ein bemoostes Dach senken den realen Ertrag, der gelernte Wert reagiert darauf nur träge. Die Prognose fällt dann zu hoch aus, die Zisterne wird etwas mehr abgesenkt als nötig. Durch den Mindestfüllstand ist das ungefährlich, aber wer merkt, dass die Zisterne nach Regentagen regelmäßig unter dem Ziel bleibt, sollte zuerst die Rinne reinigen und dann den Ertragsfaktor prüfen.

Umgekehrt gilt: Ein sauberer Filter vor dem Herbst ist die einfachste Maßnahme, damit der Regen, für den Sie Platz geschaffen haben, auch tatsächlich ankommt.

---

Anhang: Neue Entitäten auf einen Blick

Helfer:

• input_number.zisterne_volumen: nutzbares Volumen bis zur Überlaufkante
• input_number.zisterne_mindestfullstand: Untergrenze, unter die nie abgelassen wird
• input_boolean.zisterne_regenruckhalt_aktiv: Freigabe für die gesamte Logik

Berechnete Sensoren:

• sensor.zisterne_freie_kapazitat: Volumen minus Füllstand
• sensor.zisterne_regenertrag_48h: erwarteter Regenertrag der nächsten zwei Tage in Litern, Attribut regen_mm_48h
• sensor.zisterne_zielstand_vor_regen: Füllstand, auf den vor dem Regen abgesenkt wird
• binary_sensor.zisterne_uberlaufrisiko: Handlungsbedarf ja/nein, mit Schwelle und Hysterese

Automationen:

• Zisterne Platz schaffen vor Regen: Push, Bewässerung/Pumpe bis Zielstand, Zeitlimit 4 h
• Zisterne Ablassen stoppen (Notbremse): stoppt bei Mindestfüllstand, Sensorausfall oder Einschalten unter dem Minimum