Home Assistant discovers and reconciles device changes by mapping new observations to stable integration identifiers, then updating device, entity, and state registries.
Discovery can arrive through multicast, Bluetooth, USB, MQTT, a cloud API, or an integration scan. The observed name or address may change, so Home Assistant relies on identifiers supplied by the integration to decide whether it is seeing an existing device, a new one, or a conflict. Reconciliation updates metadata and availability while trying to preserve entity references used by dashboards and automations.
Discovery Produces Candidates, Not Final Identity
A discovery packet or scan can reveal an address, model, advertised service, serial number, or topic. Those observations are candidates because names and IP addresses can change and duplicate advertisements can exist. The integration interprets the protocol and proposes a configuration entry or update instead of treating every packet as a new household device.
Network boundaries shape which discovery traffic reaches Home Assistant. This discussion of container discovery networking demonstrates why a container can have ordinary IP connectivity yet miss multicast discovery that depends on network mode and subnet behavior.
Manual addition may still succeed when passive discovery cannot cross the boundary, but that does not repair discovery itself. Separate name resolution, routed unicast, multicast forwarding, and protocol-specific gateways. A device appearing only after a network change identifies a reachability relation, not necessarily an integration defect.
Stable Identifiers Preserve Registry Continuity
Integrations assign unique identifiers that connect a physical or logical device to configuration, device, and entity registry records. Friendly names and entity IDs are user-facing references and may be renamed; they are weaker identity evidence than a protocol serial, MAC-derived identifier, or integration-specific account key.
Replacing hardware while preserving history reveals the distinction between identity and display naming. This entity replacement workflow shows how registry and entity-ID choices affect continuity of automations and long-term statistics.
Continuity fails when firmware changes an identifier, two devices claim the same identifier, or an integration changes its mapping rule. Do not repeatedly delete and rediscover before recording old and new registry values. That evidence determines whether the safe response is a rename, migration, integration fix, or genuinely new device.
Reconciliation Merges Events With Existing State
After setup, an integration polls, subscribes, or listens for pushed events and translates protocol data into entity states and attributes. Reconciliation compares current observations with registry definitions, marks unavailable entities, adds newly supported capabilities, and may retire obsolete metadata. It is a continuous lifecycle rather than a one-time discovery screen.
MQTT discovery makes identifier and name changes especially visible because devices publish configuration payloads that Home Assistant consumes repeatedly. The MQTT name-change discussion illustrates why renaming policy must preserve a stable identity while allowing display metadata to evolve.
A delayed device may be temporarily unavailable without being deleted, while a payload with a new unique identifier can create a duplicate. The failure boundary is identity churn that breaks automations or splits history. Preserve messages and registry records before attempting cleanup.
Verify Reconciliation With a Change Matrix
Choose one test device and record its integration, unique identifiers, device record, entity IDs, friendly names, area, automations, and recent history. Then test four controlled changes separately: IP address, friendly name, temporary offline period, and supported capability update. Revert each change before the next.
Use the ZimaSpace model of discovery and routing to interpret whether a missed change belongs to transport or registry reconciliation.
Pass when the same device record persists, expected metadata changes, entities recover after offline time, automations keep their references, and history remains coherent. Stop if a duplicate device appears or an entity ID changes unexpectedly. Export diagnostics and compare identifiers before deleting either record.
Tech & AI HUB
More to Read

Open Models Are Catching Frontier AIโIs 2026 the Year Local AI Becomes Good Enough?
Open models are getting good enough for more local AI workloads, while frontier cloud models remain useful for the hardest reasoning and agent tasks.

NVIDIA PAIR Turns Your Home Network Into a Local AI ClusterโDo You Still Need One Big GPU Server?
NVIDIA PAIR spreads local AI requests across multiple PCs, making compute more elastic while one home server can keep data and state persistent.

Why Does Immich Feel Faster on LAN Than on Remote Connections?
LAN requests usually take a shorter, lower-latency path. Remote access adds WAN capacity limits and may add DNS, TLS, proxy, VPN, or relay hops.

