Hi everyone,
Sorry I have been more or less absent in this thread for a while. I have not really prioritized the project for several reasons. First of all, I have been really buzzy at work. Which I guess is a good thing in this day and age… Secondly, it’s been winter here in Norway, so 90% of my plants are either dead or covered in snow. And thirdly, the PR to get access to the configuration values has not moved at all.
This core problem here is that we are not allowed to expose config-values (e.g. the max/min-values for each plant) as attributes for the plant. It is done in the integration today, but as soon as I touched it, to add some more values, that patch was rejected. Even though it could definitely be argued that even though they are set in the config, they are “attributes”, and not “configuration” of the entity. But that discussion seems to be lost, so I won’t keep beating that horse.
Now, one could quite easily expose them in a websocket as suggested (and I have code for that in a private branch), but that is only really helpful for the GUI. It does not expose the values for scripts and automations, so you can’t in an easy wayt create notifications, automatic irrigation etc. by going that route.
What COULD be done, is to create another integration, which uses the websocket from the plant integration, to create the neccessary sensors to expose the max/min-values. But to me that sounds like a terrible solution and really lots of extra work and abstractions to do something that should be very simple.
Another path forward, which I like more, but still are unsure will be accepted, is to recreate the plant component to be more like e.g. a thermostat entity. Meaning that you can modify the max/min-values like you modify the setpoint of a thermostat. That would probably allow us to expose the values as attributes, because they are separated from the actual config.
This would also allow you to more dynamically adjust the values, and fetch the data from either the Open Plant DB or from other sources.
This also requires some more work to be functional, and I did not want to start on this before I have verified that it is a viable route, by getting an ok from the core developers. If they accept that solution, we probably also need to create a GUI-setup for the plants, and other bits and pieces to make it up to the modern standards of an integration.
(github.com) for the BLE to MQTT part.