WTH Why is ignoring Unknown & Unavailable states so difficult

Month of "What the heck?!"
1

Why is it so difficult to build triggers that specifically ignore Unknown or Unavailable states. Currently doing so requires using Yaml, or adding a template to conditions. Ideally it should be as simple as a checkbox to not trigger when state changes from unknown or unavailable.

Currently it seems like the easiest option is using yaml like so:

trigger: state
entity_id:
  - XXXXX
not_from:
  - unknown
  - unavailable
2

So how exactly can it be simpler?

1 Like
3

I think they are specifically referring to it being yaml only. I.e. Not available via the UI.

2 Likes
4

Correct, ideally there should be a way to do this without touching yaml, especially because I assume its a common annoyance.

I can only speak for my devices, but to give a simple example of a doorbell. If the doorbell loses wifi, or I reboot HA, the state goes to unavailable or unknown and then will trigger on reconnect when it gets the prior state even though nothing has actually changed

2 Likes
5

Proposed PR
https://github.com/home-assistant/frontend/pull/23285

(decided to drop it)

2 Likes
6

Would your doorbell not go from unavailable to off, where you trigger would be when it goes to on?

7

I don’t know exactly OPs case but this is really more a problem with event entities, not so much binary_sensors.

The state of an event entity is always the timestamp it was activated. So if you have an event entity, you really want to trigger on any change in state, since you can’t actually predict any particular string.

But if your integration is reloaded (or providing device loses connection), it will glitch from <timestamp> → unknown → <timestamp>, and trigger unexpectedly. So using not_from/not_to is kind of required there.

Also true for other timestamp based entities like button, script, scene, etc.

8

I think the case/issue is exactly what you describe for events. Im nit sure its soley an event issue though as I have had tjis happen in the past for other automations with non events.

Also thanks for making a PR with the change. I do wonder though if this is a design flaw with events if it would make more sense for events to never be unavailable and just have the last timestamp

9

In my experience you do want to trigger it from unknown as well. If you restart HA, the event entities will start with state unknown. If you don’t trigger from: unknown you will miss the first event.

1 Like
10

Adding checkbox dropdown to GUI would solve it: WTH can't we multi-select for input_select entities in conditions?

1 Like
11

If you use a jinja template, you could use the filter “has_value(‘sensor.my_sensor’)” which will will test if the given entity is not unknown or unavailable. See Templating - Home Assistant"

But yes, this requries jinja


1 Like
12

Ok did a little more testing and I find that at least for zwavejs (my only event provider), all events are restored to prior state on restart (they startup with their previous timestamp from before the restart), and no state change event is triggered. I thought maybe this was different in the past
 maybe something changed?

Maybe behavior is integration specific? Do you have an integration that resets event entity to unknown on restart?

However hitting “reload integration” for zwave causes glitch to unavailable, which does trigger state changed on event entity.

Perhaps that PR is not the right approach then.

13

I can only speak to my doorbell example, but if I restart HA the event does not stay as unknown until it gets triggered. I rebooted HA a few hours ago and the event currently shows the last time it was fired which was 12+ hours ago which was before I rebooted it.

14

Yes this seems to be the suggested solution, and I did try this but it actually did not work for me. Its very possible I did something wrong though, but either way ideally it shouldnt be required to add jinja to every automation and as a condition to accomplish this

15

Hmm, it seems to be depending on the integration. ESPHome event entities stay unavailable until they are triggered again. Zigbee2MQTT entities come back online with their previous state.

1 Like
16

Yeah its very possible the better solution is to instead not go to unavailable for events. I originally ran into this issue when one my integrations had an update(outside HA) and so HA was unable to connect to it for a few minutes and it went to unavailable.

After the update completed, it then changed from unavailable to the last known state but triggered the event again causing the doorbell to go off.

1 Like
17

I agree with the headline of this topic.

But all the (well meaning) suggestions on how to write yaml inja templates shows the problem.

Example:
As a newbie user set’s up an automation to open the windows if the room temperature get above 25 degrees.
And the newbie even created a small card with the temperature
That’s simple and he/she is happy.

But then he/she starts getting wired error messages, and the card with the temp show funny things. Just because the temp sensor lost connection for a short period. And he/she is now forced into the land of strange markup languages, and long hard to read documentation, to figure out that there is some secret Woodoo spells. Where the temperature is not just a number, but can also be “unknown” or “unavailable”, not “missing”, “lost”, “not-known” or any of the other magic words you might try and guess. No you need to know the exact magic words.

18

I think a better example for this problem is a door switch, where you expect long periods of open and closed, not a short press of a button.
And you might have actions on both close and open.

The underlying problem is that a non-tech user believes that a door is either open or closed, not anything else. (and newer crack jokes about Schrödinger’s cat)
Therefore the natural conclusion is that if the door sensor changes to closed, the door was open and is now closed.

And the UI should reflect that reality,

But to use HA as it is today, that poor user needs to learn that a door can not only be closed or open, but also unknown
“What do you mean by unknown, the door is right there I can see it with my own eyes??”.
“Well it is actually not the door that is unknown it is the sensor!”
“What? But it is right there and it is named Sonoff, how can you say that it is unknown??”
“Well it is not the sensor that is unknown it is the state of the sensor, and it reflects that the wireless connection was interrupted for long enough to trigger a timeout in the
 !”
“The state of it! Timeout!.. Well guess what, the state of that stupid sensor is soon to be >>Flying out the window<<. And that Home assistant can go take a timeout on the bench.”

So to a normal user the state of that door should always be open or closed, nothing else.
Then the handling of the unknown or unavailable states should either be handled in some other context, or only be considered by the automation if the tech-savvy user explicitly asks for it in his/hers advanced yaml setup.

1 Like
19

The so-called “poor user” in this hypothetical discussion seems unwilling, or incapable, of learning new concepts. They should find a hobby that doesn’t demand anything from their brain.

For all other users, unavailable and unknown are useful states that allow you to handle real-world failure scenarios (because devices can fail).

1 Like
20

What we need in the first place is to remove confusion around those states.

Right now there seems to be no clear-cut guideline what they mean exactly and when they should be triggered.

One example was even given above, with some integrations starting with “unavailable” state, some with “unknown” state, and yet other ones restoring the last state from before the restart.

1 Like