Smart Irrigation waters a garden by the evapotranspiration the day cost

The bucket model: moisture lost, moisture added, what is left

The core idea of this integration is a water balance. It calculates the time to run an irrigation system to compensate for moisture loss by evapotranspiration, so a garden, a lawn or a crop gets watered precisely enough to replace what evaporated. It takes into account precipitation including rain and snow, and adjusts the irrigation time accordingly.

The rule it applies is a simple threshold. If it rains or snows less than the amount of moisture lost, then irrigation is required. If the balance does not go negative, no irrigation is required. The documentation also refers to the accumulated moisture as a bucket, so the mental model is a reservoir that the sun drains and the rain refills.

What makes this more than a timer is that the loss side of the balance is computed rather than assumed. The component can take into account weather forecasts for the coming days, so a wet week ahead reduces what you water today rather than tomorrow's schedule discovering the problem.

Multiple zones are supported, each with its own configuration and set up, which matters because a lawn and a bed of crops do not have the same water demand, and a single schedule across both is how most automated irrigation ends up over or under watering one of them.

Hourly FAO-56, checked against the paper's own example

The evapotranspiration calculation is the technical heart of the component, and the documentation is specific about the method. Evapotranspiration is computed hour by hour from the Penman-Monteith equation, using the FAO-56 formulation, either with or without a radiation sensor, and with forecast days included. The documentation states that the calculation is checked against the paper's own worked example, which is the right thing to do with an equation this fiddly.

The hourly granularity is a departure from the usual daily approach. Most irrigation controllers run a daily reference evapotranspiration and multiply by a crop coefficient. Computing it hour by hour means the peak midday loss is represented rather than averaged away, and it is what makes the component able to say when in the day a zone should run.

The corrections are listed in the release history and they are the sort of thing you only notice if the numbers are wrong. Several corrections were made to the water balance, among them the saturation vapour pressure, which the documentation describes as having made the evapotranspiration too low for everybody, along with rain counters and recurring schedules that never ran. That last one is a reminder that a component doing arithmetic on your behalf can quietly fail to do anything, and the v2026.10.1 release notes list the corrections with the changes in amounts.

Four things can each hold a run back

The skip conditions are the safety net around the calculation, and there are several of them. A rain sensor, frost, wind, a soil moisture sensor per zone and the rain forecast can each hold a run back, and the Info page says which one and on what numbers.

That last detail is what separates a usable component from a black box. A system that silently skips a run leaves you wondering whether it is working. One that names the condition and the measurement tells you whether the sensor is stuck, whether the threshold is set too tight, or whether the weather service is returning something odd.

There is also a mode for the case where the sky above is not the sky that reaches the plant. Under glass, a lux sensor inside answers the question of how much light actually arrives, and without one the glass dims the sun, which is the conservative assumption and is what the component does when no indoor light sensor is present.

The per-zone soil moisture sensor is worth singling out, because it is the only input that measures what the plant has rather than what the weather did. A garden with a cheap moisture probe in one bed and a lawn without one ends up being managed by two different pieces of evidence, which is arguably the correct arrangement but does mean the two zones behave differently.

It can drive the valves itself, or hand you the numbers

There are two ways to use the output, and the component supports both. It can open and close your valves itself, or leave that to your own automations and the blueprints it ships.

The direct control path has real features behind it. There is cycle and soak, which the documentation explains as the same water in several passes so that clay takes it in, a pause between zones, and a watchdog that closes a valve left open. That last one matters more than it sounds: an irrigation valve that fails open floods a bed, and a watchdog is the difference between a leak you find in the morning and a garden that is saturated.

The alternative path is to let the component compute the duration and let your own automation open the valve. For most existing Home Assistant setups that is the lower friction option, since the valve control is usually already in place as a switch.

The blueprint route covers the named commercial controllers. There are controller blueprints for Rain Bird, Hydrawise, Rachio, OpenSprinkler and B-hyve, besides plain valves, ESPHome and Irrigation Unlimited. The presence of ESPHome in that list tells you something about the audience, since an ESPHome valve node is the common way people add a controllable valve to Home Assistant in the first place.

A four-tab panel and a dashboard card, with a standard mode

The configuration UI is the part that decides whether people keep using a component, and this one has been reworked. There is a panel in four tabs, Home, Zones, Data and Settings, built with native Home Assistant components and saving as you type. A new installation starts in the standard mode, with a setup assistant that asks one question at a time and creates the first zone, while the advanced mode opens every setting.

The design choice of a standard and an advanced mode is the interesting one. The alternative, exposing everything at once, is what most integrations do, and it means a new user faces a page of unfamiliar fields before they have configured a single zone. Here the first run is a conversation, and the full surface is still there when you want it.

Soil and crop are chosen by name rather than by a numeric coefficient, which is the difference between a lookup table the component maintains and a field the user has to look up. The per-zone settings that follow from that are days between irrigation, a crop factor by month, and seasonal adjustments edited in the panel.

There is also a dashboard card, served by the integration itself, which answers the questions a user actually has: what each zone is short of, how long it would run, when, and why not, with a button to water on the spot. The why not is the part that makes the card useful when a run does not happen.

Twenty languages, three weather services, and a JSON backup

Three practical details make this usable rather than merely impressive.

The first is translations. There are 20 languages out of the box, and both the panel and the config flow are fully translated: English, French, German, Spanish, Italian, Dutch, Norwegian, Slovak, Slovenian, Polish, Portuguese, Brazilian Portuguese, Czech, Russian, Ukrainian, Simplified Chinese, Swedish, Danish, Finnish and Hungarian. The documentation is candid that everything except English and French was machine-translated, and it invites corrections through Hosted Weblate, in the browser and with no account on GitHub, or directly in the JSON file.

The second is the weather service. You can switch between Open-Meteo, OpenWeatherMap and Pirate Weather, and update the API key, without removing and re-adding the integration. That matters because weather APIs get rate limited, get bought, and occasionally change their terms, and a switch that requires a reconfiguration of every zone is a switch nobody makes.

The third is the backup. There is a one-click Backup and Restore of the entire configuration as a JSON file, which is the right answer for a component where you have spent an afternoon tuning per-zone coefficients, thresholds and schedules.

The start triggers are flexible in the same spirit. They are placed around sunrise, sunset, solar azimuth or a fixed time, with one active at a time, and each firing an identifiable event for your automations, so you can hang your own logic off the moment a run is due.

Installation through HACS, and a fast moving release line

Installation is the easy part, and there is a recommended route. Smart Irrigation is in the HACS default store, so there is no repository to add. In HACS you search for Smart Irrigation and click Download, then restart Home Assistant and add it from Settings, then Devices and Services, then Add Integration, then Smart Irrigation. The manual route is to download the latest release and extract it into custom_components/smart_irrigation/, then restart Home Assistant. The full documentation is at altmenorg.github.io/HAsmartirrigation.

The release line moves fast. The tags are v2026.10.7 from 2026-10-18, v2026.11.0-alpha2 from 2026-10-17, and v2026.10.6 from 2026-10-17, so there is a stable line, an alpha line, and a cadence of more than one release in two days. The last push was on 2026-10-22. The project moved to this repository in June 2026, and the stable v2026.10.2 gathered seven betas and three release candidates, which tells you how the development process runs.

For local development the Makefile creates a virtual environment with Python 3.13 and installs the development dependencies:

	python3.13 -m venv .venv
	./.venv/bin/pip install --upgrade pip
	./.venv/bin/pip install -r requirements-dev.txt

The licence is MIT and the project is not archived. The repository also carries a HACS manifest, a Makefile with setup, test, format, lint and clean targets, a pyproject.toml configuring ruff with pycodestyle, pyflakes, bugbear, isort-style import ordering, pyupgrade and flake8-simplicity selected, and a set of test modules at the top level. Development expects Python 3.13, since the setup target checks for python3.13 and creates a virtual environment from it.

Editorial conclusion

Adopt Smart Irrigation if you already run Home Assistant, have a controllable irrigation setup, and want watering driven by measured moisture loss instead of a fixed timer. Do not adopt it if your system has no way to read rain or soil moisture and no forecast source, since without those inputs the component is a timer with extra steps, and expect the value of it to be concentrated in one zone while you tune it. Before you install, check three things: which weather service you will point it at, since the key can be switched later without removing and re-adding the integration, how your valves are driven, because the controller blueprints cover Rain Bird, Hydrawise, Rachio, OpenSprinkler and B-hyve and plain valves need your own automation, and that you are ready to use the backup and restore JSON, because the configuration is per zone and worth keeping.

Frequently asked questions

Official sources

1. altmenorg/HAsmartirrigation on GitHub
2. License: MIT
3. Project website
4. README
5. Releases