Home Assistant 2026.8 changed how devices that connect through more than one integration are tracked, and it has broken automations for some users. Previously, if a physical device was exposed through two integrations at once, Home Assistant merged them into a single device entry. In 2026.8 that merge was removed: each integration now gets its own separate device entry for the same physical hardware. The official reasoning is sound — a merged device could only hold one value for fields like model or serial number, which caused conflicts. But the migration doesn't always leave a clean trail. Automations that reference a device by its internal ID, rather than by entity, can keep pointing at an ID that no longer exists, and Home Assistant's Repairs page doesn't reliably flag every broken reference. If an automation has simply stopped firing since you updated, this is worth checking before you assume it's something else.
What actually changed in Home Assistant 2026.8?
Home Assistant no longer merges devices that are exposed by more than one integration into a single device entry. The 2026.8 release notes describe this as a deliberate cleanup: when two integrations reported the same physical device, Home Assistant combined them so you'd see one device in the UI instead of two. The problem was that fields like model number or serial number can only hold a single value per device, so a merged device could show incorrect or conflicting details depending on which integration's data won. From 2026.8, each integration gets its own device entry for that hardware, and entities are moved across automatically during the update.
This affects any setup where the same physical device is reachable through two integrations at once. The pattern that's caused the most reports so far involves network-attached devices, such as ESPHome nodes or Shelly relays, being surfaced both through their own integration and through a network/router integration like TP-Link Omada. Multi-integration setups involving Sonos, UniFi, FRITZ!Smart Home, HueSync and FullyKiosk have also been reported as affected in the same way.
Why didn't Home Assistant warn me before my automations broke?
It does warn you in some cases, but not all of them. Home Assistant's Repairs system is built to catch entities and devices that go missing and prompt you to reassign them. In a GitHub issue opened on 6 August 2026, one user described needing to repair around 20 automation templates that referenced ESPHome devices previously merged with a TP-Link Omada network device — and Home Assistant did flag those. But a separate automation trigger, referencing the same outdated device ID, was never flagged in the general Repairs overview. It only became visible when the automation was opened in the visual editor, and the automation itself had simply stopped firing with no notification at all.
Comments on the same issue describe the same gap affecting other integrations. One user with roughly 30 Shelly devices found that multi-switch Shelly hardware received new, separate device IDs for each sub-device, breaking `turn_on` actions across their automations; given the scale of manual repair involved, they restored a backup taken on Home Assistant 2026.7.4 rather than fix each automation individually. Others reported the same pattern with Sonos, FRITZ!Smart Home-integrated devices, HueSync and FullyKiosk. One user tried disabling the affected integration before updating as a precaution, then re-enabling it afterwards — the broken references reappeared regardless.
How do you check if your automations are affected?
Start with Settings > Automations & Scenes, and check for any repair notification banner — Home Assistant does catch a meaningful share of broken references this way, so clear those first. Then, because the Repairs page doesn't catch every case, manually open any automation that uses a device trigger or device action (rather than an entity trigger/action) and look for a warning inside the visual editor itself, even on triggers that are currently disabled. The safest way to confirm an automation is genuinely still working is to trigger it manually via Developer Tools and watch whether the expected action fires, particularly for anything tied to ESPHome, Shelly, Sonos, UniFi, TP-Link Omada or FRITZ!Smart Home devices, since those are the integrations with the most reports so far.
How do you fix a broken automation after the device split?
Open the affected automation in the visual editor, find the trigger or action showing a device that needs reassigning, and re-point it at the correct new device entry for that integration — the entities themselves have already moved across, so the underlying functionality is intact once the reference is corrected. Where practical, switch device-based triggers and actions to entity-based ones instead; entity IDs are generally more stable across this kind of restructuring than device IDs, so rewriting the automation around entity references rather than device references reduces the chance of the same problem recurring on a future update. If you manage a large number of affected devices, such as a Shelly-heavy installation with dozens of automations, restoring your pre-update backup and waiting for a patch release with better migration handling may be the more practical option, as one user in the GitHub thread chose to do, rather than repairing each automation by hand.
For the rest of what changed in this release, including the new default port and interface changes, see our Home Assistant 2026.8 release notes. The device-splitting issue was still open and unresolved on GitHub as of publication, so check the issue thread for updates before assuming a fix has shipped. The same release also drops Companion app support for iOS 15, watchOS 8 and macOS 11, so it is worth checking your phone or Apple Watch is on a compatible OS version while you are fixing automations.
