the new install/skip on the new update entities are great…
until you accidentally click install on an OS update, which you really wanted to skip.
Happened to me this morning, when my phone slipped out of my hand. some sort of “Are you sure” would have been nice, now I am running a beta OS and am not sure I like that just yet…
warrants a Frontend FR I guess…
You can downgrade using the CLI.
yes, in an ideal world we can. Thing is, I have encountered a few ‘bricked’ Rpis before when updating the OS and because of that am very cautious updating them. Always check the issues on the OS GitHub repo first etc etc, and, wait a bit. Its way more impactful than updating Core (of which I run the dev nightly, and never have any issues with)
A confirmation on an OS update would be very welcome because of that.
I don’t think that changed. Depending the state of the loaded frontend you either see the technical internal name (which is still “hassio”) or the nicer translated end user name.
Hi Philip, good you’re here 
could you please have a look 1 post up, and see if a FR/Discussion on this could be considered?
In the end not up to me, but I would agree with that proposal => Frontend repo discussion would be the way to go
thanks Philip, consider it done
Just to amplify prior comments on this release…
It would seem that community shared blueprints shouldn’t happen within HA if HA updates are not going to be checked against the code shared blueprints use. We use HACS at our own risk with warnings at installation, in the interface and in the logs. Updates to HA that break HACS are the problem of the user and the great people who maintain their HACS custom integrations. Shared blueprints are downloaded and used without warnings and there’s no one to look to for assistance if the creator loses interest in their creation.
For my part, I have found the new release didn’t break the remote nor native code to make it function. For me this is not a ZHA hardware problem. The advice to create and maintain my own blueprint makes sense.
The toast says the id of the component that is being loaded. The Home Assistant Supervisor component has id hassio. It’s not referring to Home Assistant (i.e. core) as hassio, its referring specifically to the Home Assistant Supervisor component within core.
It probably should say supervisor but it would be tricky to change that now.
Just want to note here that I wouldn’t expect the beta to fix it permanently. I have a system on the dev channel and even I’m still seeing it periodically. It’s being tracked as an issue here.
My belief is that this is happening because a change in the hassio component of core in 2022.4 caused supervisor to start checking every addon repository for updates every 5 minutes (whereas it used to do that every few hours). My guess is github is not happy with that (checking for updates of an addon repository means cloning that repository). That is being tracked as an issue here and a PR has been opened to fix it. My current plan is to wait for that PR to be released in a patch and see if this error goes away. If not I’ll dig into it then.
Dude, ZHA is software, Zigbee controllers/USB sticks are hardware. Hardware needs care and feeding as technology moves forward. With matter on the horizon your Zigbee hardware needs to be able to support the Zigbee 3.0 stack. All of this connectivity stuff is constantly changing. Personally, I run zigbee2mqtt with no issues, but my hardware is all been flashed with the latest code… Just sayin…
I have the same problem. These are not sensors that can have the units changed.
These are forecast entities, so they have multiple units and there is no option to select it. Also, it actually says “F”, although the values are clearly in Celsius.
Same problem as well.
Hello,
I’ve noticed some automations partially failing since the update and I’ve isolated it to the same action in all my automations. I didn’t see where anybody else reported it but I’ve now found this same problem/behavior in a handful of automations since the update.
Just a standard notifier, nothing fancy:
alias: Notification - Sirens
description: ''
trigger:
- platform: device
type: turned_on
device_id: f17ba481f86c6bd84f78f73c0695a005
entity_id: switch.front_door_siren
domain: switch
- platform: device
type: turned_on
device_id: cb95387116e5bee33a6f03091a4b2676
entity_id: switch.garage_door_siren
domain: switch
condition: []
action:
- choose:
- conditions:
- condition: device
type: is_on
device_id: f17ba481f86c6bd84f78f73c0695a005
entity_id: switch.front_door_siren
domain: switch
sequence:
- service: notify.mobile_app_serge_s_s9
data:
message: Front door siren has been triggered
- service: notify.mobile_app_iphone
data:
message: Front door siren has been triggered
- conditions:
- condition: device
type: is_on
device_id: cb95387116e5bee33a6f03091a4b2676
entity_id: switch.garage_door_siren
domain: switch
sequence:
- service: notify.mobile_app_serge_s_s9
data:
message: Garage door siren has been triggered
- service: notify.mobile_app_iphone
data:
message: Garage door siren has been triggered
default: []
mode: single
Something happened to all the notifications for the iPhone only on several automations. All the automations were setup the same and the notifier for the android device and iPhone was configured identically before the update. But now, they are all showing in the UI as:
As I type this, I myself am having trouble believing what I’m describing but I’ve now pulled it up on 4 automations that were all configured identically prior to the update. The way I found out the automations were failing is because the subsequent sequences (after the iPhone notification) were failing. They all work fine as long as I reconfigure them how they were (same as my android) but I’m trying to figure out if there’s an underlying problem that has caused/will continue to cause this.
What on earth is going on in the dev team here guys? I started using home assistant (core) a couple months ago and love it, but after reading through this thread I am definitely staying on 2022.3.8
The breaking changes in this release are huge and there appears to be a huge shift in fundamentals that are very much opinion based.
I am a developer and I am all for UI improvements, but at the expense of YAML config for advanced users?
The space for HASS in the “smart home market” is literally to cater to advanced users, I am 100% sure that’s why we’re all here instead of using any of the mainstream options.
I don’t really understand this big shift to deprecate YAML code in favour of UI + sqlite. Why not add more UI to MANAGE the YAML code?
I’ve seen some comments saying it’s for “performance” but what’s wrong with loading YAML files into memory and writing changes as needed?
After all, the recent deprecated YAML code e.g. groups will not be something the user changes often enough for loading/writing YAML code to be a performance impact.
I’m not trying to be self-entitled, as I said I am a developer and I am happy to help out (I also fund any devs on here I like via buymeacoffee) but these changes are opinion based and not a result of a lack of devpower.
Edit: Considering the breaking changes in this release, it also seems to have been rushed out way too quick for custom component devs to catch up, have you hired Tim Cook over there?
As I wrote further above: It will say “Supervisor” or whatever the user facing integration name is, depending on the loading state of the UI. The coding for that is already in place.
For that to work however the translation frontend logic has to be loaded / available already. During the initial start of HA that sometimes/often/always (?) is not the case for my instance, but if I have the fronted then already open and loaded and then restart the backend, the translated integration names are shown during the reconnect.
After i put everything back together last night, everything broke again. But what I thought was the first time now appears to be an incremental value change to the iphone device name.
yesterday when I discovered the issue, it was previously configured for ‘iphone’. Yesterday when i fixed it, it said ‘iPhone2’. I thought this was strange but didn’t think anything of it. This morning, it changed again breaking the automation and there’s now an ‘iPhone3’ in the box where I’m trying to reconfigure the notification.
Hm it seems like your iphone is regularly registering as a new device instead of locating the existing one. I’m not sure why that would be but there’s a repo specifically for the ios app. I would recommend submitting an issue there if there’s not already one about this.
Also rather than changing all your automations, just rename the phone (delete the _number) in the entities list.
