2025.11: Pick, automate, and a slice of pie 🥧

[Thyraz]

As far as I understand:

You should use WOL, as an automation trigger (which means a trigger statement for the automation you should create according to the docs, no idea how to explain that more clearly ) as in the past, to get a “power on” functionality.

But if you missed that in the past and have no way to power it on, you will be presented with unavailable as a state, as you can’t power it on.
This seems to be the behavior that HA suggests for devices that can’t be turned on by HA based on the PR text.

edit: just to be more clear about that:
As long as you use an automation to power the TV on using WOL as suggested in the docs, there is no breaking change for you.

[dedi]

This Telegram notification migration is confusing. The link in the docs (Telegram bot - Home Assistant ) “Please use notifiers instead.” is not working.

I think I have figured out the necessary changes, but I am not certain. The repair note should be more descriptive. It would be helpful if it specified:

• What configuration needs to be removed from configuration.yaml.

• That the new method uses notify.send_message.

• How the new targets function post-migration.

This also brings up a general question: Why can’t automations be migrated automatically when these underlying services change?

[mchk]

I still can’t understand the developers’ logic, why clicking on the target picker doesn’t allow editing the existing value (which is standard behavior for similar fields).

[wolf99]

Thanks!
I have an automation that is triggered by the TV being requested to turn on, then WakeOnLAN is the action to turn the TV on.

However in v10 the TV shows as “unavailable” when it is off. Which seems to contradict what is mentioned in the related PR…or does it mean that this PR fixes that so that it shows off instead (if I have the automation mentioned above)?

Perhaps @thecode can clarify maybe.

[tom_l]

My advice would be to ignore the repair and don’t change anything (you have six months until this becomes a problem) until this is resolved: Add notify_target parameter for Telegram bot actions by hanwg · Pull Request #154868 · home-assistant/core · GitHub

At the moment there is no way to use the new notify entities that are created with the new telegram_bot.send_message action, you have to use the numeric chat ids.

@dedi

Why can’t automations be migrated automatically when these underlying services change?

Because HA never changes your yaml (this is a good thing). Even after an automatic migration from a YAML to a UI integration it is up to you to delete the old YAML.

[bacco007]

@Eoin

I’m also unsure why a change like this is buried at the bottom of the release notes.

It would be nice if there was some warning before the release (and the beta) for breaking updates that are planned.

I get that there are sometimes the need for breaking updates that are unavoidable and outside of HA’s control, but where neither of these applies (which this seemingly falls into), it would be nice to know in advance so people can make any adjustments.

[allard77 (Allard K)]

I love the new automation editor. I also love that you are still concerned for Pi users with SD cards instead of soft-forcing people to use newer bigger better hardware.
I don’t quite understand why the option is not offered to keep log files in an independent file, like before. It kind of reminds me of the backup story earlier this year. Taking away a feature that is popular with advanced users without offering an optional replacement. I’m sure a similar win-win solution can be found to release next month.

[dedi]

@tom_l

Because HA never changes your yaml (this is a good thing). Even after an automatic migration from a YAML to a UI integration it is up to you to delete the old YAML.

It does, when you edit an automation . I have a few ideas for how this could work. One solution would be:

• List all affected automations in the “Repairs” section or specific popup.

• When I click one, it takes me straight to that automation’s editor.

• Inside the editor, the exact part that needs changing is highlighted, with a “Migrate” button right there.

(That highlight and migrate button should appear anytime an automation needs migrating, even if I didn’t open it from the Repairs dashboard.)

This approach lets you migrate and test each automation one-by-one, avoiding a risky bulk YAML change.

You could still have a “Migrate All” button in the Repairs section, perhaps for after you’ve tested one manually and confirmed the fix works.

I know building these migration tools takes developer time, but the time saved by users would be immense.

I’m sure tons of people would appreciate making these migrations easier. It’s just an idea.

[tom_l]

@dedi

I have a few ideas for how this could work

Build software better, together

[jojo01fr]

Alexa failed to login, rolled back to previous and its the same, cant login.

[sparkydave (🇦🇺 Dave)]

@jojo01fr

rolled back to previous and its the same,

Guessing the issue is elsewhere then…

[GrizzlyAK (Shane)]

Thanks for this, Petro. This change was sure buried deep. I understand why it is being done, and I appreciate any help in preserving my SD cards, but not sure I agree with this not being listed in breaking changes, since I’ve used that file forever to pull into UltraEdit to troubleshoot. It would have really sucked to suddenly not be able to find it.

Based on the original PR, I assume (and it appears) that the UI-provided log has the same information as this log file, and would be found in the Core log?

[petro]

The live UI logs do, yes.

[GrizzlyAK (Shane)]

I have no automations built using the UI. All of mine are still in YAML. One reason I keep using YAML is that I comment the crap out of my automations and I can’t do that in the UI (or I couldn’t when I tried it). In my first tests of migrations long ago, all comments were stripped, which I considered very uncool. I know it’s extra coding, but seems it should be pretty simple to have comment blocks that are ignored by the UI code, but maintained. Even non-coders might want help remembering what they did 4-5 years ago. Once the UI can accommodate comments, then I’ll be happy to use it.

[SteveDinn]

One reason I keep using YAML is that I comment the crap out of my automations and I can’t do that in the UI (or I couldn’t when I tried it). In my first tests of migrations long ago, all comments were stripped,

@GrizzlyAK I know this is a kludge, but you can have comments in templates

{# this is a comment #}

[Ildar_Gabdullin]

Or in alias.

[SteveDinn]

I get the reasoning behind having the person entities use the zone friendly names for their states, but it would be awfully nice if we could also have the entity name of the zone as an attribute.

I sometimes name multiple clustered zones that have the same friendly name in order to have irregularly-shaped zones. It would be nice to know exactly which one the person was in

[nilsreiter (Nils)]

The Shelly integration now supports climate and valve entities. Thanks @thecode

How is that new? I have a Shelly TRV which is exposed as climate entity for some time now.

[jcmleng]

Great release as always!

I initially thought that the addition of the total consumption on the top right of the energy cards made sense. But it now adds 10-15% more height to the card, and the space entirely to the left of the total is now completely wasted - this does not feel like a good use of very valuable dashboard real estate.

Can there please be a parameter in the energy card to provide the option to turn off the display of the total consumption? Or alternatively, to add other related buttons or fields so that the real estate to the left is not totally wasted.

Many thanks …

[tom_l]

@GrizzlyAK

I comment the crap out of my automations and I can’t do that in the UI

@Ildar_Gabdullin

Or in alias.

Yeha that is exactly what the alias is for. A description/comment for every block.

I still use YAML though as I find it faster and a whole lot easier to read.