Gardena Micro-Drip in Home Assistant: What It Really Does

Our terrace faces south-east. From mid-morning the sun is on it fully and stays there into the afternoon. In a normal summer that’s why we sit out there. In the summer of 2026 it’s why everything on it died.

The drought was the point where hand watering stopped working. Not because it was too much effort — because it was irregular. Two days away and the pots in the west sun are finished. A pot on a hot terrace does not forgive a forgotten day, and the forgotten day is exactly the one you get. The plants didn’t die from too little water. They died from unreliable water.

So: a Gardena Micro-Drip-System balcony starter set for 15 plants*, a Gardena Water Control as the tap computer, and both of them in Home Assistant.

The honest part of this article isn’t the installation. The installation works. The honest part is how little Home Assistant actually knows about this system — and that I only found out when I sat down to write the automation.

The build: drippers are boring, which is the point

The Micro-Drip set is pleasantly unremarkable. The 1000 base unit goes on the tap — that one is not optional, it drops the mains pressure for the whole system, and without it full pressure blows the push-fittings apart. Behind it the 4.6 mm distribution tubing runs along the terrace as a single line, pinned down with pipe holders, and the inline drippers sit in the pots.

What surprised me, in order of surprise:

• The push-fit connectors really do hold without tools. Cut the tube, push it in, done. I had budgeted for hose clamps and swearing.
• Fifteen drippers is a hard limit. The set is sized for exactly 15 plants: 20 m of distribution tubing, 15 inline drippers. More pots than that on the terrace means buying extras — drippers and tubing separately. Better to count the pots before ordering than after.
• Routing takes longer than the plumbing does — not for technical reasons, but because you want the line laid so it doesn’t look like a building site. Under the pots, behind the bench.
• The base unit is the bottleneck. Too many drippers on one run and the far ones visibly get less. You notice that days later, in the plants, not during the build.

Up to here: a good, dumb piece of hardware. The computer on the tap is the part that needs thinking about.

What Home Assistant actually exposes

The Water Control is in HA via the Gardena Smart System integration. These are the entities that come out of it — all of them, exactly as they stand in my instance on 24 August 2026:

Entity	State
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

The valve entity carries its diagnostics as attributes:

# valve.water_control — attributes, live from 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 simply means open and close. No positioning, no partial opening. A valve is open or shut, which for a garden tap is entirely enough.

The duration entity is the interesting one:

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

One minute up to 1440 minutes — 24 hours straight. Mine sits at 60. That’s the value the valve runs for when it’s opened from HA.

The disappointment: there is no schedule in Home Assistant

Here’s the part I’m actually writing this article for.

I wanted to build an automation: water early in the morning, skip when it rains, run longer in heat. So I went looking in HA for whatever drives the watering schedule — and the answer is: nothing does.

I went through all 15 automations in my instance and read each one’s configuration. Not one of them references valve.water_control, the duration entity, or anything else in the Gardena namespace. The schedule domain in my instance contains zero entities. The schedule that actually waters my terrace does not exist in HA at all — it lives in the Gardena app, on Gardena’s servers, and the integration does not mirror it.

You see the outcome, not the plan. sensor.water_control_watering_end is a timestamp entity that shows the end of a cycle while one is running, then falls back to unknown. Mine reads unknown, last changed at 05:08:58 UTC — the same second the valve flipped to closed. Which means a watering cycle ended this morning at about 07:08 local time. The app triggered it, not me, and HA only saw it once it was over.

I’m labouring this because it’s the point where most guides online quietly cheat: they show a tidy automation calling valve.open_valve and present it as the irrigation control. It isn’t. It’s a remote control, not a schedule. The real schedule lives with Gardena, and HA gets to watch the results.

The services the integration offers are correspondingly thin:

# valve domain — available services
valve.open_valve
valve.close_valve
valve.set_valve_position   # no effect on this device
valve.stop_valve
valve.toggle

That’s enough to water. It is not enough to know when watering happens next.

To be unambiguous about this: as I write, there is no automation running against the Gardena valve in my instance. I am not going to show you YAML below and imply it’s in service here, because it isn’t. The watering runs on Gardena’s own schedule.

For contrast: the valve on the same terrace I do automate

To make the difference concrete — on the same terrace there’s a SONOFF Zigbee valve for the misting line. That’s a local Zigbee device, and all of its logic lives in HA. This automation genuinely runs; here it is unmodified:

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

Fourteen lines, and I know for certain that valve can never run away. I cannot build the same certainty for the Gardena while the schedule lives outside HA — a failsafe would be fighting Gardena’s own cycles rather than backstopping them. The device’s built-in duration cap is the failsafe here, and you have to trust it.

Honest limitations

All of this observed, not copied off a spec sheet:

• It is a cloud integration, with no way around it. The Water Control talks to the Gardena gateway, the gateway talks to Gardena’s servers, and HA talks to those same servers over an authenticated WebSocket. No internet, no control from HA. Why a garden tap needs a cloud, nobody has managed to explain to me to this day. For a device whose entire job is to run reliably in summer, that’s the most uncomfortable property in the chain.
• There is an API quota, and you can watch it. The integration keeps count: 60 requests this week, 13 today, against a weekly quota of 700. Broken down that’s 53 WebSocket connection setups, 5 OAuth tokens and 2 locations calls. The WebSocket is re-established roughly every two hours — that’s Gardena’s design, not a fault. Poll hard, or attach several HA instances, and you will meet that limit. A weekly quota. For a garden tap.
• You get the battery level, not the battery verdict. battery_level reads a clean 86%. battery_state reads UNKNOWN — the field exists, it’s just empty. You get a number, but no statement from the device about whether it considers that number healthy. I commissioned the system in spring; 86% in August isn’t enough to extrapolate a season from, and I’m not going to pretend otherwise.
• The radio link is unremarkable. rf_link_level: 100, rf_link_state: ONLINE. The tap is within sight of the gateway. So I have nothing useful to tell you about range — it was never a question here.
• Devices that go offline don’t disappear, they go unavailable. The same integration carries a valve.pressure_pump that has read unavailable since 20 August, along with its own duration and sensor entities. Same for the mower entities. So any automation pointing at one of these has to cope with unavailable — for cloud devices that’s the normal state, not the exception.
• No flow, no liters. The Water Control reports open/closed and duration. How much water actually went through, nobody knows. For drip irrigation time is a workable proxy, but it stays an estimate.

What I’d tune

• Answer the “one schedule or two” question first. Either you leave the schedule entirely in the Gardena app and use HA only to watch and to intervene by hand — or you delete the app schedule and rebuild it in HA on valve.open_valve plus the duration entity. Both are defensible. Both at once is how you water twice. I’m currently on option one.
• The 60 minutes is my number, not yours. It follows from the number of drippers and the pot sizes. Mine sits at 60 because a lot of drippers hang off one pressure-reduced run and deliver slowly as a result.
• Rain skip would be the first real win. That is precisely what the system cannot do by itself: the Gardena schedule waters happily through rain. An HA automation that suppresses the cycle when it’s raining would be the first good reason to actually move the schedule into HA. I haven’t built it, and I’m deliberately writing it here as an intention rather than as instructions.
• Alert on unavailable, not on battery level. The dangerous case isn’t a dead battery, it’s a dead connection at 30 °C: the valve is shut, the app reports nothing dramatic, and the terrace dries out. binary_sensor.water_control_online is the entity a warning belongs on.

Where I landed

The Micro-Drip system did what I bought it for: the terrace survived the drought summer, and it survived because the water now arrives every day instead of whenever I remember. As a piece of garden equipment: unreserved recommendation.

As a smart home device it’s the weakest link in my setup, and that’s not a complaint about the valve — it’s about the architecture behind it. It depends on a vendor cloud, it has a weekly quota, and the schedule, the one thing that actually matters in irrigation, is invisible from Home Assistant. By contrast I have fourteen lines of YAML that let me guarantee the Zigbee valve two meters away can never run away. For the Gardena I can’t guarantee that. I can only trust it.

I can live with that, as long as I know that’s the deal. Which is why it’s written down here.