or, perhaps another comparison: you’d like to jump into water head first but without knowing how deep it is…
And in no way is the goal of HA to make things easier? I thought that was the entire point of these WTH topics.
3 Likes
Should not cause “adding vagueness/fuzziness/ambiguity/…”
I’m not sure how HA can make things easier than writing:
from: on
to: off
or even better: selecting these two in UI when creating automation.
That’s why i wrote
I start to wonder if HA is for you…
and i meant it…HA is open source, freeware… and it requires quite some amount of programming, maintaining etc… it’s definitely not “set-and-forget” thing.
And there is the bug, you are missing the not_* attributes. Thanks for proving my point.
I haven’t given a solution and you already determined it to be vague/fuzzy/ambiguous. That’s strange is it not?
Hm… what bug? Above statement clearly said to do something when trigger goes from OFF to ON and only then. There’s no need for “not-” anything here, since automation won’t trigger if it goes from unavailable to off, neither if it goes from unknown to off.
But you suggested to allow users to write a code w/o knowing important internals.
I’m done discussing in circles.
(at least) three people are apparently against ‘improving’ this, we know that now. I’m still heavily in favor of making this better.
Have a nice day
1 Like
Come on dude. You are wrong and just admit it.
What @Protoncek said is correct. If you say from on, to off then it will not trigger because of an unknown or unavailable state.
This is how it works. You can try it yourself.
However, when we talk about sensors where the state can be anything then you need to specify not_from since you can’t realistically list all states.
And no, it will not make it any easier to remove the un-states.
All of a sudden, On -> Unknown -> Off doesn’t exist anymore?
Not in the context of what @Protoncek provided. That will not trigger if you provide a from and a to.
It does but it will not trigger an automation that is set up with
from: on
to: off
try it yourself!
Can everyone relax with the proving right or wrong things happening here? Thanks.
I have a bunch of automations where I’m sure I added the not_from and not_to in specifically that situation. It might be that I’ve added those during debugging and didn’t notice being able to remove those after also adding from afterwards and then learned the wrong lesson from it.
I’ll have to check that.
Would have been way faster if I was told how I was wrong instead of that I was wrong about 30 reactions ago. This example has been given multiple times already and unless I missed it, this was not pointed out.
Edit:
Quick test indeed seems to indicate that I was mistaken in how this works.
@Hellis81, @Protoncek, @Ildar_Gabdullin: Sorry for not noticing that this was wat you were trying to say.
2 Likes
It’s a xy problem.
You kept saying you wanted to remove the un-states and we kept saying why that is a bad idea.
Had your question instead said, how can I fix the issue that it triggers my automations when only having to: on then someone would have said add from: off.
To be fair,
This means that I have to make triggers from
On -> Offinstead of just triggering onOn. I think that also means that I now miss states that goOn -> unknown -> Off, to me that’s stillOn -> Off.
That statement is only true because I actually (but incorrectly) thought that 
I tried to clarify it with
I do not care about the distiction between
On -> OffandOn -> Unknown -> Off. That unknown is meaningless to me, the state went from on to off.
Hm… you’re wrong again. This last:
On -> Unknown -> Off
Certainly doesn’t mean
the state went from on to off.
Well… it kinda does… it definitely went from on to off. BUT…whole process can be:
“ON” → after a while device’s state becomes unknown. While it’s unknown it’s state can actually be: “on-off-on-off---- or it can go off and stays off for, say, one hour…”
And when state becomes known again and it’s “OFF” you really have to clue what happened between those “on” and “off” and when device became off. And we didn’t even came to the fact that whole this time you’ve had no clue that device is “dancing” between on and off state, because state, visible to you was “unknown”.
In fact, i think you’re confusing “i don’t care” as “you as a person” and “i don’t care” from HA’s point of view. And this last IS very important, so let’s say that you’re partially right - YOU as a person perhaps don’t care indeed, but HA cares a lot, and since you are HA’s admin person/programmer - you care, you care a lot. You care for HA.
Please stop this now.
4 Likes
I’ve been trying to square the circle in why saying On -> Off would include On -> Unavailable -> Off, and I think I found out that it actually doesn’t, but that it probably doesn’t matter.
I have a self-built integration built on the mqtt discovery that I tested with before, my implementation sets the availability first (which is probably something every integration does, especially the mqtt ones), then sends the current state of a device. The actual order therefore doesn’t seem to be On -> Unavailable -> Off, but On -> Unavailable -> On (because it became available) -> Off which makes the reason why the from and to solution works a lot more clear to me.
If I manually set the states to On -> Unavailable -> Off (by updating the actual state while the integration state is unavailable before making it available again), the from: on, to: off, the automation does not trigger, but since integrations probably (hopefully?) don’t actually do that, it doesn’t matter.
not_from: unavailable, to: off also doesn’t trigger in this case, so I don’t see other workarounds other than getting integrations that do it that way to change their behavior.
Judging by the discussion, I’m expecting that integrations don’t actually do this and in that case it doesn’t actually change anything; I still don’t need the feature I requested, but it helps me wrap my head around why the solution works (unless I’m wrong again ).
1 Like
For me I don’t see the use case to distinct between unkown and unavailable.