I’m referring to this post from Stooovie. I think it would be great to have a list at an extra column in the developer tools in which the previously recorded states of entities are displayed so you don’t have to go through the documentation (if there is one available) of each integration or device or have to test the possible states manually.
Have an upvote, this is something would come in handy for me as well.
I know HA can’t know up front all the states an entity can have, but showing a list of all the different states that are in the recorder for a given entity would be useful.
showing it from the recorde means grouping or distinct operation which is not cheap operation.
But aren’t components have defined all possible states internally? what about to make them able to provide such list?
This would be possible for a good chuck of devices (light, switch, binary_sensor, device_tracker, etc) but there’s a bunch that this wouldn’t be possible for. For example, the sensor catagory, everything here comes from a device and the states are potentially endless.
Yes that’s impossible, that’s why I said that the states that were recorded so far should be displayed. Of course, the sensors etc. would have to be connected for a while before the possible states can be shown. For numeric states like sliders or temperature sensors you could turn the recording/logging off, or it is off by default and you can enable it for the entities you want.
2 Likes
It obviously would not be possible for all sensors, but definitely possible for some. Let me pick an example:
The rTorrent sensor. In the list of possible monitored_variables, one is current_status. That’s good. However the description of it is “The status of your rTorrent daemon”.
That gives me some idea of what it does, but I’ve only ever seen that sensor show a single state, up_down. I have no idea what else it could show, since it’s never shown anything else for me.
However if I look at the code on github for that integration, I can see that this sensor has only 5 possible options.
up_downseedingdownloading- STATE_IDLE (which is imported from
homeassistant.const, so I’m still not sure what it displays as) - NONE (Shown as
unavailableI believe)
So the documentation for this integration should probably list the possible options for this sensor. Since the state is chosen from an if/elif code block, all possible states are well defined, just hidden from the documentation unless you read through the code.
That’s just the first example I could think of, but I’m positive there are many more examples where there’s a finite list of possible states, but that list is not in the documentation. It’s hard to create automation based on states where you don’t know the possibilities.
And this is also why I think showing only previously observed states isnt enough, since for me this sensor has never shown any of the other states, but they still obviously exist as possibilities.
I would think it should be (mostly…) trivial for the developer of an integration to know what states are possible especially if the integration isn’t an “analog” type integration.
Where possible the standard should be to require the developer to put in the documentation the possible states along with the possible attribute values where appropriate.
3 Likes
Maybe even have it as part of the metadata for the integration and then this could be displayed in the frontend if available.
3 Likes
Perhaps a nice idea to have the most common states in the documentation for the integration, that would cover most people’s needs.
Maybe a sidetrack a bit but I feel it’s somehow related.
How GUI knows what to display inplace of the state value?
I know that there are several replacements of binary states. Like: open, on representing state true.
Withings integration somehow displays its states in gui as: Clear or Detected. But the message representing state change contains: off or on respectively.
So I scratch my head how does it work? How can I know which state representation is the one I can use on API side and which one is just for graphicsl representation (and how to affect the latter)
That’s all handled through translations. They are defined on the inherited class or in the integration itself in the translations folder. It’s basically a large database that maps each state to a translated phrase.
1 Like