Still, when HA starts, if it has no way to ask, it cannot tell if you’re currently pressing the button or not.
You ME types bring a whole new meaning to the word pedantic. If you guys still ran the world our phones would still be attached to the wall with a cord. 
Well, that is true. But, they worked, or they don’t. They were ON, or OFF. There was no UNKNOWN. 
And again, I do not argue here, just trying to share a different view.
I’m trying to explain, why people, using your software, sometimes do not understand the way’s, devs take to reach a goal. People who do not make software find things unlogic. And I can understand, where it come’s from.
But me myself, I evolved enough to understand your reasons and can work with your logic. Just a lot of others do not, because of the above mentioned differences.
So, no, I do not push anyone to do things the way I describe, just want to give you a view, that explains, why some people do not understand you. (and that means not me).
1 Like
And I don’t understand why you’re focusing on devs while Taras and I tried to tell you it applies to actual people as well, either remote or disabled.
I’m afraid you’re locked in a technical view, where you only take the switch point-of-view into account, not the world around it 
But anyway, enough with this rather pointless and philosophical discussion 
Same here. No data since Update.
This is the solution:
Home Assistant Release Candidate (beta)
That page updates when the beta is available (one week before the ‘stable’ release).
Yes, you can skip the upgrade and dont join the beta.
Hi there,
just updated to 2022.2.2. Since then, my auto entities are no longer available in Lovelace. I first reset to 2022.2.1.
Greetings Werner
Sometimes it is the cache that leads to problems with custom cards.
1 Like
OK. What can I do? Had restarted twice but didn’t help.
Had you emptied your browser cache?
1 Like
For those like me for whom the new ‘unknown’ state is an issue for their event-triggered binary sensor templates, there is a workaround (probably not the most elegant, but it works for me): you have to “bloat” your templates with an additional trigger event, homeassistant start and then test it everywhere else (not only in the state templates, but also in the attribute, icon ones).
Additional trigger:
- platform: homeassistant
event: start
id: "ha_start"
Then test it in your template state, attributes (& icon):
state: "{{ iif((trigger.id == 'ha_start'), 'off', 'on') }}"
attributes:
attr_one: "{{ 'None' if (trigger.id == 'ha_start') else trigger.event.data['...'] }}"
Ideally, you could also add the trigger on the event event_template_reloaded.
All of that could be spared if there was an initial/assumed/starting/default value parameter added to the state, attributes, icon…
1 Like
Interesting choice of verb.
It’s a fairly common practice to include multiple triggers in a Trigger-based Template Sensor in order to ensure it reports a proper computed value at startup, reload, etc.
1 Like
That was the mistake. Thank you. 
Because, for the state at least, it was not necessary before (and again, what does this newly introduced change fix?) and would not be necessary if my last paragraph was considered.
1 Like
Another example that might help regarding button presses: I have an air purifier that has a button to set it to ‘Auto mode’. If I press the button on the remote or in HA, it just sends a command to set it to auto, even if it’s already in ‘auto’.
I can walk up to the purifier and change the mode by increasing or decreasing the fan speed, which would make it not be in ‘auto’ anymore, and mode would either be ‘low’, ‘medium’ or ‘high’. But the remote and HA both don’t know what state it’s in, all the button press does is send a command to make it ‘auto’ again.
So one way of looking at the difference between a button press and a momentary switch is that the button sends a command blindly, and the command doesn’t have to only be on or off. Whereas a momentary switch will just do the opposite of the devices current ‘on or off’ state
It brings parity to Template Sensors; other entities have always supported unknown.
Submit a Feature Request.
Well, the last thing, I will say, before I quit this discussion.
You push the button. State OFF → State ON → State OFF
what happens with the machine behind it (goes to AUTO), has nothing to do with the state of the button. The button is OFF.
If somehow you restart the controlling device (HA for example), then it is the machine, who is in UNKNOWN state, not the button. The button is OFF. It is not pushed right now. It will report ON when pushed.
But, this discussion is ridiculous, as said before. Not worthy my time anymore. I’m quitting it now.
Not angry or something, just do not feel like my help is anyhow appreciated, so turning my head toward useful stuff.
4 Likes
You almost have that right. It’s the machine knowledge of the button’s state that can be unknown.
Refer to the example I posted previously. What’s the state of my kitchen switch right now? You don’t know for sure until I tell you. Therefore, based on your current knowledge of the switch’s state, it’s unknown.
3 Likes
+1 here, empty dashboards