Skip to main content

Device registry

The device registry is a registry where Home Assistant keeps track of devices. A device is represented in Home Assistant via one or more entities. For example, a battery-powered temperature and humidity sensor might expose entities for temperature, humidity and battery level.

Device registry overview

What is a device?

A device in Home Assistant represents either a physical device that has its own control unit, or a service. The control unit itself does not have to be smart, but it should be in control of what happens. For example, an Ecobee thermostat with 4 room sensors equals 5 devices in Home Assistant, one for the thermostat including all sensors inside it, and one for each room sensor. Each device exists in a specific geographical area, and may have more than one input or output within that area.

If you connect a sensor to another device to read some of its data, it should still be represented as two different devices. The reason for this is that the sensor could be moved to read the data of another device.

A device that offers multiple endpoints, where parts of the device sense or output in different areas, should be split into separate devices and refer back to parent device with the via_device attribute. This allows the separate endpoints to be assigned to different areas in the building.


Although not currently available, we could consider offering an option to users to merge devices.

Device properties

area_idThe Area which the device is placed in.
config_entriesConfig entries that are linked to this device.
configuration_urlA URL on which the device or service can be configured, linking to paths inside the Home Assistant UI can be done by using homeassistant://<path>.
connectionsA set of tuples of (connection_type, connection identifier). Connection types are defined in the device registry module. Each item in the set uniquely defines a device entry, meaning another device can't have the same connection.
default_manufacturerThe manufacturer of the device, will be overridden if manufacturer is set. Useful for example for an integration showing all devices on the network.
default_modelThe model of the device, will be overridden if model is set. Useful for example for an integration showing all devices on the network.
default_nameDefault name of this device, will be overridden if name is set. Useful for example for an integration showing all devices on the network.
entry_typeThe type of entry. Possible values are None and DeviceEntryType enum members (only service).
hw_versionThe hardware version of the device.
idUnique ID of device (generated by Home Assistant)
identifiersSet of (DOMAIN, identifier) tuples. Identifiers identify the device in the outside world. An example is a serial number. Each item in the set uniquely defines a device entry, meaning another device can't have the same identifier.
nameName of this device
name_by_userThe user configured name of the device.
manufacturerThe manufacturer of the device.
modelThe model of the device.
serial_numberThe serial number of the device. Unlike a serial number in the identifiers set, this does not need to be unique.
suggested_areaThe suggested name for the area where the device is located.
sw_versionThe firmware version of the device.
via_deviceIdentifier of a device that routes messages between this device and Home Assistant. Examples of such devices are hubs, or parent devices of a sub-device. This is used to show device topology in Home Assistant.

Defining devices

Automatic registration through an entity


Entity device info is only read if the entity is loaded via a config entry and the unique_id property is defined.

Each entity is able to define a device via the device_info property. This property is read when an entity is added to Home Assistant via a config entry. A device will be matched up with an existing device via supplied identifiers or connections, like serial numbers or MAC addresses. If identifiers and connections are provided, the device registry will first try to match by identifiers. Each identifier and each connection is matched individually (e.g. only one connection needs to match to be considered the same device).

# Inside a platform
class HueLight(LightEntity):
def device_info(self) -> DeviceInfo:
"""Return the device info."""
return DeviceInfo(
# Serial numbers are unique identifiers within a specific domain
(hue.DOMAIN, self.unique_id)
via_device=(hue.DOMAIN, self.api.bridgeid),

Besides device properties, device_info can also include default_manufacturer, default_model, default_name. These values will be added to the device registry if no other value is defined just yet. This can be used by integrations that know some information but not very specific. For example, a router that identifies devices based on MAC addresses.

Manual registration

Components are also able to register devices in the case that there are no entities representing them. An example is a hub that communicates with the lights.

# Inside a component
from homeassistant.helpers import device_registry as dr

device_registry = dr.async_get(hass)

connections={(dr.CONNECTION_NETWORK_MAC, config.mac)},
identifiers={(DOMAIN, config.bridgeid)},

Removing devices

Integrations can opt in to allow the user to delete a device from the UI. To do this, integrations should implement the function async_remove_config_entry_device in their module.

async def async_remove_config_entry_device(
hass: HomeAssistant, config_entry: ConfigEntry, device_entry: DeviceEntry
) -> bool:
"""Remove a config entry from a device."""

When the user clicks the delete device button for the device and confirms it, async_remove_config_entry_device will be awaited and if True is returned, the config entry will be removed from the device. If it was the only config entry of the device, the device will be removed from the device registry.

In async_remove_config_entry_device the integration should take the necessary steps to prepare for device removal and return True if successful. The integration may optionally act on EVENT_DEVICE_REGISTRY_UPDATED if that's more convenient than doing the cleanup in async_remove_config_entry_device.

Categorizing to device info

Device info is categorized into Link, Primary and Secondary by finding the first device info type which has all the keys of the device info.

Linkconnections and identifiers
Primaryconfiguration_url, connections, entry_type, hw_version, identifiers, manufacturer, model, name, suggested_area, sw_version, and via_device
Secondaryconnections, default_manufacturer, default_model, default_name, and via_device

This categorization is used in sorting the configuration entries to define the main integration to be used by the frontend.

Mandatorily, the device info must match one of the categories.