Duplicate Devices After Home Assistant 2026.8: Fix

Direct answer: If devices appear duplicated after upgrading to Home Assistant 2026.8, do not immediately delete one, merge registries manually, or re-pair the hardware. The release changed how Home Assistant represents some physical products that are supplied by more than one integration. Review Settings, System, Repairs, follow the official repair when one is offered, and then check automations or scripts that target a device ID directly. Entity-based actions usually continue to address the same entities, but unusual configurations need verification.

What changed in Home Assistant 2026.8

Home Assistant’s August 2026 release introduced groundwork for more flexible device handling. The official release notes explain that a product previously represented as one device can be split when different integrations provide different parts of it. In rarer cases where the same device was configured through more than one integration, Home Assistant may raise a repair.

The release notes state that automations and scripts generally keep working because actions are still sent to the appropriate devices. They specifically identify device-ID-based automations and unusual setups as areas that may deserve review. This is not the same as a random duplicate created by pairing a radio device twice, restoring an old registry, or adding both a local and cloud integration.

Symptoms covered by this guide

One physical product appears as two device cards after the 2026.8 upgrade.
Entities that were grouped together now appear under separate devices.
A new repair mentions a device represented by multiple integrations.
An automation using a device trigger or device action behaves differently.
A dashboard still works but the device page looks reorganized.
You cannot tell whether the second device is intentional or stale.

Before making changes

Create and download a current Home Assistant backup.
Record the Core version and installation type.
Capture the repair text and both device pages.
List the integrations shown on each device page.
Record entity IDs, device IDs where visible, area assignments, and disabled entities.
Export or copy important automations and scripts that reference the device.

Do not edit the device registry or entity registry files manually on a running system. Do not delete database rows. Registry corruption can affect more than the visible duplicate and may leave automations pointing to identifiers that no longer exist.

Step 1: Determine whether the split is expected

Open each device card under Settings, Devices & services, Devices. Compare manufacturer, model, serial or hardware identifiers, entities, and the integrations listed. An expected split may place different functional groups under separate representations because distinct integrations provide them.

For example, one integration may provide local device controls while another provides a service-level function. The visible names may be similar even though the representations have different ownership. Do not rename them solely to make the distinction disappear; first understand which integration supplies each entity.

Step 2: Read the Repairs entry completely

The Repairs integration is enabled by default and lists issues under Settings, System, Repairs. Each repair either offers a guided fix or provides information about the required action. Open the item and read every step before confirming it.

If the repair is related to the 2026.8 device-handling change, follow the official flow. Avoid using a generic “ignore” choice until you know what remains unresolved. Take screenshots or notes so you can compare device and entity mappings after completion.

Step 3: Identify other causes of apparent duplicates

Not every duplicate after an upgrade is caused by the new device model. Check whether the same product was added through multiple paths:

A manufacturer cloud integration and a local protocol integration.
HomeKit Device and Matter for the same accessory.
ZHA and Zigbee2MQTT records from a migration.
Two configuration entries for the same network service.
A restored backup plus newly discovered hardware.
An old unavailable device with no entities and a new active device.

Multiple integrations can be intentional. A cloud entry may expose functions that the local path does not, while the local path offers better responsiveness. Decide based on ownership, reliability, privacy, and entity requirements rather than the number of cards alone.

Step 4: Compare entity registries before deleting anything

Open each entity and record its entity ID, integration, device association, state, and where it is used. Home Assistant’s interface can show related automations, scripts, scenes, and dashboards. An unavailable entity can still be referenced by an automation, so absence of a current state does not prove it is safe to delete.

Look for equivalent entities with different IDs, such as a cloud switch and local switch controlling the same relay. Test only a non-critical control and confirm which physical function changes. Do not experiment with locks, garage doors, alarms, mains-powered heating, irrigation, or other safety-sensitive systems without appropriate safeguards.

Step 5: Audit device-based automations

Automations can target entities or devices. Entity actions reference an entity ID, while device triggers, conditions, and actions can store a device identifier and integration-specific details. The 2026.8 release notes call out device-ID-based automations for review after a split.

Open each related automation in the visual editor and inspect triggers, conditions, and actions. If YAML mode is used, save a copy before editing. Confirm which new device contains the required trigger or action. Do not replace every reference mechanically; the correct representation can differ by function.

After a repair, trigger each non-critical automation under controlled conditions. Check traces to verify that the expected trigger fired, conditions evaluated correctly, and the intended entity received the action.

Step 6: Check scripts, scenes, dashboards, and areas

Scripts and scenes usually reference entities, but device actions are also possible. Dashboards can contain entity cards, device pages, conditional cards, and area-based views. Search for unavailable or renamed entities and update only confirmed stale references.

Check area assignments on both device representations. A split can leave functions in different areas, which affects area-based voice commands, dashboards, and automations. Assign each representation according to the physical location and how Home Assistant uses the area.

Step 7: Decide whether one integration should be removed

Remove a configuration entry only after proving it is redundant and documenting what it owns. Use the integration’s official removal flow. Some integrations remove devices and entities immediately; others leave registry entries until cleanup conditions are met.

Before removal, list unique capabilities, authentication requirements, cloud dependencies, update frequency, and automations using its entities. Prefer the path that meets your reliability and privacy needs, but do not assume “local” and “cloud” are interchangeable. The local path may not expose every function.

Step 8: Handle a stale unavailable device

If one device has no active entities and belongs to a removed configuration entry, Home Assistant may allow it to be deleted. Confirm that it is not a bridge, service device, or parent of hidden entities. Check disabled entities as well as visible ones.

Delete through the user interface only when Home Assistant offers the action and all references have been reviewed. If deletion is unavailable, investigate the owning integration instead of manipulating registry storage manually.

Step 9: Review custom integrations

The 2026.8 release notes say most custom integrations require no immediate changes, but developers working directly with device information should review the developer guidance. If the duplicate involves a custom integration, check its repository for a release compatible with your exact Core version.

Do not copy unreviewed patches into production. Custom integrations are outside the official project’s normal support boundary and can affect registry behavior. Back up, read release notes, and test updates one at a time.

How to verify the repair

Clear or complete the relevant Repairs item.
Restart Home Assistant once under controlled conditions.
Confirm the expected device representations return.
Check that all required entities have current states.
Run important non-critical automations and inspect traces.
Verify scripts, scenes, dashboards, area controls, and voice exposure.
Review logs for registry, config-entry, or platform errors.
Wait through at least one normal integration update cycle.

Common mistakes to avoid

Deleting the first device that shows unavailable.
Assuming similar names prove two records are duplicates.
Removing a cloud integration before checking unique entities.
Editing registry JSON files directly.
Re-pairing Zigbee, Z-Wave, Matter, or HomeKit hardware without evidence.
Ignoring device-based automations after the split.
Restoring an old backup without considering later changes.
Renaming entities before recording their original IDs.

Rollback and recovery

If a guided repair or integration removal breaks automations, stop additional changes. Restore saved automation YAML or update references to the verified new device and entities. If many registry relationships are damaged, a full backup restore may be safer than manual reconstruction, but it also reverses changes made after the backup. Review the backup date and preserve the current system before restoring.

When radio devices are involved, avoid factory resets during registry cleanup. Radio pairing state can reside in both the controller and endpoint. A reset can turn a user-interface organization problem into a network re-pairing problem.

When to escalate

Collect the Core version, previous version, installation type, repair text, integration names, device identifiers with sensitive values redacted, entity mappings, relevant logs, and steps that reproduce the problem. State whether the setup uses official or custom integrations and whether the duplicate existed before 2026.8.

Search the Home Assistant Core issue tracker and the relevant integration repository. If filing a new report, focus on one reproducible behavior. Do not upload a complete backup, secrets file, tokens, precise location, or unreviewed diagnostic archive.

Prevention and maintenance

Read release notes before major monthly upgrades.
Keep verified backups and matching recovery material.
Document integrations that represent the same physical product.
Prefer stable entity naming and avoid unnecessary renames.
Review device-based automations after device-registry changes.
Remove obsolete configuration entries through supported interfaces.
Track custom-integration compatibility separately.

Use automation traces to find hidden device references

A device-based automation can look correct in the visual editor while its stored reference still points to the representation that changed. Open the automation’s recent traces and inspect the trigger, conditions, and action path. A trace can show whether the trigger never fired, a condition evaluated against an unavailable entity, or an action targeted a device that no longer offers the expected capability.

When correcting a reference, change only the affected trigger or action and save a copy of the previous YAML. Then reproduce the event safely and compare the new trace. This is more reliable than replacing every similar device name across the system.

How names can make an intentional split look like an error

Home Assistant may derive names from the product, integration, room, and entity descriptions. After a split, two legitimate records can inherit nearly identical names. Give them clear display names only after you identify their roles—for example, distinguishing a local control representation from a cloud service representation. Renaming improves clarity but does not merge ownership or change which integration updates an entity.

Avoid changing entity IDs during the first investigation. Entity-ID changes can ripple through YAML, templates, dashboards, notifications, and external consumers. Stabilize the device relationships first, then make naming changes deliberately with a reference audit.

Check voice assistants and external consumers

Google Home, Alexa, HomeKit bridges, Node-RED, MQTT consumers, and dashboards outside Home Assistant may refer to entity IDs or exposed-device selections. After completing the repair, review exposed entities and look for a duplicate display name in the external platform. Do not delete the external copy until Home Assistant’s source entity is understood.

If an external platform retains a stale device, sync or rediscover through its supported procedure after Home Assistant is stable. Re-linking an entire account can affect rooms, routines, and names, so use the smallest supported refresh first.

Special care for bridges and multi-channel products

A bridge, power strip, multi-relay module, or climate system can legitimately contain many entities and child devices. Two cards do not necessarily represent two copies of the hardware. One may represent the bridge or service while others represent endpoints. Check the “via device” relationship and integration ownership before removing the parent.

For Zigbee, Z-Wave, Matter, and HomeKit, registry cleanup is not the same as radio removal. Exclusion, unpairing, or factory reset changes network credentials and should be reserved for a proven communication or ownership problem. A device-page reorganization after 2026.8 does not by itself justify radio changes.

2026.8 duplicate-device decision table

What you see	Likely meaning	Safest next step
Two device pages, each owned by a different integration	The former cross-integration merged device was split as designed	Keep both until you confirm which entities and automations belong to each integration
A Repairs notification after upgrading	Home Assistant detected a device-registry case that needs guided review	Follow the repair text; do not delete registry records first
Duplicate-looking cards but different entity sets	One physical product is represented by separate integration responsibilities	Rename the device pages for clarity and leave entity ownership intact
An entity is unavailable or orphaned	The issue may be an integration/config-entry failure rather than the 2026.8 split	Check the entity’s integration, config-entry status, and logs before cleanup
An automation reports an unknown device	A device-based trigger or action may reference the pre-split registry entry	Re-select the intended device/entity in a copy of the automation, test it, then replace the original

Verify before deleting or merging anything

Open each device page and record its integration, identifiers, entities, and automation links. The official 2026.8 change assigns a device to one config entry instead of merging information from several integrations. A physical product may therefore appear once for its primary integration and again for a router or tracker integration. That is not automatically corrupt data.

Use a reversible test: rename each device page temporarily with its integration name, run one device-based automation, and operate one entity from each page. If both pages control or report distinct functions, keep them. If a repair explicitly instructs you to choose an entry, follow that guided flow and recheck automations afterward. Do not unpair Zigbee, exclude Z-Wave, reset Matter credentials, or factory-reset HomeKit accessories merely because the registry presentation changed.

Expected result: entities remain attached to the correct integration-owned device, existing entity-based automations continue working, and any affected device-based automation is deliberately remapped. Rollback: restore the original automation from its backup or traceable copy and reverse temporary display-name changes. Registry deletion is not a rollback strategy because it can remove references without fixing the owning integration.

Evidence and testing disclosure: This diagnostic order is based on the Home Assistant 2026.8 release notes and the official developer explanation of single-config-entry device ownership. Community reports are treated only as examples of impact, not proof of a universal defect. Troubliq did not reproduce every integration combination. Last reviewed October 1, 2026.

Sources

Last reviewed: September 8, 2026.

Related Troubliq guides: Use the least-destructive diagnostic method, browse all troubleshooting guides, and read Matter device unavailable troubleshooting when the apparent duplicate involves a Matter accessory.

Decision summary

Follow the official repair when Home Assistant identifies a 2026.8 representation issue. Audit device-based references when functions moved between device records. Keep multiple integrations when each supplies needed capabilities. Remove an entry only after documenting its entities and dependencies. Delete a stale device only through the supported interface after confirming that it owns nothing required. This evidence-first process prevents a cosmetic duplicate from becoming lost automations, missing entities, or an unnecessary radio rebuild.

Find your next troubleshooting path

Use the related guide that matches the next confirmed layer of the failure. Avoid changing unrelated systems at the same time.

Duplicate devices after Home Assistant 2026.8: safe repair