Triggers: 'Unavailable' != 'unavailable'?

I have an ESPHome device for which I want an automation to trigger whenever it comes back from being ‘unavailable’ (i.e. offline, being rebooted, whatever).
Seems simple. But…
Setting up a trigger using the UI, and choosing the state to be from ‘Unavailable’ never fires.
But if I edit the YAML and change the trigger to the uncapitalized ‘unavailable’ it works as it should.

So, why are trigger states case-sensitive?

Part of the ingoing problem was that the UI offered me the capitalized form of the available states, but the integration presents them un-capitalized. I let the UI create the YAML (a reasonable thing to do), but the YAML then stored the trigger with an uppercase ‘U’, and it never triggers.
Just observing the states change in the developer-tools panel showed me the difference in the typographical case of the states, which led to this observation.

Hi glyndon,

Did you write this to vent or are you actually looking for a technical answer.

I would venture to guess that because almost all the internal references that have words are lower case, that this is as well.

This is a good question, this should be written up as a feature request I would guess.

It would be a frontend one, so it would go here:
home-assistant/frontend Other Feature Requests · Discussions · GitHub.

I write it to possibly point out a coding error somewhere.
If one uses the UI to create such a trigger, their trigger will never work.
I searched the forum for the problem and saw that others have run into it and seem to have never found a solution.
That it is simply a matter of capitalization seems (to me) to be a trivial programming oversight, which by pointing out, I hope that the relevant author(s) will see and assess as to whether it is deliberate or an oversight.
My goal is only to help. Yes, pointing out flaws can be a form of help.
Testing for state changes using case-sensitive code, when it’s clear that not all the code observes actual states sent, seems like an oversight (the kind someone would like to know exists).

Apologies if I miscategorised the post.

No problem. I would post there though or look if it’s already requested there. Sound like odd behavior for sure.

1 Like

It’s hard for me (mostly end-user, but with lots of old-school IT background; read: I’m old, and don’t necessarily grasp all the nuances of bug-reporting these days) to know upfront if this is a UI defect, or a logic flaw in the trigger-testing code.
Offhand, it feels like the latter, since altering the YAML ‘fixed’ it.
That makes me feel that the UI should be able to paste what it wants in the YAML, but that the trigger code should not consider case as an issue when comparing strings.

Where could I place this post so as to hopefully bring it to the attention of both realms?

So the place I suggested is for feature requests. This might be a bug but that is not certainly clear. Bugs require a bit more knowledge, but front end feature requests they ask for the versions of stuff and what you would like to see changed. much lower level of entry.

Certainly someone here might take up your flag and make an issue, but I don’t use the UI editor enough to be able to test it or answer questions and stuff either.

Also searching thru the current list of [FR]'s doesn’t take any particular knowledge either.

This still feels entirely more like a bug than a missing feature.
That is, two parts of the same system should not collide like this.
That’s not ‘missing functionality’, it’s an error.
If I open the UI and choose from the selection list that it offers (and the option I seek is shown!) then it should match what the downstream logic is going to process successfully.
That one, or both of these are incongruous is something people have already noticed, and most certainly would notice in a retail product.
In other words, I’m not writing to ask for function that doesn’t already exist (i.e. a feature), I’m posting about what looks like it works, but doesn’t. (i.e. a bug)

Turns out the origin of the mis-capitalized ‘unavailable’ is in the mobile app, not the default web UI (which creates the proper case for that state).
But it leaves unanswered the questions: why is trigger state case-sensitive? Are there actually states that differ only in capitalization?

1 Like