Cloud Plant DB with API for PlantCard

slaxor · July 20, 2021, 11:32am

Hi guys,

I’m working on a cloud Plants Database with API for HASS PlantCard. At this stage, this database consists of temperature, light, soil moisture and fertility thresholds I found in open internet sources. It can be used with Xiaomi MiFlora plant sensor or any other sensor. It is also useful for different irrigation projects.

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 in active development and it has already gone live so you can login https://open.plantbook.io, get API credentials and start using that. BTW, there is a social Single SignOn 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:

Allow to add and update plants thresholds via WebUI
Ability to lodge request for specific plants information to be added to DB
Plant detection API from images
And many other ideas which are blowing my mind…

Please take a look. Let me know what is working well and what is not working at all. Any thoughts and feedback will be much appreciated. I’m open to new feature requests and your ideas!

HASS integration

Available and maintained by @Olen.

Plant component: GitHub - Olen/homeassistant-plant: Fork of the Plant component of home assistant
lovelace-flower-card for UI: GitHub - Olen/lovelace-flower-card

Latest Update - 20 July 2021:

version 1.04

Major UI update. Now Users can:

Modify existing Public-Plants using “Modify” button in Browse DB.
Add new Plants using “Add Plant” button in side Menu. Plant is cloned into User-Plant and visible in “My Plants” side menu.
Modify own User-Plants via “My Plants” side menu.
The only way to delete User-Plant at the moment is via API DELETE call. UI-based deletion will be available in next release.

Release notes and documentation: GitHub - slaxor505/OpenPlantbook-client: Open Plantbook clients and UI

Slava

Olen · September 10, 2020, 9:02am

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.

slaxor · September 10, 2020, 10:23am

Hi Olen,

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

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

Olen · September 10, 2020, 6:54pm

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.

slaxor · September 11, 2020, 2:23am

@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.

slaxor · September 19, 2020, 3:06am

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.

homelord · September 19, 2020, 3:07am

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

Olen · September 19, 2020, 7:06am

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.

Olen · September 21, 2020, 6:37pm

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:

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.

Olen · September 25, 2020, 8:56am

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.

codedmind · September 26, 2020, 10:44am

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

slaxor · September 26, 2020, 10:58am

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.

nickrout · September 26, 2020, 8:47pm

Both web browser and plant card.

slaxor · October 4, 2020, 3:37am

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/

Olen · October 4, 2020, 12:02pm

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.

slaxor · October 5, 2020, 1:31am

@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.

Olen · October 5, 2020, 4:16pm

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.

slaxor · October 6, 2020, 12:12am

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?

nickrout · October 6, 2020, 1:43am

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:

Olen · October 13, 2020, 7:49am

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.