The entity_id you see there is the config entry_id. That will never quit working. It’s the backbone of identifying entities at startup and it’s a truely unique id that represents an entity. It’s more robust than entity_id itself. But it’s a pain to work with in yaml.
Typically they are real issues, but users have to identify the integration (or app/addon) causing the problem for anything to be done to fix it.
I’m not following, the “entity_id” here isn’t in the device registry or config entries files.
type: temperature
device_id: e4f885d038beb56e1c20ac690ebc7972
entity_id: 34f46c09b765caf5397b9f8d549e192d
It is here in the entitry_registry, with a different config entry id. And those IDs (device_id/entity_id) are both in the same entity registry record:
"id": "34f46c09b765caf5397b9f8d549e192d",
"config_entry_id": "01KH9XE8363KHMYGC0BAS27GF6",
"device_id": "e4f885d038beb56e1c20ac690ebc7972",
"entity_id": "sensor.deck_temperature",
The related config entry has:
"domain": "switchbot",
"entry_id": "01KH9XE8363KHMYGC0BAS27GF6",
"minor_version": 2,
"title": "Indoor/Outdoor Meter 420D",
"unique_id": "d8bfc246420d",
And the device registry references the same config entry:
{
"config_entries": [
"01KH9XE8363KHMYGC0BAS27GF6"
],
"id": "e4f885d038beb56e1c20ac690ebc7972",
Right, I misspoke, it’s the entity registry id. Regardless, it’s the identifier that HA uses to identify an entity.
Not trying to harp on this, but wondering if I’m missing something (and back to the original comment)
Does this:
behave differently in some way than this?
trigger: numeric_state
entity_id:
- sensor.deck_temperature
above: 60
Besides that last trigger won’t break if the device is replaced.
I guess I’m wondering if there’s something else I’m just not understanding about the benefit of that first trigger. Or since both “id” (“entity_id” in the first trigger) and the entity_id in the second one are both unique IDs for the sensor, did the developer just get lazy and not pull in the “sensor.deck_temperature”?
You’re not missing anything. It’s just how the old device triggers worked. It was front and center for ~5 or 6 years in the UI, and now it’s not. You’re really just over thinking this.
It was intended to be more approachable by new users who only use the UI. That’s the main difference. Functionally they are the same.
Hi @petro - are you referring to Make device identifiers and connections unique per config entry instead of globally unique · home-assistant/architecture · Discussion #1226 · GitHub ? Is there any more detail on the meeting mentioned that was held on the 16th July? I dont’t feel the reasoning is explained in detail - a lot of questions and proposed alternatives (eg simple adjustments to the UI) are not really responded to with explanations.
I completely understand that the developers (who do an amazing job) don’t owe an explanation but I am just wondering if there is more detail on the discussion or future road map that explains this speeration of devices.
Yes that’s the discussion, there’s an explanation right there in the “background” section.
Mucking about with the live json files and overwriting them live with kludgy hacks is not a usability feature.
I had planned on skipping this update but forgot and hit update. I definately regret it. Tons of “replacing” in automations. It would be one thing if it was just a “replace” but it wipes out all the settings for that device in the automation.
Honestly, I could deal with this one time painful maintance task but spliting of devices is horrible. The UI’s explination doesn’t even make sense;
“Linked devices
These devices share hardware with this device and are managed by other integrations.”
Those aren’t linked devices it’s all the same device. I mean at least make the description correct.
Regardless, grouping info related to a physical devices was great, all info in one spot. I can’t fathom how spreading it around is better.
If the goal was to eleviate some confusion I feel almost any other option would have to have been better.
This is the first update in years that I think has had a major negative impact. Which is equal parts praise as it is disapointing.
I can except change and have liked 90% of the changes over the years, but this one I hope gets reverted.
Warning people via the forum is not the same as raising a deprecation warning in Home Assistant itself. I’ve never seen any of these ‘warnings’, so for me this was a true major, unannounced, breaking change for my set up.
Home Assistant had actually gotten better at warning before updates with breaking changes in the past years, and now my trust/comfort of updating has been hurt.
To me the real gripe is not so much that the behavior changed which required changes. It is that for other breaking changes over the past year(s), we get six month notice and repair notifications. Now, I was confronted with core automations broken without warning, and I had to read the release notes to figure out what was going on. On top of that, it is not even listed as a breaking change in the release notes!
Whether I agree with the arch decision is not relevant, and whether my repairs were many/few is also not really relevant. Really just about the fact that there was no announcement at all.
I also had 20+ automation fail because of this, mostly devices which were joined Unifi + Tasmota or Unifi + ESPHome, where it was not able to automatically resolve the new device for the action/trigger/condition.
Indeed it is a general warning about not ever using device ids, unrelated to this particular breaking change. See: Why and how to avoid device_ids in automations and scripts
There are a lot of benefits to not using device ids and one of them just happens to be that the breaking change introduced in this release would not have affected you.
Was spook creating your repairs or was it the repair for template helpers?
And yet now it’s exactly those users who are feeling the brunt of the pain caused by these changes. and they are less likely to have the tools/knowledge to deal with them.
I guess all the old school users weren’t being unreasonable luddites when we complained about the UI-centric “make it easy™” push.
I got the lowdown on what people are seeing with devices
There is 1 core repair and 1 spook repair:
This template entity repair will ask the user to choose a device. In 2026.8.0 it did not indicate which integration provided the device. In 2026.8.1, there will be an icon to let the user know which device to choose. So the repair is a workflow where you do not need to leave the repair window itself.
The repair from spook is currently not correct. The developer of spook has been on vacation/holiday and completely missed this release. As a result an incorrect repair is presented to users. This repair will claim your device was deleted. This is not true, it can be ignored. When the developer of spook returns from vacation/holiday, this will get fixed.
If you have an automation or script that uses devices, they will continue to work. When you visit the automation, it may prompt you to choose a device for for any device triggers, conditions, or actions. Users will be presented with a list of devices. Again, if you are on 2026.8.0 there won’t be an integration icon next to the device. Upgrade to 2026.8.1+ and you will have an icon.
Currently, if you used a legacy event trigger targeting the device_id inside event data, this will likely need to be fixed. e.g.
triggers:
- trigger: event
event_type: some_event_type
event_data:
device_id: 8937498274a3245234a
A repair is coming for this in a future minor release this month.
If anyone has screenshots of the repairs in question, that would be great so I can attach them to this post.
Quite Naive to think that a small group of Dev’s and UIX People(research or not) can please or even imagine how a New User base(of + 100000) think and like and want, Just look at all new ! Integrations & Cards which pops up, made by New Users, who as most People learn relative fast and want their own style.
The pre-populated forced Dashboards is another fu Idea ( We Think si & so …Now ! , so therefor we Incorporate it in Core, instead of making Optional Integrations )
The entity rename function doesn’t work flawlessly for me.
So I have for now stopped tidying my entities, hoping 2026.8.2 will bring improvements.
Am I the really only one experiencing these anomalies?
Some integrations override the default entity_id themselves, even though for most of them it is not recommended to do so.
For example your custom integration Electrolux Status happens to be one of them.
You will have to ask them to stop, if you want your entities to use your configured entity_id generation pattern.