Nothing changed. Triggers remain or.
1 Like
No, fix is needed to keep a code consistent with a new syntax.
The code may be passed to some other person who has no idea about old syntax.
1 Like
All of the following fail to start for me:
- hildebrandglow_dcc
- alexa_media
- uptime_kuma
- monitor_docker
- esxi_stats
- watchman
- pirateweather
- eufy_security
In the log file I get lots of messages like “Unable to install package… failed to create file /tmp/uv-…lock”
Going to have to revert back to 2024.9.3
Running HA in Docker, and using the venv setup to run as a specific user.
Should be converted automagically when hitting Save according to the release notes:
“Automations managed by the automation editor will automatically be migrated to the new syntax when saving an automation”
Still core install, tried several things :
- uv in global (instead of venv) : finds uv but can’t install packages at run time
- install HA in venv with uv pip install … same error
- install HA as a uv “tool” with uv tool install homeassistant : HA will not even start
Reverting to 2024.9.3 and will try again tomorrow after reading this thread !
2 Likes
In all my yaml packages ?)))
No dude, the post makes it pretty clear. Automation editor, so UI automations only.
Your original point of “The code may be passed to some other person who has no idea about old syntax.” led me to assume that a reasonable person would create their automation in the UI while pasting the code in yaml.
“Dude”, ofc I understand that this is about UI-driven automations only.
Means - your statement about “automagically converted” is not related to yaml-config.
Why do you think so? ))) Many many many users use yaml as the basic way.
And automations may be passed to another setup along with other yaml-defined entities as a package.
Edited my comment to clarify while you were typing. Check again please.
Oh yes, this was ABSOLUTELY needed! I started using Home Assistant in the era of:
condition:
condition: or
conditions:
- condition:
And between this new syntax and the previously implemented condition shorthands, I think I’m FINALLY getting to the point where I don’t need to look it up everytime I code it!
So thank you thank you thank you thank you to all the developers for the ongoing quality-of-life improvements.
12 Likes
One more core installation that is spewing FileNotFound errors into the log looking for uv. Successfully rolled back to 2024.9.3.
Welcome, I am not saying that I hate/dislike this change - I only do not consider it as important.
Ofc using plurals makes the code more logical - like we say “views” & “cards” in lovelace.
We all have different definitions of “Many many many” 
2 Likes
This is not about a particular number or percent, this is about “some significant number of users are affected”. I think the issue can be closed.
It’s a path issue, adding the environment line to my systemd file worked for me.
[Unit]
Description=Home Assistant
After=network-online.target
[Service]
Type=simple
User=%i
WorkingDirectory=/home/%i/.homeassistant
ExecStart=/srv/homeassistant/bin/hass -c "/home/%i/.homeassistant"
Environment="PATH=/srv/homeassistant/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/homeassistant/.local/bin"
RestartForceExitStatus=100
Restart=on-failure
[Install]
WantedBy=multi-user.target```
12 Likes
Same for me
1 Like
Tibber integration still broken? Haven’t worked for me since 2024.8.3.
Is there anyway to make the Heading Title (not subtitle) go back to the same size was it was in prior releases?
yes, you can set the variable
ha-heading-card-title-font-size: in your theme to any size you like
see frontend/src/panels/lovelace/cards/hui-heading-card.ts at 67217b9dd0f5ad43aafb3bba2fe2821407b25243 · home-assistant/frontend · GitHub for the used theme variables in the heading card
2 Likes
Another Core user with that issue and your solution works! 