Changes from HA 2026.8.0+ ("Linked devices" etc) #804
agittins
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
HA 2026.8.0 introduces new policies on how "devices" are represented in the backend. In some cases you might experience some breakage or unexpected behaviour as a result.
Separate device pages for each integration
In earlier versions, if more than one integration (eg Shelly, NMap, Bermuda) provided sensors or other entities for the same physical device, the HA UI would group these together on the one "Device page", and provide a list of which integrations were providing the entities, like this example where Bermuda and BTHome are each showing data for the same device:
The new device implementation in 2026.8.0 splits these into new, separated devices. The device pages are now separate per-integration, so that a BTHome/Bermuda device will look like this on the BTHome device page:
And the link to the Bermuda page will be similarly restricted to the entities from Bermuda, with a link back to the BTHome page.
Separate Areas and name for each device-integration combination
This change also means the names and areas of these newly-separated devices will initially be copied from the original device, but from then on must be manually managed by the user. ie if you want to rename a device or change it's area setting, you will need to manually do so for each integration's version of that device.
Firmware fields doomed to go stale
If one of the integrations provided firmware details, these details will be copied to each new device, but only the one belonging to the integration that provides it will get updates to that property - all the others will remain at the original value after updates etc. This will need to be cleaned up by Bermuda in a future release.
Automations that target by device and Helper Entities (templates, batteryNotes etc)
I think all cases of this will raise a "Repair" item during the initial migration that 2026.8.0 does, which will present you with a simple dialog to choose which device to target. This appears to work well, so might be a bit tedious if you have many affected items but seems otherwise fairly low-impact.
Unknown unknowns
If you have some "odd" setups, like having scanner devices also added as selected devices in Bermuda you might experience unexpected things, but I haven't seen any in my testing yet. Please let me know!
Future cleanup
A future release of Bermuda will do some post-migration cleanup on the split/duplicated devices, to remove extraneous "firmware" properties etc. I'm not sure if the overall change in 2026.8 might cause some user blowback, so I'm not wanting to rush into this in case the way core handles it changes in the next few releases.
Once the dust (if any) settles, I'll look further into whether to keep separate device entries for Bermuda or if it might be better to shift to a "helper integration" model. I suspect not at this stage (since not all Bermuda devices have existing device entries from other integrations, which sort of rules out the helper model - but it would work for scanners).
All reactions