Cloud Plant DB with API for PlantCard

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:41am

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:39am

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.

slaxor · October 15, 2020, 1:53am

Here we go. OpenPlantbook release 1.02

WebUI and API Release notes:

version 1.02

Introduction of Plant images feature. api/v1/plant/detail/ endpoint returns Plant’s image URL as image_url JSON string field.
Web UI is generally available for guests. Guests can search Plant DB but to get API key and plants details Signing in is required.

image_url is supposed to be dynamic link so please do not hardcode them anywhere but update from API.

Example:

curl --request GET 'https://open.plantbook.io/api/v1/plant/detail/acanthus ilicifolius/' \
--header 'Authorization: Bearer token_string'

{
    "pid": "acanthus ilicifolius",
    "display_pid": "Acanthus ilicifolius",
    "alias": "acanthus ilicifolius",
    "max_light_mmol": 2500,
    "min_light_mmol": 1200,
    "max_light_lux": 6000,
    "min_light_lux": 1500,
    "max_temp": 32,
    "min_temp": 10,
    "max_env_humid": 80,
    "min_env_humid": 30,
    "max_soil_moist": 60,
    "min_soil_moist": 15,
    "max_soil_ec": 2000,
    "min_soil_ec": 350,
    "image_url": "https://example.com/n/sdpo/b/plant-img/o/acanthus%20ilicifolius.jpg"
}

slaxor · October 17, 2020, 1:29am

@Olen
Possibly when you get details about a plant, you can download/cache image into local folder and then refer to the local folder within component. Though, as the image can be updated on Cloud end then there should me way to re-fetch plant’s image_url from API and then new image using new URL again. The thing is in current implementation even if the url is the same the image can be different as the key to the image is pid (PlantID).

Also as users will be able to update and add more optimal environment thresholds, there should be way to refresh plant’s details from API.

Olen · October 20, 2020, 5:24pm

I have now moved my custom component into a branch in my main home assistiant repo in preparation for creating a PR:

The logic for max/min values are:

If a value is configured in configuration.yaml, that value is used
Else if plantbook api is enabled, the values from the api is used
If no plant is found in the api, or api is not configured, use a hard coded default value

The logic for images are:

If no image: is configured in configuration.yaml generate a local url
Else if image is set to the string "openplantbook" in configuration.yaml, use the image URL from the API
Else use whatever is set in configuration.yaml

Auto-generated URLs default to http(s)://ha_external_url/local/images/plants/species.jpg
So you end up with one of:

image: http://10.11.12.13:8123/local/images/plants/sansevieria trifasciata.jpg
image: https://objectstorage.ap-sydney-1.oraclecloud.com/n/sdyd5yr3jypo/b/plant-img/o/sansevieria%20trifasciata.jpg
image: path/from/configuration_yaml.jpg

I have not implemented any auto-download or local caching of images, which is why I default to a local path. It is easy enough to download the image to the correct path manually when you add a new plant.

I am going to do some more cleanup, and possibly wait for the API to settle a bit more(?) before submitting a PR to the plant component itself.

I am not sure I will implement a “refresh” function for this. The data is pulled from the API each time HA starts up, and I don’t think there will be that many changes to the values.
On the other hand, I am considering adding “config flow” to the plant component, so plants can be configured from the GUI. As of now, it would be quite complicated, as you would first need to add the API client_id and secret, and then add each plant by searching the API (with a fallback if no plant is found). And then be able to add the neccesary sensors…

For now I am pretty happy that all I need to configure is the species and sensors, and the rest is taken care of by the component.

slaxor · October 21, 2020, 6:06am

Excellent work @Olen! Thank you!
I’m working on database editing now. Though let me know if you need any extra features for further development.

Olen · October 21, 2020, 7:53pm

I’ve changed my mind…

I split out the openplantdb functions to a seperate integration, and made a config flow for setting up the API.
In the process I realized that the only reason this was necessary was that the API requires authentication. I am not sure why you require that for read only access, but that is another discussion…

I have also changed the plant component again, so it now takes advantage of this new openplantdb component if it is enabled and configured. This means less modifications to the plant component, and also that it could be possible to add other sources of information about plants as well, if that becomes an option later.

I’ll clean up the code some more, and add a PR for the openplantdb integration tomorrow. If (when) that is merged, I’ll add a PR to update the plant component as well.

rlems · October 21, 2020, 8:03pm

Wow, my deepest respect for you two! Absolutely interesting!

Olen · October 22, 2020, 12:35pm

Thank you. It always annoyed me that I had to configure the max/min values for each plant in every card or sensor or automation or whatnot, and I was really considering setting up such an API myself. However, it requires some infrastructure that I do not have time to maintain at the moment. So when @slaxor did that heavy lifting, it was a great opportunity to get this “right”.

The PR for the OpenPlantbook integration is now added:

I need to rewrite parts of it and get a openplantbook-python package published in pypi first… So it will take some more time tha initially thought.

Olen · October 22, 2020, 7:07pm

So, the pypi-package is now ready (this is a learning process…)

Next step is rebuilding the integration to use that, which shoudl be pretty easy, and then getting back to the PR…

Olen · October 23, 2020, 12:52pm

@slaxor would it be acceptable to open the full API to everyone (read only), without having to use a client_id and secret?
It would greatly simplify the integration in HA, as we would not need a special integration just to configure the client_id and secret.

slaxor · October 23, 2020, 10:17pm

First of all, thank you @rlems for good words. I’m very glad to hear that we are bringing value to community and the product of our efforts is useful.

@Olen I’m really grateful for your contribution while enables myself and others to start using the api with home-assistant straight away.

Thank you for raising questions about anonymous read-only API access. There are number of reasons to require authentication, though the main ones are:

Cloud resources are limited and I’d like to spend them only on intended use. So API serve only users who is registered and understand what API for.
Another reason is security. What do I mean by that? If for example there is an DDOS attack on API or some API client misbehaves (the most likely scenario). Without authenticated access, I have no means to track the client and isolate it to prevent negative impact on API performance and cloud resources consumption.
In addition to this in near future, API will provide write access as well so it would be more difficult to segregate anonymous requests.

Having said that I understand that authentication always brings extra layer of complexity and because of that I’m making it as simple as possible to users and developers to register and get credentials. There is potentially room for improvement here and I’m happy to implement whatever necessary to make it even easier.
I hope it makes sense and understandable. Nevertheless, I’m open to any suggestions.