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?
Feedback - the changes to pigpio Daemon PWM LED daemon 1.5 broke my home ventilation system. They were functioning via variable speed functionality of PWM extraction fans. I built a custom interface to do this. I reverted to 1.4 and rebooted. Now it is working again, I did not investigate root cause as GPIO is being deprecated in HA. I wont upgrade again until I am clearer about support for using GPIO on the same Pi as HA. Fully variable fans - controlled by a low voltage PWM signal, are easy enough to integrate via the GPIO interface and the PWM outputs from a Pi. I thought I could move to a Zwave PWM controller, but these look like they will not work (for various reasons). My options could be bringing up a second Pi for this purpose and integrating with MQTT, or moving to (3) speed fans and a Zwave switch.
Since nothing has changed the reason it’s not working for you right now is not the depreciation.
As the documentations say, 2022.06 is when it will be removed.
I’m also getting:
Configuration of the Version platform in YAML is deprecated and will be removed in Home Assistant 2022.4; Your existing configuration has been imported into the UI automatically and can be safely removed from your configuration.yaml file
I’m looking at the configuration.yaml file and I can’t figure out what needs to be removed. There is not string “version” (regardless of case). What needs to be removed?
1 Like
I would like to know about this as well.
version: is part of default_config: so maybe the error is being generated from that. Either way as long as you don’t have version: in your config you should be fine (now found in the Integrations UI). I’m sure they will fix the error generation.
Actually version: is not in default_config
updater: was, but is deprecated and has been removed from default_config in 2022.3.0.
Yeah sorry. I was questioning myself as I typed it!
I had to look it up three times while posting my reply. I have so many tabs open it becomes even more confusing!
Scenes now have states. What would i put in my trigger for an automation to fire based on scene being activated? i have tried on, active, reloaded… not triggering… The logbook just shows the date when i look. Anyone using this?