But we are talking about version aren’t we? (Maybe we aren’t!) But you are right, updater is in default_config.
That’s the confusing part 
Which version? I have 3: Running, Available (and docker image version, but that’s just mine)
Running:
- platform: remote_command_line
name: HA running version
scan_interval:
hours: 6
command: >
cat /config/.HA_VERSION
Available:
{{state_attr('binary_sensor.updater', 'newest_version')}}
EDIT: IIRC, the updater fetches the available versions once or max twice a day, not like every 30 secs
It is on the list. I checked
Só I assumed that the updater changed if there is a new core update but it doesn’t (anymore).
Tô be more clear I have only used the standard available configuration for this. I have not build my own binary sensor for this.
Sure? See above. It can take up to 1 day before the updater is… updated.
I will wait for the next update. I think I am faster then the updater…
Please upgrade to latest version. This should be resolved for all core integrations in 2022.2.7. PR #66379
Version does not appear on its own. You did add it. It is not in default_config.
I am at 2022.2.8
I didn’t unless you consider the installation of homeassistant on a rpi an installation of updater as well.
Weekend guys. Enjoy !
I rest my case😉
You don’t seem to understand that updater and version are two different things.
Vs
2 Likes
.9 came out less than 24 hours ago(Github says 3:52PM EST yesterday for the core release). After core builds, they build all the images based on it (docker, board-specific OS versions). Give it until at least 5PM EST today to see if updater and version just haven’t tripped yet. You 2nd screenshot above is the NEW with 2022.2 consolidated update checker and I’m not sure how that mechanism triggers yet (it’s only available on HA OS, and so I don’t have it on my venv). It may look more often than once per day, or it may be triggered by visiting the configuration section. I know it can be manually triggered by going to the three-dot menu.
Yes, my forehead is rather low and my eyebrows are one connected line and on top of that my hands hang just besides my knees.
What you doesn’t seem to understand that I didn’t add or change anything and after the updates it stopped working where it used to indicate nicely that there was an update available. So I don’t think that I am the problem here. It’s always a pleasure to try to help and get p@@@@d off!
Ciao guys!
At least with the most recent release, it still hasn’t been long enough from 2022.2.9’s release to be sure the updater component (which only updates at most once per day) is at fault. Give it another 4 hours or so and see if it has changed. If not, I recommend filing an issue with all of the usual requested information, as doing so may allow you and the developers to work together to reveal more light on the subject - maybe it’s your setup, maybe it’s the integration, maybe it’s a unique combination of the two.
Of course I spoke too soon:
1 Like
Same here, running Core on OpenBSD - 2021.12 was (is) running fine. The code now explicitly checks for Linux et.al. (found the line in main.py) - apparently, the developers really do not want people to even try and run HA on anything else… 
1 Like
…aand I can confirm that - at least for what I am doing with it, which is not very complex - 2022.2 runs just fine on OpenBSD 6.9, once you remove the OS check from __main__.py
1 Like
I need to correct myself - it is possible to avoid the OS check. One can simply add the command line switch --ignore-os-check when calling hass - see also Validate operating system is supported by emontnemery · Pull Request #64352 · home-assistant/core · GitHub
1 Like
Still get that crazy “My My My My My My Home Assistant” showing up on my tab still.
I agree with the addition of the unknown state for binary sensor, but I came across a curious case. I have this event-base binary sensor defined:
- trigger:
- platform: event
event_type: amcrest
event_data:
event: CallNoAnswered
payload:
action: Start
binary_sensor:
name: Doorbell Rang
state: true
auto_off: 5 # seconds
After an HA restart, the state of the sensor is unknown and will remain so until an event has fired (which will turn it on, and then off 5 seconds later). I would argue that for a sensor like this, the unknown state should never be used. The sensor is only on if the event was fired and otherwise off.
I would like to get some feedback on this, but I think I’d like to log this as a bug or improvement.
Also, would there be any potential workarounds?