I’m not sure what I’m doing here, but I’m having a couple of issues.
- The flower card seems to be off
- The data is in F, but the ranges seem to be in C, so the ranges are off.
See images. Any suggestions?
Is this with all the new integrations in place?
E.g. Openplantbook, the update Plant integration and the pathced Plant card?
You are right that the ranges from Openplantbook are in C. Can add the details (state and attributes= from your temperature sensors? Does it provide the correct “Unit of measurement”?
And also the detail from the plants (all the attributes).
@Olen are doing conversion with your integration from C to F? Or is it something that you’d expect from API?
I do not expect that form the API.
I am going to have the plant integration convert the data it receives from the API into F if the temperature-sensor for a plant reports its unit_of_measurement to be F.
1 Like
That is correct. I’m using Openplantbook, the updated plant integration, and the patched plant card.
I’m using the Mi Flora sensors with this integration to get the sensor data into HA via MQTT: https://github.com/ThomDietrich/miflora-mqtt-daemon
Where would I add the state and attributes= settings?
Here’s my plant data
Here’s my config:
plant:
openplantbook:
client_id: !secret plantbook_client_id
secret: !secret plantbook_secret
Jasmine:
species: trachelospermum jasminoides
name: Star Jasmine
sensors:
moisture: sensor.jasmine_moisture
battery: sensor.jasmine_battery
temperature: sensor.jasmine_temperature
conductivity: sensor.jasmine_conductivity
brightness: sensor.jasmine_light
Dumb_Cane:
species: dieffenbachia maculata
name: Dumb Cane
sensors:
moisture: sensor.dumb_cane_moisture
battery: sensor.dumb_cane_battery
temperature: sensor.dumb_cane_temperature
conductivity: sensor.dumb_cane_conductivity
brightness: sensor.dumb_cane_light
And here’s the card settings:
Thanks for the info.
I’ll add a fix to the plant integration in a coming update. So that if the “unit_of_measurement” for the temperature-sensor is “F” or “°F”, it will convert the data from openplantbook to F.
Any ideas why the images are not showing up, or why they are not aligned correctly? I’ve used the plantcard previously, and this is a first.
What is the URL it uses for the images?
Try right-click on the image and “open in new tab” or copy the url and paste it into a browser window.
Does the image show up then?
Both are showing:
myurl/local/images/plants/undefined.jpg
Yeah. I have not updated the card yet so it takes advantage of the image attribute to the plant.
Will see what I can do in a few days.
Thanks for testing this.
@homelord: I pushed an update to https://github.com/Olen/lovelace-flower-card so it uses the name and image attributes from the plant.
Hopefully that fixes your problem.
I figured out the issue. I still have to define species in creating the card.
So it works with something like this:
type: 'custom:flower-card'
entity: plant.dumb_cane
species: dieffenbachia maculata
The F to C thing is still not functional
Oh. With my version of the card you don’t need to specify species.
The C to F conversion will not happen until we are getting this included in the official integration.
@Olen Is my understanding correct that currently your plant component does not take image url from API? I’m getting local path to image.
To use the link from the API you currently have to set the following config
plant:
my_plant:
species: foo
image: openplantbook
So you need to explicitly tell it to use the image from the API. This is both to ensure we are not pulling data from the api uneccesarily. And also because I guess some people are more comfortable using different images than the ones provided by the API. Also, it is more of a potential security risk to add images from “untrusted” sources directly to HA.
So today, the priority is:
- Use the path that is set in the
imageconfig-setting for the plant. - If that path is the string “openplantbook” (and nothing more), replace it with the image-url from the api
- If
image:is not set in the config, it will create a local path based on the species name.
I am considering changing this a bit, so it will look to see if e.g. www/images/plants/species_name.jpg exists, and if that file is not found, it will fall back to the image from the API, instead of having to specify it explicitly. That way you can just download the images locally, and name them properly, and they will be used if they are there, but you still get the images (from the API) if you don’t have any local files.
I am not 100% sure which path to take yet, and I am open for suggestions and discussions of any security implications.
And I think it could be a lot of requests to the images, so it would be better to prioritize local images over remote if possible.
This look the best for me. When you set image = openplantbook then API image takes priority over local file. If nothing set then first check local file if no then image from API.
Though some people may prefer not to have any image so possibly there could be option to set image to none, e.g.:
image: none
I honestly treat image as a low security risk as it is non-executable though it would be interesting to hear community’s opinion on the fact that image will be fetch from API by default, e.g.: when image parameter not set at all.
BTW, I’m getting image from local URL (they exist) while my plant image set to openplantbook as below. Is it expected in current implementation?
plant:
openplantbook:
client_id: E...vQ
secret: nCfPF.....Z2WNDq3
Hydrangea:
species: hydrangea chinensis
image: openplantbook
sensors:
moisture: sensor.miflora_moi
temperature: sensor.miflora_tem
conductivity: sensor.miflora_fer
brightness: sensor.miflora_lux
Also from the instruction it seem like I need to set secret as
openplantbook:
client_id: !secret nCfPF.....Z2WNDq3
secret: !secret nsdsF.....Zsssdsr
Do I need “!secret” parameter? It does not seem to work for me as HASS conf. validation fails. Currently, I set it without this parameter.
I have moved the openplantbook-config away from the plant-config in the latest updates, so openplantbook is configured from the GUI as a stand alone integration.
I agreee that images are low risk, but there has been cases where embedded data in images have been used bot to transport parts of infections, but also where bugs in image viewers have been used to trigger remote execution of code by simply viewing an image. It is also a matter of remote dependencies and traffic, which I want to avoid.
Another issue I see is that several of the images returned by the API have a water mark, so I guess they might be copyrighted or licensed somehow. Before using the images wildly and publicly, that should be cleaned up.
Merry Christmas and Happy New year, everyone.
New major release of Open Plantbook 1.03. It is now possible to create new plants and update existing ones via API.
You can find release notes and documentation in OpenPlantbook-client repository.
Postman collection has been updated with these changes and published here.
Next step will be to make modifications available in Web UI. As always I’m open to your suggestions and will appreciate your feedback.
Enjoy this festive season!
FYI, there is an error in your look up… its adding a 2nd .jpg on the end of any URL (local or remote) so right now local is the only way to make images work and you have to add a 2nd .jpg to the file name:
http://homeassistant:8123/local/images/plants/dracaena%20fragrans%20’massangeana’.jpg.jpg
Experiencing the same as you on the local calls. When trying to set images to openplantbook, the url is just “openplantbook”