Why are states case sensitive in state triggers? I have been bitten more than once by seeing a sensor with a state displayed in Title case (e.g. “Dead”) and writing a state trigger to match that, only to realize that my automation will never trigger because the actual state value is in all lower case.
In case of a template sensor which is created by a user - the “internal value” of a state is same as “displayed value”:
if state is defined in a template as
state: lowercase value
then it will be shown in UI as “lowercase value” exactly, and of course the same value will be shown in Dev tools → State.
But if an entity is provided by some other integration (not “template”) - then it’s “internal name” may differ from “displayed name”:
assume internal name is “dead” → then the English displayed name will be “Dead”, the German one - different, and so on - each value can have a translation.
(similarly - for a binary sensor, incl. template binary_sensor: it is internally “on/off”, but displayed values depend on a language)
So, when building an automation, check for a proper “internal value” in Dev tools → State.
Conclusion: this is not a valid WTH, it is a question.
A valid WTH might be “Why are the values of states changed and capitalised in the GUI?” It’s annoying for people who are aware of it and confusing for those who are not.
I mean in the English language GUI. I hadn’t thought of your point about translation, which is a good one. But why is it necessary to translate English into… different English?
Erm, why “Connected” or “Problem” instead of “on”?
Ok, then why not “WTH Let me use translated state values for entity state triggers”
In UI editor they are translated.
In yaml you do what you must do - real values.
Yep, the states behind the scenes are untranslated english states.
The states in the UI that you see everywhere with capital letters are translated states. If you swap your language to something else, it will be a completely separate word. If you use english, it jsut looks like a it’s capitalized. Off the top of my head, one place that’s different is not_home
and after translations it’s Away
.
If this trips you up, you shouldn’t be using YAML to make automations, just stick to the UI and use the drop-downs and preconfigured UI settings to handle everything.
If only this were possible in all use cases… I think the OP has a valid point. All the explanations make sense, but don’t make the situation any more convenient or less annoying. I’ve been bitten by this myself multiple times too. While I agree that it’s a good thing that the states are translated, I think it would be possible to make the tooling a bit more friendly. E.g., like we have auto-completion for entity IDs in the yaml editors, it would be nice if there were some autocompletion-like tooling for states. Like with entity ids, it could show the “real” value along with the translated value.
If there is no translation, you use the direct state manually. There won’t be confusion because nothing is capitalized, just copy/paste.
That’s only possible if HA knows the states ahead of time, and if HA knows the states ahead of time, the states are translated and selectable from a drop-down. We are dealing with custom integrations and old integrations that do not provide this information to HA. HA cannot provide what it doesn’t know.
FYI before you all miss interpret my responses, HA’s goal is to make every state it knows about selectable from the UI without needing to move to yaml.
True, but this doesn’t work if you’re working in YAML. My idea was to have a similar drop down while editing YAML, just like it is with entity IDs (and icon IDs).
That’s not possible, yaml doesn’t provide those tools, neither do web-based text editors.
If you’re referring to known states with auto-complete, that is likely possible and a good WTH.
That’s exactly what I meant.
If you have the time, I recommend searching for/creating a WTH for that.
Isn’t this that WTH? I mean: the auto complete for known states would mitigate the OPs annoyance, wouldn’t it?
WTH’s are better when they are explicit and to the point. They are more likely to be picked up.
No offsense to this WTH, but it’s unlikely to get picked up because there is no defined path forward. Where a WTH: why isn’t there an auto-complete for states in the yaml editors gets straight to the point.
Looks good
Your suggestion that I “stick to the UI” is not helpful in this case. The values do not appear in the drop down.
The entity that inspired this post is part of a device provided by the Z-Wave integration.
Yes, that’s a sensor and it does not provide known states to HA. That most likely deserves it’s own WTH as that could easily be an enum sensor with known states.