Cloud Plant DB with API for PlantCard

Share your Projects!
1

Hi All,

I’m working on a cloud Plants Database with API. The database consists of optimal environment thresholds from open sources and plants' thresholds Plantbook users have added. It can be used with Xiaomi MiFlora plant sensor or any other sensor. It is also useful for different irrigation projects.

logo
logo767×271 31 KB

This is FREE service and it will always be free! Anyone can use information from the database for any purpose without permission.

It is intended to be community sourced and I see it as a GitHub for plant care recipes.

The purpose is to help the community with collecting and storing STRUCTURED information about plants care and potentially plants in general.

The service is live so you can login https://open.plantbook.io, get API credentials and start using that. BTW, there is a social Single Sign On so you don’t even have to register.

The documentation is within Web UI and in GitHub.

Discord chat link if you have suggestions, questions or need support.

Roadmap:

  • Ability to specify alternative thresholds for different seasons of the year (summer, winter, etc.) In Progress
  • Expert advice service on plants health
  • Plant and decease detection from images
  • Allow to search users' plant (user-plants) via API
  • Ability to upload plants' pictures in UI. DONE.
  • Ability to add and see multiple common names of the plants including in different national languages. DONE
  • Ability to add, modify and see general information about plants in UI and via API DONE

Any thoughts and feedback will be much appreciated. I’m open to new features requests and your ideas!

HASS integration

Plant component and corresponding forum topic.
HASS OpenPlantbook integration
lovelace-flower-card for UI

The latest releases of Plantbook-cloud:

release 202605-22 (22 May 2026)

Milestone: Open Plantbook now provides general plant care information! This marks a significant step beyond environmental thresholds — the platform now covers how to actually care for your plants.

  • New feature: Editable Care information — sunlight, watering, fertilization, pruning, and soil fields can now be filled in when creating or editing user-plants. Each field includes a tooltip with guidance and a live character counter.

release 202605-18 (18 May 2026)

  • New feature: Care information section on plant details pages — care guidance (sunlight, watering, fertilization, pruning, soil) is now displayed with icons and tooltips below the Environment thresholds card.

release 202605-02 (2 May 2026)

  • Enhancement: Expose PlantCreation endpoint via Browsable API, which allows creation of new plants via UI using JSON payload. See Browsable API at Docs page.

Full release notes and documentation: GitHub - slaxor505/OpenPlantbook-client: Open Plantbook clients and UI · GitHub

2

Great!
I was thinking of creating something similar!
I think this should be integrated in the “plants”-integration not just the plant-card.

The plant integration should then also be extended with a few more fields, such as name, spieces and image.

It means that you can just configure:

plant:
  kitchen_window:
    spieces: unique_name_from_plantbook
    name: Plant in the kitchen window
    sensors:
      moisture: sensor.my_sensor_moisture
      battery: sensor.my_sensor_battery
      temperature: sensor.my_sensor_temperature
      conductivity: sensor.my_sensor_conductivity
      brightness: sensor.my_sensor_brightness

And all the other fields

    min_moisture: 
    max_moisture: 
    min_conductivity: 
    max_conductivity: 
    min_temperature: 
    max_temperature: 
    image:

Are populated from the plantbook.

By doing that, all the different plant-cards can take advantage of the info, and read it from the plant entity instead of the external source.
Of course, you should be able to add any of these manually to the plant config, and only have plantbook overwrite empty fields if you want to use your own image, or adjust some values yourself.

3

Hi Olen,

Thanks - it’s very encouraging! You are always welcome to join forces :slight_smile:

In terms of “plant integration”, do you mean Plant Monitor component? If so then yeah I completely agree. While improving plant-card seems much easier but I doubt that it will work well as we need to store API data and not query it every time when PlantCard is being rendered. I’m learning HASS architecture now and how to develop for HASS in general (no experience so far unfortunately but I’m getting there). Next step is to make this integration happen :slight_smile:

4

Hi, I’ll see if I am able to help out here.

Yes, I mean the Plant Monitor component/integration.
The main code is here: https://github.com/home-assistant/core/blob/4d6e694d1488634439420411867a6d717d41587b/homeassistant/components/plant/init.py and it should not be too hard to add a function that calls the API to fetch the values for max/min on init of a new Plant.

However, the API should ofcourse be stable first, and you need a way to uniquely identlify the plant you are configuring. I have not looked extensively at the data, but is the “pid” in your data always unique?
If so, you could just use that as an index directly, so instead of first doing a search for the alias, and then a lookup of the id, why not allow you to do a lookup of the pid?
E.g.
https://open.plantbook.io/api/v1/plant/detail/acer%20sieboldianum
instead of only
https://open.plantbook.io/api/v1/plant/detail/68

That way, you don’t really need to care about the id anyway.

Also, I think it would be a great idea to add localized names of plants to the api. A simple table with locale, plant_id (or pid) and local name would make searching for and displaying plant info much nicer.
Some plants might have more than one local name though, so it makes sense to not limit it to one entry per locale, but maybe add some kind of “score” or “value” to each name to be used in ordering, or telling what the official (or most common) name is.

locale | pid  | local name            | score |
-------+------+-----------------------+-------+
en_US  | 123  | Common Name           |   100 |
en_US  | 123  | Less Common Name      |    75 |
en_US  | 123  | Old Name Nobody Uses  |     5 |

You get the point…

This way, when you search for a plant, you can get a hit for any of the names, and when you display a plant in a front end, you can highlight the most common name, and choose to show some or all of the others if you have space.
For the HA integration, you should probably only include the most common name, and let the user override it in customizations if they want to use another name in their installation.

5

@Olen

oh… wow! that’s excellent ideas. I like your suggestion to include pid into endpoint path (I think it can be useful in future for search indexing as well):

https://open.plantbook.io/api/v1/plant/detail/acer%20sieboldianum

Also localized names are essentials - I agree. I like the names rating/score feature as well.

I’m definitely taking those onboard and putting them onto roadmap. Lemme work through this I will be back with updates soon.

6

Version 1.0 has been released. It includes “pid” lookup suggested by @Olen. I’m planning to implement suggestions in next version where I will be working on editing/browsing plants’ in UI.

Updated docs https://github.com/slaxor505/OpenPlantbook-client

API Release notes:
version 1.0

Breaking changes in comparison with 1.0-RC:

Removed api/v1/plant/detail/{id}/ endpoint
Removed "id" from responses
Now to get plant details use api/v1/plant/detail/{pid} endpoint.

Client Release notes:
version 1.0

Updated Postman collection:
    built-in variables for easier use (See variables specific to the Collection)
    "Get token" call now extracts and updates {{access_token}} value automatically (no need to copy/paste)
Added Python client by @Olen (https://github.com/Olen). Thanks and Kudos! The client is a step for Home-assistant.io integration and this is why it is a bit over complicated.
7

So what’s the easiest way to incorporate this with the plant card?

8

I have a plan…
My idea is to incorporate this into the Plant component of HA, because then all the different plant cards can take advantage of the data by using the information from that component instead of accessing the api directly.

Since the cards probably would poll the api each time they are rendered, it would make a lot of extra traffic. While adding the information to the plant component instead means only one lookup for each plant when the component is initiated.

I have started on a PoC here:

This is NOT tested yet, so I have no idea if it works. But when it is ready, the point is to get all the max/min-values into each plant entity, and then modify the different lovelace cards to read the data from the plant entity instead of having to set them in each card.

So it means that a plant card config can be as simple as

- type: custom:miflora-card
  title: 'Kitchen Window'
  entity_id: plant.my_plant

Both the sensors and the configured limits are then available from the Plant entity to be used by the card.

9

I have updated the custom component, and it is now actually working!

Added a README to explain some details. Some tweaks are still missing, and then of course getting a PR wrapped up and submitted and cross the fingers that it will be added to the core plant component.

But you can get the files from this component now, and it will fill your plants with config-values from the API.

And here is what a plant entity will look like:

image
image762×631 50.6 KB

Notice the two new attributes name and species. Along with a new dictinary limits which contains the configured max/min-values, either from the Plantbook API, or from the configuration.yaml or from the default values of the component.
These can now be used in the plant cards (or in automations and other template sensors etc).

Just for the fun of it, I also created a fork of the flowe-card which ditches the old way of getting data from the included file.

10

Do you think the Plantbook API should also contain images of the plants?

On one hand it would help tremendously when trying to decide which plant is which when you are searching the API. On the other hand, it is a LOT of data that needs to be stored, fed from tha API and maintained.

11

@Olen for sure have the image is a plus, but don’t if justify the maintenance…

12

About images, I was thinking to simply return URL to image and host files itself separately. In term of data/storage from my prospective, it is not a lot of data because images can have limited resolution.

I have images in roadmap and I’m happy to prioritize it if you guys think it will be useful.

  • How would you use it if there were images? In plant cards? Or you’d like to see it in Web UI when you browse DB?
  • I also was thinking that when “add new plant” feature will be available that it also should be possible to upload an image for this particular plant.
  • In addition to this, you can report if image which is already in DB is incorrect for the plant. And you should be able to upload correct one.

Please let me know how would you use images to help me prioritize above features. :slight_smile:

13

Both web browser and plant card.

14

Hi guys,
I have just rolled out Browse-DB feature in WebUI so it is possible to search plants available in DB. Next step will be to see plants details in UI and update them and create new ones.

https://open.plantbook.io/browse-db/

15

Great!
It would also be nice if clicking on a plant name (Display Name) would take you to a plant-details page.
At first just a formtatted output of the already exisiting plant-details.

But later this page can be filled with more details, such as localized named, images etc.

16

@Olen Yeah, sure thing. I’ve just done. For now I made “Details” button at the end of every row which will lead to related API-call page where you can see details of a particular plant. In future, I will make dedicated form where editing will be possible. I’m planning to roll out the form together with Create/Update plant functionality.

17

Good!

As soon as you/we figure out how to deal with images, I am going to start the process of getting a PR for the plant component merged.

18

Hey, the images are easy to do. It’s in road map but not priority but I can make it as one.
My idea with images is simple. #1 I will host images within separate object storage and will return its URLs as part of /plant/detail response. With create new plant and update, #2 I’m planning to allow providing URL and #3 upload new image for the plant.

feature #1, I can roll out very soon… say next week or something close to that - this seem easy for me. Then #2 with create/update and after that #3

Let me know your thought on above-mentioned and if you guys have any suggestions.
I’m also just curios how would you use images from openplantbook?

19

Something like this, but have an option for the image to be an online image from the db. Like

image: opb:Ab2z678)

Also this card may give inspiration:

20

I’ve updated the custom “plant” component so it now has an image attribute and config.
The attribute can be set in the plant config, but will default to /local/images/plants/<species>.jpg if species is set and no image attribute is provided in the config.

I am not sure about the remote hosting of images and using them directly in HA, because I guess it can lead to potential security issues to have the browser load the images from a 3. party location the user has no control over, and many people would not like that. But having the images (or a link to them) in the plant-db at least makes it easier to download them locally.

I also made a config setting so you can disable the low brightness warnings. The reason is that this is not really something you can do anything about for a lot of plants, so getting notified about the condition does not make much of a difference.
Here in the north, all the outdoor plants don’t get much sun these days. That is expected, and nothing I can do anything about, and does not need to trigger any warnings.