I personally wish unavailable was separated out and made into an additional property on the state object in combination with a new “device/entity online/offline” trigger. That would essentially remove all need to check for to/from unavailable states while still being able to do everything that’s available now. I.e. when this entity goes offline, when this entity comes back online, when this device goes offline, etc. We’d still have unkown as a possible state, but that would only be for a few types of entities that have no known state during startup or don’t have an assumed state during startup. It would really alleviate a lot of random issues with automations without needing template conditions or needing any UI changes.
9 Likes
Joining the party late: but would like to share I have the same issue with motion sensors. What I’m doing now is to use not_to in the trigger include unknown/unavailable, then in the condition I check the timestamp is within X seconds to be 100% sure the event should fire something. Not ideal but works.
Why not simply use not_from instead?
What do you mean? My understanding is ‘not_from’ is not needed because it’s possible after restarting that the value goes from unknown → previous value.
My workaround is to avoid unknown → previous value to trigger an action (as the event is old should be disregarded)
I’m very new to HA so I might misunderstand something, very much like to hear from the suggestions 
It’s very simple to explain. You know it’s the previous value, but HA doesn’t.
Take a door sensor which goes from off to unavailable and back to off.
You know it was off before it went unavailable, so in your mind, it is restoring it’s previous state.
The state engine in HA’s automations don’t work that way though, so according to the automation, all it knows is that it went:
from: unavailable
to: off
Given that most automations are triggered on the to: state, you want to safeguard against triggering when your automation goes from an “undesirable” state to something you actually want. You really shouldn’t care if it goes from off to unavailable, because any decently written automation won’t trigger this way.
Hope that was clear enough - happy to answer any further questions if you have any.
1 Like
Thank you for the explanation!
However there is one case - that is when (in rare chance) my motion sensor changed from unavailable/unknown to motion event (real event), in which case I’d like my automation to fire.
You’re welcome.
I’d generally reply with “fix what is causing your motion sensor to go unknown/unavailable”, but there might be different scenarios where this could happen:
- intentional restart while motion is actually detected: in that case, don’t add the
not_fromin the automations triggered by the motion sensor. - device weirdly reporting motion by itself if it comes back from an unavailable state: keep the
not_fromin the automation or replace the device. - device randomly going unavailable: fix the issues with whatever integration it’s using, of get a new device
(Apologies for the formatting which looks like it’s ripped out straight from AI - I promise it isn’t)