Gardena Micro-Drip in Home Assistant: was die Integration kann

Unsere Terrasse zeigt nach Südosten. Ab dem Vormittag steht die Sonne voll drauf und bleibt bis in den Nachmittag. In einem normalen Sommer ist das der Grund, warum wir dort sitzen. Im Sommer 2026 war es der Grund, warum dort alles gestorben ist.

Die Dürre war der Punkt, an dem Gießen von Hand aufgehört hat zu funktionieren. Nicht, weil es zu viel Arbeit war — sondern weil es unregelmäßig war. Zwei Tage weg, und die Töpfe in der prallen Sonne sind durch. Ein Topf auf einer heißen Terrasse verzeiht keinen vergessenen Tag, und genau die vergisst man. Die Pflanzen sind nicht an zu wenig Wasser eingegangen, sondern an zu unzuverlässigem.

Also: Gardena Micro-Drip-System Start-Set Balkon für 15 Pflanzen*, dazu ein Gardena Water Control als Wasserhahn-Computer, und beides in Home Assistant.

Der ehrliche Teil dieses Artikels ist nicht der Aufbau. Der Aufbau funktioniert. Der ehrliche Teil ist, wie wenig Home Assistant über diese Anlage tatsächlich weiß — und dass ich das erst gemerkt habe, als ich die Automation schreiben wollte.

Der Aufbau: Tropfer sind langweilig, und das ist gut so

Das Micro-Drip-Set ist erfreulich unspektakulär. Das Basisgerät 1000 kommt an den Hahn — das ist nicht optional, es reduziert den Leitungsdruck für die ganze Anlage, und ohne es drückt der volle Druck die Steckverbindungen auseinander. Dahinter läuft das 4,6-mm-Verteilerrohr als Strang entlang der Terrasse, mit Rohrhaltern fixiert, und in den Töpfen sitzen die Reihentropfer.

Was mich überrascht hat, in der Reihenfolge der Überraschung:

• Die Steckverbindungen halten wirklich ohne Werkzeug. Rohr abschneiden, reindrücken, fertig. Ich hatte mit Schlauchschellen und Frust gerechnet.
• Fünfzehn Tropfer sind eine harte Grenze. Das Set ist auf genau 15 Pflanzen ausgelegt: 20 m Verteilerrohr, 15 Reihentropfer. Wer mehr Töpfe auf der Terrasse stehen hat, kauft nach — Tropfer und Rohr einzeln. Das rechnet man besser vorher durch als hinterher.
• Verlegen dauert länger als gedacht — nicht wegen der Technik, sondern weil man die Leitung so legen will, dass sie nicht wie eine Baustelle aussieht. Unter den Töpfen durch, hinter der Bank entlang.
• Das Basisgerät ist der Flaschenhals. Zu viele Tropfer an einem Strang, und die hinteren bekommen sichtbar weniger. Das merkt man erst nach ein paar Tagen an den Pflanzen, nicht beim Aufbau.

Bis hierher: ein gutes, dummes Stück Hardware. Der Computer am Hahn ist der Teil, über den man nachdenken muss.

Was Home Assistant tatsächlich anzeigt

Der Water Control hängt über die Gardena-Smart-System-Integration in HA. Das sind die Entitäten, die dabei herauskommen — vollständig, so wie sie am 24. August 2026 in meiner Instanz stehen:

Entität	Zustand
valve.water_control	closed
number.water_control_water_control_watering_duration	60.0 min
sensor.water_control_battery_level	86 %
sensor.water_control_rf_link_quality	100 %
sensor.water_control_watering_end	unknown
binary_sensor.water_control_online	on
binary_sensor.websocket_status_gardena_websocket_connected	on
sensor.websocket_status_api_requests_week	60

Die Ventil-Entität trägt ihre Diagnose als Attribute mit:

# valve.water_control — Attribute, live aus HA
is_closed: true
battery_level: 86
battery_state: UNKNOWN
rf_link_level: 100
rf_link_state: ONLINE
service_id: 2846a39f-6c80-4bf7-8a47-412ab07b637d
supported_features: 3

supported_features: 3 heißt schlicht: öffnen und schließen. Keine Positionierung, kein Teil-Auf. Ein Ventil hat auf und zu, was für einen Wasserhahn auch völlig ausreicht.

Die Dauer-Entität ist die interessanteste im Bunde:

# number.water_control_water_control_watering_duration
state: 60.0
min: 1
max: 1440
step: 1
mode: box
unit_of_measurement: min

Eine Minute bis 1440 Minuten, also bis zu 24 Stunden am Stück. Meiner steht auf 60. Das ist der Wert, mit dem das Ventil läuft, wenn es über HA geöffnet wird.

Die Ernüchterung: es gibt keinen Zeitplan in Home Assistant

Hier ist der Teil, für den ich diesen Artikel eigentlich schreibe.

Ich wollte eine Automation bauen: früh morgens gießen, bei Regen aussetzen, bei Hitze länger. Also habe ich in HA nachgesehen, was den Bewässerungszeitplan steuert — und die Antwort ist: nichts.

Ich habe alle 15 Automationen in meiner Instanz durchgesehen und ihre Konfiguration einzeln ausgelesen. Keine einzige davon referenziert valve.water_control, die Dauer-Entität oder irgendetwas anderes aus dem Gardena-Namensraum. Die Domain schedule in meiner Instanz enthält null Entitäten. Der Zeitplan, nach dem meine Terrasse tatsächlich bewässert wird, existiert in HA schlicht nicht — er lebt in der Gardena-App, auf Gardenas Servern, und die Integration spiegelt ihn nicht.

Man sieht das Ergebnis, nicht den Plan. sensor.water_control_watering_end ist eine Zeitstempel-Entität, die während eines laufenden Zyklus das Ende anzeigt und danach auf unknown zurückfällt. Bei mir steht sie auf unknown, zuletzt geändert um 05:08:58 UTC — dieselbe Sekunde, in der auch das Ventil auf closed gewechselt hat. Das heißt: heute früh, gegen 07:08 Uhr unserer Zeit, hat ein Bewässerungszyklus geendet. Den hat die App ausgelöst, nicht ich, und HA hat ihn erst gesehen, als er vorbei war.

Ich betone das, weil es der Punkt ist, an dem die meisten Anleitungen im Netz schummeln: Sie zeigen eine hübsche Automation mit valve.open_valve und tun so, als wäre das die Bewässerungssteuerung. Ist es nicht. Es ist eine Fernbedienung, kein Zeitplan. Der echte Zeitplan liegt bei Gardena, und HA darf beim Ergebnis zuschauen.

Was die Integration an Diensten anbietet, ist entsprechend knapp:

# Domain valve — verfügbare Dienste
valve.open_valve
valve.close_valve
valve.set_valve_position   # bei diesem Gerät ohne Funktion
valve.stop_valve
valve.toggle

Das reicht, um zu gießen. Es reicht nicht, um zu wissen, wann als Nächstes gegossen wird.

Wichtig, damit hier nichts falsch stehen bleibt: Zum Zeitpunkt, an dem ich das schreibe, läuft in meiner Instanz keine Automation auf dem Gardena- Ventil. Ich zeige unten keine YAML, die bei mir angeblich im Einsatz ist, weil es sie nicht gibt. Die Bewässerung läuft über Gardenas eigenen Zeitplan.

Zum Vergleich: das Ventil auf derselben Terrasse, das ich wirklich automatisiere

Damit klar wird, worin der Unterschied besteht — auf derselben Terrasse hängt ein SONOFF-Zigbee-Ventil für die Sprühnebel-Kühlung. Das ist ein lokales Zigbee-Gerät, und dort liegt die gesamte Logik in HA. Diese Automation läuft tatsächlich, hier ist sie unverändert:

alias: "Atomizer failsafe - close water valve if open too long"
description: >-
  Safety net for the garden atomizer. The misting automation opens the valve
  for 2 minutes at a time, so the valve should never be open for 5 minutes
  straight. If it is (HA restarted mid-cycle, manual toggle, stuck
  automation), force it closed to prevent flooding and water waste.
triggers:
  - trigger: state
    entity_id: switch.garden_sonoff_water_valve
    to: "on"
    for:
      minutes: 5
actions:
  - action: switch.turn_off
    target:
      entity_id: switch.garden_sonoff_water_valve
mode: single

Vierzehn Zeilen, und ich weiß mit Sicherheit, dass dieses Ventil nie durchlaufen kann. Für den Gardena kann ich dieselbe Sicherheit nicht bauen, solange der Zeitplan außerhalb von HA liegt — die Absicherung würde gegen Gardenas eigene Zyklen kämpfen, statt sie abzusichern. Der eingebaute Dauer-Deckel im Gerät ist hier die Absicherung, und man muss ihm vertrauen.

Ehrliche Grenzen

Alles hier beobachtet, nicht aus dem Datenblatt abgeschrieben:

• Es ist eine Cloud-Integration, ohne Ausweg. Der Water Control funkt zum Gardena-Gateway, das Gateway zu Gardenas Servern, und HA spricht über eine authentifizierte WebSocket-Verbindung mit ebendiesen Servern. Kein Internet, keine Steuerung aus HA. Warum ein Wasserhahn eine Cloud braucht, kann mir bis heute niemand erklären. Für ein Gerät, dessen einziger Zweck ist, im Sommer zuverlässig zu laufen, ist das die unangenehmste Eigenschaft der ganzen Kette.
• Es gibt ein API-Kontingent, und man sieht es. Die Integration führt Buch: 60 Anfragen diese Woche, 13 heute, bei einem Wochenkontingent von 700. Aufgeschlüsselt sind das 53 WebSocket-Verbindungsaufbauten, 5 OAuth-Token und 2 Locations-Abfragen. Die WebSocket-Verbindung wird etwa alle zwei Stunden neu aufgebaut — das ist Gardenas Vorgabe, nicht ein Fehler. Wer viel pollt oder mehrere HA-Instanzen anhängt, läuft in dieses Limit. Ein Wochenkontingent. Für einen Wasserhahn.
• Der Batteriestand kommt, die Batterie-Bewertung nicht. battery_level steht sauber auf 86 %. battery_state steht auf UNKNOWN — das Feld gibt es, es ist nur leer. Man bekommt eine Zahl, aber keine Aussage des Geräts darüber, ob es die Zahl für gut hält. Ich habe die Anlage im Frühjahr in Betrieb genommen; von 86 % im August lässt sich noch keine Saisonprognose ableiten, und ich behaupte das auch nicht.
• Die Funkstrecke ist unauffällig. rf_link_level: 100, rf_link_state: ONLINE. Der Hahn liegt in Sichtweite des Gateways. Über Reichweite kann ich deshalb nichts Nützliches sagen — bei mir war sie nie ein Thema.
• Geräte, die offline gehen, verschwinden nicht, sie werden unavailable. In derselben Integration hängt eine valve.pressure_pump, die bei mir seit dem 20. August auf unavailable steht, samt ihrer eigenen Dauer- und Sensor-Entitäten. Ebenso die Mäher-Entitäten. Wenn also eine Automation auf eine dieser Entitäten zeigt, muss sie mit unavailable umgehen können — das ist bei Cloud-Geräten der Normalzustand, nicht die Ausnahme.
• Kein Durchfluss, keine Liter. Der Water Control meldet auf/zu und Dauer. Wie viel Wasser tatsächlich durchgelaufen ist, weiß niemand. Für Tropfbewässerung ist Zeit ein brauchbarer Näherungswert, aber es bleibt eine Schätzung.

Was ich anpassen würde

• Die Frage „ein oder zwei Zeitpläne” zuerst beantworten. Entweder man lässt den Zeitplan komplett in der Gardena-App und benutzt HA nur zum Zuschauen und für manuelle Eingriffe — oder man löscht den App-Zeitplan und baut alles in HA über valve.open_valve plus Dauer-Entität nach. Beides ist vertretbar. Beides gleichzeitig ist der Weg in doppeltes Gießen. Ich bin aktuell bei Variante eins.
• Die 60 Minuten sind meine Zahl, nicht deine. Sie hängt an der Anzahl der Tropfer und an der Topfgröße. Bei mir läuft es auf 60, weil viele Tropfer an einem druckreduzierten Strang hängen und entsprechend langsam abgeben.
• Regen-Aussetzer wäre der erste echte Gewinn. Genau das kann die Anlage von sich aus nicht: Der Gardena-Zeitplan gießt bei Regen fröhlich weiter. Ein HA-Automatismus, der bei Regen den Zyklus unterdrückt, wäre der erste Grund, den Zeitplan tatsächlich nach HA zu holen. Ich habe es noch nicht gebaut, und ich schreibe es hier bewusst als Vorhaben und nicht als Anleitung hin.
• Auf unavailable alarmieren, nicht auf den Batteriestand. Der gefährlichere Fall ist nicht die leere Batterie, sondern die tote Verbindung bei 30 °C: Das Ventil ist zu, die App meldet nichts Dramatisches, und die Terrasse trocknet aus. binary_sensor.water_control_online ist die Entität, auf die eine Warnung gehört.

Wo ich gelandet bin

Das Micro-Drip-System hat getan, wofür ich es gekauft habe: Die Terrasse hat den Dürresommer überlebt, und zwar deshalb, weil das Wasser jetzt jeden Tag kommt und nicht dann, wenn ich daran denke. Als Gartengerät: uneingeschränkte Empfehlung.

Als Smart-Home-Gerät ist es das schwächste Glied in meinem Aufbau, und das ist kein Vorwurf an das Ventil, sondern an die Architektur dahinter. Es hängt an einer Hersteller-Cloud, es hat ein Wochenkontingent, und der Zeitplan — das einzige, was bei einer Bewässerung wirklich zählt — ist von Home Assistant aus nicht sichtbar. Ich habe im Vergleich vierzehn Zeilen YAML, mit denen ich für das Zigbee-Ventil zwei Meter weiter garantieren kann, dass es nie durchläuft. Für den Gardena kann ich das nicht garantieren, ich kann ihm nur vertrauen.

Damit kann ich leben, solange ich weiß, dass es so ist. Deshalb steht es hier.