I’ve been converting my automations from being device-based to being entity-based, and one thing that appears to be missing in the switchover is a completely drop-down list of entity states that have previously been seen from the device.
For example, when creating a device trigger from an Inovelli switch, the dropdown is populated with previously seen actions:
For the states of a sensor entity to be visible in the state selector dropdown, the entity needs to be device_class: enum. And it needs to provide all its possible values in another attribute called options, which is the list of possible states.
A sensor entity with those attributes will correctly populate the dropdown. So if you’ve got a sensor that reports string values, but is not an enum class, that could be something improved in the integration.
Valid point, but since the list of possible values for device triggers is based on values that have been seen, rather than something explicitly specified in the integration, it seems that that would also be a good way of handling it for entities.
I see that one of my reasons (cryptic device IDs in the cases where I switch to YAML editing, usually because I want to copy-and-paste a trigger or action and then change the device) already got covered, but the other reason for me is that some integrations, for some reason, seem to work better when things are accessed by entity rather than by device (the one example that I know of being one particular Govee light fixture accessed through the Govee to MQTT Bridge add-on).
Yes. This is not browser autofill, which looks completely different. Nor have I entered most of those terms manually for the browser to have remembered.