What the dashboard adds, and what it doesn’t
Home Assistant doesn’t water: it runs the decision you defined. Its value is in three things a garden timer doesn’t do: store the history, warn you when something goes wrong, and let you change the criterion without dismantling anything.
The hard part isn’t the automation, it’s the rule. A dashboard can have the prettiest entities in the world and still overwater if the threshold is wrong.
If you don’t have the dashboard set up yet, the step-by-step Home Assistant installation is the starting point.
The basic rule: threshold and hysteresis
The classic mistake is “water when moisture drops below 40 %”. With that threshold the pump switches on when it reaches 40, waters, the reading climbs to 45 and drops back to 40 shortly after: the pump switches on and off constantly and the plant only gets sips.
The solution is hysteresis: two different thresholds.
- Start watering when the reading drops below the start threshold.
- Stop watering when the reading rises above the stop threshold.
With that, the cycle is long and the plant gets water every time instead of in bursts. In Home Assistant that means two automations, because a single one can’t react to both directions of the reading:
automation:
- alias: "Riego por humedad - arranque"
triggers:
- trigger: numeric_state
entity_id: sensor.humedad_suelo
below: 38
for: "00:10:00"
conditions:
- condition: state
entity_id: input_boolean.riego_habilitado
state: "on"
actions:
- action: switch.turn_on
target:
entity_id: switch.bomba_riego
- action: timer.start
target:
entity_id: timer.parada_riego
- alias: "Riego por humedad - parada por histéresis"
triggers:
- trigger: numeric_state
entity_id: sensor.humedad_suelo
above: 45
actions:
- action: switch.turn_off
target:
entity_id: switch.bomba_riego
- alias: "Tope de tiempo de seguridad"
triggers:
- trigger: event
event_type: timer.finished
event_data:
entity_id: timer.parada_riego
actions:
- action: switch.turn_off
target:
entity_id: switch.bomba_riego
Before this you need two supporting entities: an input_boolean
(input_boolean.riego_habilitado) so you can switch irrigation off, and a
timer (timer.parada_riego) set to five minutes. The timer is what switches
the pump off even if the sensor never reaches the stop threshold.
The numbers in the example are only a starting point: yours come from the two-point calibration.
The syntax for numeric and state triggers is in the Home Assistant automation documentation, and ESPHome entities are created with the corresponding integration.
The safety timer, mandatory
Every irrigation automation needs an independent time limit. If the pump doesn’t stop because the sensor is stuck or because the automation hung halfway, that timer is the only thing preventing a flood.
- A second timer that switches the pump off after five minutes, whatever the sensor says.
- An “irrigation in progress” entity that resets every time a cycle starts.
- A history record of how long each watering lasted: if one day lasts four minutes and another forty, something in the system has changed.
The electronics side of this is solved in the ESPHome irrigation project, including the rule that the plant must not depend on the dashboard being open.
What to do when the sensor fails
This is the scenario almost nobody designs, and the one that kills the most plants. If the sensor disconnects, the value may stay at the last reading, may turn unknown, or may report absurd values. All three options are bad if you haven’t decided what to do:
| Situation | Sensible behaviour |
|---|---|
| Stale reading (unchanged for an hour) | Don’t water and warn |
| Impossible reading (0 or a fixed 100 %) | Don’t water and warn |
| Sensor unknown | Don’t water and warn |
| Battery or connection down | Warn, but keep the schedule |
The fourth row is what stops a network problem from becoming a catastrophe: if the sensor fails but the time information is still valid, you can water on a schedule and warn yourself about the failure.
Scheduled watering as a safety net
The most robust combination is to have both rules active, with the second one acting only if the first hasn’t watered:
- Moisture-based watering, with hysteresis and reading validation.
- Scheduled watering every two or three days, skipped if moisture is above a threshold or if it has rained.
That way the system doesn’t depend on a single variable, and the schedule also gives you a reference to compare: if moisture watering fires every day and the schedule never does, your threshold is wrong.
Alerts worth having
Not every notification is useful. These are the ones that really warn of a problem:
- Pump active for more than N seconds. Configuration error or leak.
- Sensor with no readings. Cable, battery or probe.
- Reading that jumps suddenly. Noise or poor contact.
- No watering for X days although moisture is low. Blocked pump or closed valve.
- Abnormal power consumption by the pump, if you measure it.
All of this is easier to see in a history chart than in a single number. That’s why history is the dashboard’s real advantage over a timer.
Getting started without complications
- Install a single soil sensor and publish its reading.
- Let it log for a week without automating anything.
- Look at the chart and choose the thresholds from data, not from memory.
- Enable the automation with hysteresis and the safety timer.
- Add the rain sensor so you can skip watering when it’s needed.
- Only then, if the system is stable, does it make sense to consider solar irrigation or a full project such as the balcony vegetable garden.
Sources and next step
The Home Assistant automation documentation covers state and numeric triggers, and the ESPHome integration explains how sensors are added. For guidance on when to water according to the plant, see the water needs guide.
External sources
- Home Assistant: automation documentation — numeric triggers, conditions and timers.
- Home Assistant: ESPHome integration — how sensors and entities appear in the dashboard.