Same here ! Renamed yaml in blabla.yaml.disabled (I often do this to test…) and groups are still here after a reboot 
Can’t find a solution yet !
Issue opened : Can't delete YAML groups ? · Issue #69496 · home-assistant/core · GitHub
I have read the blog post and this entire thread. You have proved my point by pointing to issues file on the localtuya github which is where the failure belongs.
These are prepopulated entities from either ZwaveJS or DeConz.
You didn’t answer the question!
This screenshot looks like it’s from a previous version version of HA, a clue being that the “Enable entity” functionality has been moved to the advanced settings. Are you sure you’ve actually updated to 2022.4? If so, have tried to refresh/reload the frontend?
Here’s what my 4-in-1 Sensor temperature entity looks like:
Working fine here
Ha! OK, figured it out. My browser was cached to the previous version of HA. Closed, cleared cache, re-opened and all is there. Thanks!
I told the WLED update entity to skip this release, and the update turned off, but only for a while. It has come back on at least 5 times in 2 hours, so the “skip this update” functionality doesn’t seem to work quite right.
2 Likes
I have some centralite zigbee switches which show up as lights for some reason. I have one attached to a fan…
What you described has only ever existed in the form of automations and scripts. Nothing else is UI/YAML interchangeable.
After I updated, Synology DSM completely stopped loading. After multiple reboots with the same result I removed the integration completely, rebooted and had tried to log back in. No success. I logged into the NAS and verified I was able to connect so the last thing I checked was active sessions and there was still a hung session. I killed the session and was able to install the Synology DSM integration in HA successfully.
Now it seems that the switch entity that is supposed to be available to enable/disable the Surveillance Station Home mode is gone.
Adjusting long-term statistics for items like solar spikes “works” but seems could be better.
The spikes are still there, they now just have an added negative value… do wonder why the actual value is not changed rather then just adding another db entry to make the global statistic tally correct ?
Hue “rooms” and “zones” are just ways to (usually, maybe always?) create Zigbee groups, and “groups” is also the terminology that the Hue v1 API uses/used for this and that they are likely carrying over here, too (even though it looks like the v2 API separates them more clearly). In any case, the issue is that the v2 API, which Home Assistant recently switched to for Hue Bridges with sufficiently new firmware, had very limited group support, basically just sending on/off commands. Now you can do color, color temperature, etc., depending on the capabilities of the devices/group.
Reporting out on the v2 API side is still more limited than v1, but it sounds like they don’t plan to address that, which I can sort of understand (if they aren’t all the same, does the “average” color or level of a group mean anything? and you can still see individual lights). Not sure how HASS is handling that, or why the v1 API (which still works, though they do plan to eventually remove it–if they do what they say) wasn’t used as a fallback in combination with v2 for new features (real-time status updates being the one most people probably care about), but that’s how it is now. 
BOND integration, all fan entities are unavailable. light entities are valid.
Logs? Where are your logs?
I have the same error.
Also with no openhome.
Also there were changes to bond/fan.py and bond/cover.py yesterday which are not in 2022.4.0. Maybe they fix this, I don’t know.
If localtuya is not working after upgrading to 2022.4 here is a quick fix
Quick fix:
Seems like the issue is with the fan platform, if you do not use the fan platform, you may exclude it from the config flow temporarily until a correct fix
in custom_components/localtuya/const.py line 49
change:
# Platforms in this list must support config flows
PLATFORMS = ["binary_sensor", "cover", "fan", "light", "sensor", "switch"]
to:
# Platforms in this list must support config flows
PLATFORMS = ["binary_sensor", "cover", "light", "sensor", "switch"]
The database migration lasted for about 10 hours. During that timeframe home assistent wouldn’t allow me to manually reboot HA because (warning message that DB upgrade was ongoing).
I restarted the core after DB upgrade and it look likes ha is working now. Note that no events, state changes have been recorder and when you look at the history there is a 10 hour gap. Restarting ha seems to have re-enabled recording.
My ZHA network went down in flames with the 2022.4 update. After a few hours trying to fix it, I gave up and downgraded to 2.3.8 doing a full restore from last night’s backup. Trouble is that some ZHA issues still linger (they were not present last night) and a number of History cards now say “History Integration disabled”. If it is a full restore, then why aren’t thing just like they were before the 2022.4 upgrade?
I do have another HA setup but it doesn’t have any zwave or zigbee devices and I am reluctant to add radios on it to avoid interference… so how would I test an upgrade to see if it causes major issues such as in this case? My test setup is not configured to do much and is running on an RPI while my production setup is running on an i7 tiny PC in a proxmox vm.