I have a bunch of automations on devices with statusses that sometimes become unknown or unavailable. This means that I have to make triggers from On -> Off instead of just triggering on On. I think that also means that I now miss states that go On -> unknown -> Off, to me that’s still On -> Off.
I haven’t encountered a situation where I actually care about those statusses in my automations.
I’m currently using the not_from and not_to options, but that means that I cannot use the visual editor anymore.
WTH can’t I tell devices that they should just ignore those 2 statusses and keep what HA thinks the status was?
Edit:
This apparently is a:
WhyTH does the trigger documentation not mention that using both from and to removes the need to handle the unknown and unavailable states.
This is a very important part of how HA handles states and not a WTH.
If you want something to happen when a device turns off then you must know if the state change is because going from on to off or if it just lost connection for a brief moment.
I am not using UI editor for automations.
If you are saying that something is possible in yaml - but impossible in UI (cannot confirm this) - then probably a proper WTH should be “why this option is not available in UI editor?”
So because it’s logical to you, it’s not a WTH for me. Didn’t know it worked that way. I don’t know (nor actually care) why it’s important to HA, it’s not important to me or my automations and it’s a WTH every time I forget.
There probably could be a way to keep the statusses for HA, but hide them for users that just don’t care about them, even if it would be a toggle in triggers to automatically add the not_from and not_to with these two statusses.
I do not care about the distiction between On -> Off and On -> Unknown -> Off. That unknown is meaningless to me, the state went from on to off.
I’m saying I have to take something into account that I don’t want and that I think the workarounds (that I know of) suck. Improving the workarounds could be a possibility, but the actual WTH is having to remember those statusses every single time I make an automation.
Having the UI handle this option would make it less of a problem, but it wouldn’t actually fix it because I still have to remember that, for instance, booleans can have 4 states instead of the regular 2.
I as a user don’t care about these statusses. They make automations more complex than I think they need to be.
Similar:
why would I care to use “foo | float” for numerical states,
why would I care to use “foo | float(default=0)” - it is not my headache to keep this state numerical,
etc
In short: making an automation = writing a program, you should care about possible values, conversions, …
I’m not advocating to remove them completely, just to allow them to be handled differently in certain situations. I understand that just removing the states would break a whole lot of automations. I’m not trying to give a solution, I’m trying to get what I perceive to be a problem across.
Sure, but why use HA at all, just program the entire thing. Isn’t the goal here to make things more simple? Not having to care about these values would make life a lot more simple for me.
Because Off -> Unknown -> Off would trigger (see why I think this sucks, this is not something I would want to have to think about).
Hm… “you as a user”… that makes me wonder: who’s admin of your HA then? If it’s YOU, then you’re not a user but admin which means you do (you should) care. If admin is someone else and you’re really only a user then it’s really not up to you to set this WTH question in the first place, don’t you agree?
It’s kind of similar as you’d say that you don’t really care if your car works fine or not, if its tyres are correctly filled or not…
(Assuming that YOU are the admin) perhaps because in that case you also don’t care if, say, your garage will or won’t open when you come home, you don’t care if your climate will or won’t cool down/warm up your house for you before you come home, or if you have alarm system made with HA you don’t care if your house will be safe or not (because one offline sensor)…etc…
Knowing if and which devices are offline is important part of working with HA. If a device goes offline to frequently then it’s either something wrong with device or with receiver of that device (zigbee stick, wifi router…) and you must address this problem. As described above: if anything triggers because an offline situation (unless specifically wanted) it’s wrongly programmed system - I guess you won’t be happy if, say, all your lights go on in the middle of the night because one single device will go offline because automation is wrongly defined, would you?
It doesn’t suck at all. Automation will just do exactly as you told it to do: When it goes to OFF it triggers. You didn’t specify “from what state to off”. It’s program. It must be programmed. It’s not some AI or clever self-thinking “creature”, so it only does exactly as told. If you’d state" OFF → on → off" it will change things a lot.
Again, not saying the states must be removed completely, just saying that it’s a hassle to constantly keep in mind that they are there and having to deal with them in situations where they are not important to me.
In most cases for me, I wan’t to trigger on physical actions, someone pressing a button or whatever. That the button has become offline is interesting, but not for that specific automation.
Yes there are workarounds, I’ve used the not_from and not_to and I have made helpers that have a sane default value and that helps a lot.
I’m not entirely sure if Off -> Unknown -> On triggers with a Off -> On trigger when using not_from but again, I think it’s bad to require users to think about that, especially because it’s not immediately clear (to me) that I have to when building the automation.
You see another user making the same mistake that I have made and am arguing against and you go “Nope, no problem here”.
Given where? By using the not_* options that I still have to think about constantly?
I must say that I’m quite surprised about the pushback on wanting something like a binary_sensor to actually be binary.
It may be that I’m just dumb to forget it constantly but most of the issues I have with automations is forgetting these states (combined with having devices that trigger them).
How are you supposed to know if something is wrong if you want to mask the error message?
If your alarm goes offline then it reports unavailable, but you want to mask this so it keeps saying Armed. Is that really a good idea?
Everything will look as if it’s working but some things wont work. That is the worst problems to debug.
If the state says unavailable then you know something is wrong and you can start troubleshoot the issue.
In the world of computers a binary sensor can be four states.
On and off is the normal states.
Unavailable is the word used in HA for a undefined sensor, meaning the sensor does in fact not exist, so your reference is wrong, at least in that moment.
Unknown is the word used in HA for a sensor that is defined, but otherwise cause an error, so it can not tell if it is on or off.
well, as i said: HA is only doing what’s told. You must clearly tell what to do and if you’re just saying, “when go to off do this” - HA really doesn’t care from what state went to off because you didn’t tell it to watch for this. That’s why you must either say “from on to off” or use “not_to” or “not_from”, as explained.
It’s basically similar as if you’d say to your brohter/sister: “hey, put it into this drawer”, while not stating WHAT to put in, so don’t be surprised if he/she will put something weird in…
Yep, no problem here, i say again. Problem is user’s wrong programming, not HA. Don’t kill the messenger…
Exactly there. But with you saying:
I start to wonder if HA is for you… HA requires a certain amount of skill, programming, knowledge. If that’s too much options are there, which only require “snap-in” modules and nothing more (price is accordingly bigger then).