Having case-sensitive states has no use, as far as I know (please educate me, if you think differently) and is confusing for non-savy users.
The GUI shows states capitalized, but using states capitalized in p.e. an automation will not trigger the automation. There is no error raised and no indication for the user, what they did wrong.
Example for GUI output:
The ongoing push to include more functionality in the GUI is good, but the user experience should follow suit. Making states case-insensitive or providing a proper validation would help a lot with user adoption.
It is not the state that is displayed in the UI, it’s the translated state based on which language you have selected. The raw state name is available via Developer Tools -> States.
The state will always be lower case on and off. As pointed out above though the frontend can translate this into many things other than on and off:
See: https://www.home-assistant.io/integrations/binary_sensor/#device-class
Alright, thanks for the input. What do you think of a dropdown menu for known states (either on/off or frontend output)?
Currently a normal user might just enter “Cold” and will not receive an errror. Other than that, my initial proposition of input validation is still up. A user entering “Cold” should not be able to save via the GUI, if it is not a valid state.
For the majority of end-users it does not matter what the internal state is and expecting them to know is not something I would subscribe to.
1 Like
I agree, it makes way more sense if you select a binary sensor for trigger or condition, the state selection should be an “on/off” dropdown