OpenPlantbook for Home Assistant: plant data, sensor uploads and three actions

A data backend for plant care, not a plant monitor

The integration connects Home Assistant to the OpenPlantbook API for searching plant species, fetching care data and uploading sensor readings. The README is explicit about its role in a larger setup: it is used as the data backend for the Plant Monitor integration, and to set up plant monitoring and tracking of your plant related sensors you need to install that integration too.

That division of labour is the main thing to understand before installing anything. This component does not read your sensors. It talks to a public plant database and, optionally, forwards readings that the other integration collects. If you install it on its own, you get search and care data in Home Assistant, and the sensor upload options do nothing useful because there is no sensor data to send.

The audience is therefore a home automation user with plants and a soil sensor, who wants the plant database available in Home Assistant and, optionally, wants their readings to contribute to a community dataset.

The technology choices are ordinary for a Home Assistant custom component. It is a Python integration, distributed through HACS as a custom repository of type Integration, with a manual installation path for people who do not use HACS. The licence is GPL-3.0, and the repository carries a hacs.json, an info.md for the HACS listing and a custom_components directory that holds the integration itself.

Installing it, and what setup actually asks for

There are two installation routes. Via HACS, which the README marks as recommended, you add the repository as a Custom Repository of type Integration, click Download on the OpenPlantbook card, and restart Home Assistant. Manually, you copy the custom_components/openplantbook/ directory into your own config directory's custom_components folder and restart Home Assistant.

Setup then needs an OpenPlantbook account, which is free, plus API credentials. You register at open.plantbook.io, and you find your client_id and secret on the API key page. In Home Assistant you go to Settings, then Devices and Services, then Add Integration, then OpenPlantbook, and you enter the credentials. The integration validates them and shows an error if they are incorrect, which is the point of doing it in the wizard rather than writing them into YAML.

After that, the Configure button on the integration card opens the additional options, and the README marks the upload settings as optional but recommended.

The credentials question deserves one more sentence. The integration holds a client_id and a secret for a third party service, and it uses them to fetch plant data and, if you enable it, to post readings. That is a small amount of trust placed in a community integration, and it is the reason the project ships a privacy policy for govulncheck-style scrutiny elsewhere in the ecosystem: a Home Assistant user is granting a third party component standing access to their API account. The integration itself is transparent about what it sends, which is the part that matters here, and the sharing options are opt-in rather than on by default.

What gets shared: sensor data, location and language

Three options determine what leaves your machine, and all three are opt-in.

The first is sensor data upload. When enabled, the integration periodically uploads sensor data from your plants to OpenPlantbook, once a day, and the README notes that all data is shared anonymously and that the purpose is to help build a useful community dataset. The mechanics are worth knowing. The first upload covers the last 24 hours of data, if sensors are disconnected it retries daily for up to 7 days of historical data, and the daily upload is scheduled at a randomised time of day per installation, stable for a given configuration entry, to even out the load. The upload can also be triggered by hand.

The second is location sharing, at two levels. You can share only the country from your Home Assistant configuration, or the full latitude and longitude. Location is configured in Home Assistant under Settings, System, General, and the README suggests enabling debug logging for the integration to see exactly what is being shared, which is the right advice for a feature that transmits coordinates.

The third is international common names. When enabled, the integration sends your Home Assistant interface language to OpenPlantbook so the API can return common names in that language where they exist.

None of these are on by default, and the randomised upload time is a small design decision that tells you something about the project. Spreading community uploads across the day rather than having every installation fire at midnight is the difference between a dataset that is pleasant to maintain and one that is not.

Three actions, and a search that returns forty species

The integration exposes three service calls, and they are the interface you will actually use in automations.

The search action takes a string and puts the results in a state you can read. The action itself is one line of YAML:

action: openplantbook.search
data:
  alias: Capsicum

and the result is read from the openplantbook.search_result entity. A Jinja template walks the attributes to list what came back:

Number of plants found: {{ states('openplantbook.search_result') }}
{%- for pid in states.openplantbook.search_result.attributes %}
  {%- set name = state_attr('openplantbook.search_result', pid) %}
  * {{ pid }} -> {{ name }}
{%- endfor %}

The get action returns the detailed record for one species, and the species string has to match exactly the pid that the search returned, which is a small trap for anyone scripting it by hand:

action: openplantbook.get
data:
  species: capsicum annuum

The get action also takes an optional include parameter, currently supporting care, which adds watering, sunlight, soil, pruning and fertilization to the record. The cached entries remember which categories they already contain, so asking for care for a plant fetched earlier without it triggers a fresh API call rather than returning a partial record.

The upload action manually triggers uploading of plant sensor data, and the README says it returns null if nothing was uploaded, which is the result you get when the option is off or there is no sensor data.

Entity attributes, image caching and the www path rule

The care data ends up as entity attributes, which is how a Home Assistant user would consume it in a dashboard:

* Watering: {{ state_attr('openplantbook.monstera_deliciosa', 'watering') }}
* Sunlight: {{ state_attr('openplantbook.monstera_deliciosa', 'sunlight') }}
* Soil: {{ state_attr('openplantbook.monstera_deliciosa', 'soil') }}
* Pruning: {{ state_attr('openplantbook.monstera_deliciosa', 'pruning') }}
* Fertilization: {{ state_attr('openplantbook.monstera_deliciosa', 'fertilization') }}

A plant entity also carries the moisture and temperature ranges the species expects, as max and min soil moisture and max temperature, plus an image_url attribute.

That image URL is where the last configuration option comes in. The integration can download plant images automatically, and the default path is /config/www/images/plants, though you can specify any directory the Home Assistant user can write to, with relative paths resolved against the config directory. The path behaviour has a rule that is easy to miss: if the path contains www/, the image_url is replaced with a /local/ reference, and if it does not contain www/, the full OpenPlantbook URL is kept. That is the difference between serving the image from your own instance and linking to the upstream one.

Two constraints are stated. Existing files are never overwritten, and the target directory must exist before you configure it, which is a small operational note that will save you a silent failure.

A beta cadence and a codebase that follows Home Assistant lint rules

The release history shows a project in beta. The tags are v1.7.0-beta1 from 2026-08-05, v1.6.0 from 2026-06-15 and v1.6.0-beta1 from 2026-06-09, and the last push to the repository was on 2026-10-07.

The beta tags are not unusual for a Home Assistant custom integration, since HACS itself distributes most integrations in that state, and the project uses the HACS Custom badge.

What is notable is how closely the project tracks Home Assistant core. The ruff configuration in the project metadata targets Python 3.12 with a line length of 88, and the comment explains that the rule groups are aligned with the ones Home Assistant core enforces, including the pyupgrade, bugbear, comprehensions, simplify, return, async, pathlib, logging and tryceratops groups. The Home Assistant specific pylint plugins for type hints, layout and translation checks live in the core repository and are not usable here, so the configuration is described as the portable equivalent.

That is a level of rigour worth noting for a component that runs inside people's homes, and it explains the isort setting that marks custom_components.openplantbook as first party. The per-file ignores are equally considered, allowing imports not at the top of a test file and letting the CLI helper scripts print to stdout by design.

The repository also holds a TODO.txt, a CONTRIBUTING.md, a docs directory, an examples directory with a GUI example, a scripts directory, a pytest.ini and a requirements.test.txt, so the test and lint setup is part of the project rather than an afterthought.

Editorial conclusion

Adopt the OpenPlantbook integration if you want plant care data in Home Assistant and you already have, or plan to add, soil moisture sensors, since the sensor upload path only makes sense with a Plant Monitor integration feeding it. Do not adopt it if you only wanted a static list of plant care data, since that is what the API itself provides, and read the privacy options carefully before enabling uploads, because the integration can share anonymous sensor readings, your country or your exact coordinates. Verify first which SDK version your Home Assistant core expects, since the repository tracks Home Assistant lint rules closely, that your account credentials validate, and whether the daily upload schedule that the integration randomises per installation is acceptable in your setup.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Olen/home-assistant-openplantbook on GitHub
4. README
5. Releases