I’m having problem with “flux_led”:
Platform error light.flux_led - cannot import name 'ATTR_WHITE_VALUE' from 'homeassistant.components.light' (/usr/src/homeassistant/homeassistant/components/light/__init__.py)
My code in configuration.yaml:
light:
- platform: flux_led
devices:
192.168.0.XX:
name: LED Mesa
protocol: "ledenet"
mode: rgb
I’m not sure if you’re already aware, but I haven’t found any thread talking about it.
Its not the version of ha you need to watch, it’s the shelly for hass custom component that needs to be fixed.
The firmware updates on the release notes refer to zwave, not ZHA or zigbee2mqtt.
Zigbee2mqtt has had OTA firmware updates for a long time.
zigbee2mqtt has better firmware update support than ZHA (I’ve used all 3 and much prefer Z2M)
Exactly. Everyone can see what it is, that’s why the tooltip should better describe what’s its purpose.
You’re using the custom integration for flux_led. That’s why no one is talking about it, the built in flux_led integration does not have this issue as it has never used a white value attribute.
I really want to like the new automation editor screens. I really do want to. But I find them very difficult to use. I find myself even more switching to the yaml screen now just to ‘see’ what’s going on. Too much is hidden.
I also find it funny that the new UI almost FORCES you to comment your code in order to be able to understand it (rename the lines with aliases) where-as the old UI (before aliases became more prominent) made it almost impossible to comment your code. lol.
Maybe it’ll grow on me when I get more ‘aliases’ in the code for readability in the UI.
nothing changed with mobile app notifications this release. Did you update from an older release? Are you SURE you’re using the correct notification platform? I.e. did your mobile app notification object_id change? e.g. notify.mobile_app_abc to notify.mobile_app_xyz.
Mine does this but not as consistently as yours. Its much more sporadic and happens ‘less’.
Option to rename the automation directly from the right side menu would be useful.
Wow, indeed that was it! This was one of the first devices I put in my installation and at the time I didn’t really know what I was doing. Now I’m using the right integration, thanks!
Is it known that some users using Home Assistant Supervised cannot update to a new release of HA since the July release? At least not if they want to continue using AppDeamon. This only gives an error message on Supervised. On HASSIO (Raspberry) it runs fine. There are now 3 issues created that were probably overlooked during the vacation season:
Let’s put it this way: We miss Frenck!
I have the same problem. The previous syntax no longer works. With your solution of removing the “-”, all devices in my account get the message, even those that are not specified as a target.
I had the same experience. Same mqtt.publish error message after upgrading to 2022.9.1, Reverted to 2022.8.7 and seems to be working OK. Did anyone find a fix?
Update: Just capturing this here in case it helps anyone else who had similar issues. Prior to upgrade on 2022.8.7 I had already made the changes to the new mqtt yaml format, had no MQTT errors in the logs, no VSCode warnings, and no repairs identified.
After upgrade to 2021.9.1 I still had no errors in the logs, but now had a repair telling me my automation that used mqtt.publish needed fixing. Developer tools showed mqtt.publish was available. I commented out all of the automations using mqtt.publish and restarted. The repair message remained with its original timestamp. I clicked the button text in the repair at the bottom right of the repair message, can’t recall whether it said “Fixed”, “Dismiss”, or something else, and the repair notification went away and has not returned. As best I can tell, my mqtt.publish automations were working the whole time.
I am now wondering whether the Repair message itself is incorrect and there was no underlying issue needing repair.
PS: Thank you mobile.andrew.jones for your swift reply to my original message.
Yes!
Check if you are still using manual mqtt sensors, switches etc that have the line - platform: mqtt as we were warned in 2022.6 this would be removed in 2022.9. Here we are at 2022.9, so if you have not moved to the documented new way to have manually configured mqtt entities, then the entire MQTT platform will fail to load because - platform: mqtt is no longer supported.
seems home assistant needs a “real production stable” update channel …
like for others, this update broke HA for me.
node-red is not getting any devices/entites from HA anymore, as well as MQTT is broken.
main problem here is: this is not a beta.
how in the world are we supposed to update production-setups? waiting for the next release, with other bugs? how should we update systems where we are not on-site?
damn, looks like there is no real clue of when to roll out a stable release.
by the way, i have not configured mqtt manually. only ui.
MQTT is not broken. If people had followed the warning that had been appearing in their logs for the last several releases.
Once you do as you were told to do - which is to move all your sensors, switches, lights, fans etc that are using platform: mqtt to the new MQTT format of:
mqtt:
switch:
sensor:
binary_sensor:
fan:
light:
then things work fine.
It’s just that people have been ignoring the warnings in the logs, and more recently in the repairs menu - until the system actually stops working.
repairs menu told me just yesterday, right before update, “nothing to repair” 
Do you have mqtt entities still using the format:
sensor:
- platform: mqtt
?
for MQTT no, like i said, just UI, not manually.
so do i have to add this new format now manually?