Seems safer to me to wait until next month…
Also: since I use a lot of yaml in packages, it seems that I have to crawl all the code to update to the new syntax, so I need to plan some time for it…
You don’t need to update anything for the yaml changes. I have no plans to update my files.
It is mainly needed only in case you are sharing your code with beginners who has no idea about the old syntax.
I’ll try to explain but I did these automations a long time ago lol.
I have a mix of Aqara and Linkind buttons. They have their own specific actions they send.
Here is how I use an aqara button action value in an automation…
Value Description
single = toggle lamp on short press
hold = either dim or brighten lamp while button is held on long press
release = change between dim and bright mode for hold action when long press is released
double = toggle ceiling light
These all continue to work fine because I trigger on a specific value.
What did break is I was triggering an automation on any state change of the action button. This would disable the motion detector in that room for 30 minutes on any press. Now when the button action value changes to “unknown” it triggers that automation. That would be whenever z2m sends a status update for the device.
So I can see how this would break automations and blueprints as noted in the other replies.
I’m testing a workaround of creating a manual mqtt sensor in yaml set to disregard the null value.
1 Like
You could simply ignore state changes to „unknown“, only the other values would then trigger the automation 
Thanks, I may end up doing that. But I am kind of against using the MQTT integration sensor that is going to unknown on z2m device update messages.
I think this manually created mqtt sensor in the config file using “is not none” will work for me. Sort of just the same thing as your suggestion.
# send value if it is not none else send empty string
- name: "Test mikes zigbee button action"
state_topic: "zigbee2mqtt/Mikes Room Zigbee Button"
value_template: '{{ value_json.action if value_json.action is not none else "" }}'
I’m having issues with the 2024.10.2 release and the tp-link integration. I see in the release notes that python-kasa was bumped to 0.7.5. Upon restoring to backup of 2024.10.1 the issues resolved. Logs are floods with disconnects and reconnects.
When updating from version 2024.10.1 to version 2024.10.2, multiple HACS integrations failed to setup after the reboot.
I am trying to revert so my backup if version 2024.10.1 now.
Anyone else seeing this issue?
That’s a big leap. Lots of things have changed. Revert to 2024.2.1 and check if everything’s OK. Then upgrade incrementally to each last version of every month. Make sure to upgrade all integrations and fix every issue along the way.
Yet you post no logs
Sorry. I made a typo. It was just an update from 2024.10.1 to 2024.10.2.
1 Like
I am on 2024.10.2 and waste collection schedule is all ok here. So is ics calendar.
What is your install method.
No issues with Watchman on 2024.10.2 - but it was reported in your list
Home Assistant OS on a Yellow.
Not my usual debug method, but try restarting core.
Installed the NYT Games extension. Why wordle streak and best is expressed in a date type hours??? Nobody need it, just spit out a integer of the days!!! It’s just ridicolous to have to make a template sensor for something like this…
Click on the entity to get to its settings. Change the unit. That’s the beauty of display preferences: everybody can choose. No need for a template sensor.
1 Like
It’s possible he’s complaining about the duration device_class which just ignores all entity/unit settings and displays HH:MM:SS.
1 Like
In the end I had to reinstall Home Assistant on my Yellow and restore my backup. After this the update to 2024.10.2 went smoothly.
I don’t know why Home Assistant failed like this. It never happened before. Glad I backup regularly.
anyone else notice their pi running warmer than usual? after updating to 2024.10.1 (and 2024.10.2) my CPU was never dropping to 0% idle. htop reported two threads using most of the cpu:
- wyoming protocol integration (>10% cpu)
- and a thread of “python3 -m homeassistant --config /config” (1-5% cpu)
not sure if this maybe broke something, but when i first updated i had a warning for an esphome assist_satellite entity not being supported anymore (related to M5Stack Atom Echo) so I clicked “fix” to make it go away. been seeing something in the error logs about assist_satellite.py
I believe my memory usage has increased a bit since update as well, and I just had to restart due to system locking up with 98% memory usage (leak?). disabled the wyoming and esphome (m5stack) integrations and cpu/temp has at least returned to normal.