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
The solution:
At least you could find that phone.
1 Like
So there is a button that reboots, say, a Shelly device. What should it’s state be? Are you saying it’s state should literally be “operational” or perhaps “available”.
Updated to 2022.2.2 and noticed that the Shelly’s with Tasmota did not come up. Mqtt is working fine in 2021.12.10, also when I rolled back the update, back to 2021.12.10.
The Shelly’s with Tasmota 8.5.1 are connected to a light. Sensor status is working, but light.entity name is not working in the newest update 2022.2.2
Did not find any logging errors, none?!? Someone else had this or seen something similar?
I have problem with rename device or change place. In interface button for save not active, if reload page button active but not save changes. Try use other browser no lucky.
Restore 2021.12.10 version - no problem.
1 Like
Regarding " The Legacy “Works With Nest API is deprecated and support will be removed in Home Assistant Core 2022.5 "
I have set up a work around that will keep functionality going for a while after 2022.4.x.
I had a spare Raspberry Pi running a very basic instance of home assistant attached to an APC UPS sending status information via “Network UPS Tools” to my main instance of home assistant.
Given I never need to upgrade this remote instance as it just works, I decided to transfer my Works with Nest integration to the remote instance that will never be upgraded after 2022.4.x.
I then installed HACS on the the remote instance and then a custom component called " Remote Home-Assistant " https://github.com/custom-components/remote_homeassistant
With “Remote Home Assistant” installed on both my Home Assistant instances I am able to retrieved all of the states from my Nest Thermostat and my 2 Nest Protects from the remote instance.
I am also able to control things like Temperature , Heat on/off and Home and Away from my main ( updatable ) instance of Home Assistant.
1 Like
not_currently_trying_to_reboot_the_shelly 
4 Likes