Add max/min-configuration to Plant-attributes

Feature Requests
1

Thought Id’ try this here before creating a PR, in case there is some fundamental flaw to the idea.

While developing a Plant Card for Lovelace we wanted to access the configured min/max-values for moisture, temperature etc. from the Plant domain to display different states in the card.

This could be easily solved by adding another dict to the Plant State Attributes containing the configured (and/or default-) values.

This would also help creating better automatons for plants, as the current State only shows there is a “problem”, but the actual problems is just a comma separated list of “XXXX high” and “YYYY low”, and you don’t know how serious the issue really is.
E.g. I probably dont need to take any actions if moisture just 1% below the “minimum” mark, and rain is predicted in a few hours…

So my idea is to add something like the following at the top of /components/plant/init.py

ATTR_CONFIG = "config"

And around line 355:


            ATTR_CONFIG: {
                CONF_MIN_BATTERY_LEVEL: self._config[CONF_MIN_BATTERY_LEVEL]
                CONF_MIN_TEMPERATURE: self._config[CONF_MIN_TEMPERATURE]
                CONF_MAX_TEMPERATURE: self._config[CONF_MAX_TEMPERATURE]
                CONF_MIN_MOISTURE: self._config[CONF_MIN_MOISTURE]
                CONF_MAX_MOISTURE: self._config[CONF_MAX_MOISTURE]
                CONF_MIN_CONDUCTIVITY: self._config[CONF_MIN_CONDUCTIVITY]
                CONF_MAX_CONDUCTIVITY: self._config[CONF_MAX_CONDUCTIVITY]
                CONF_MIN_BRIGHTNESS: self._config[CONF_MIN_BRIGHTNESS]
                CONF_MAX_BRIGHTNESS: self._config[CONF_MAX_BRIGHTNESS]
                CONF_CHECK_DAYS: self._config[CONF_CHECK_DAYS]
            }

(Not tested in production)

But I am not sure if adding configured values to a State object is the wrong path, and this should be resolved in another way.

2

Sad to see this hasn’t gotten more traction. It would be a great feature to have. Voted regardless.

1 Like
3

Active Pull Request: https://github.com/home-assistant/core/pull/71514

4

A very similar PR was rejected a while ago on the premise that config should not be included in the attributes.

The core problem is that the frontend can only access a very limited set of features from the backend - basically the state and the state attributes of an entity. And to use these numbers in the frontend, they need to be communicated from the backend somehow.
If the frontend could also access public varibles or (a subset of) functions from an entity directly, this would not be an issue.

However, I am now about to completely rewrite “my” plant integration, and are moving these out to separate configuration entities, and I also have an updated “flower-card” that uses websockets to get the thresholds from the plant device.