Improve HA device registry and support multiple devices in one config

[iMicknl]

Describe the problem you have/What new integration you would like

I recently got started with ESPHome and I like it very much! Most of my cases for ESPHome are in situations where I try to build a 'digital twin' for multiple physical devices. Think of a physical standing desk or Xiaomi MiFlora devices.

However, currently when you configure this, it will add all entities to a single espressif device in Home Assistant. It would be great if you could use the ESPHome YAML to create devices and decide which sensors are linked to which devices.

Use cases:

• ESP32 with Xaomi MiFlora devices
• ESP32 with multiple Switchbot Curtains
• ESP32 with multiple Oral B toothbrushes (or even a combination of the ones above)

Eventually, this would allow us to show the model, manufacturer and firmware of the device we mimic, instead of our ESPHome device. I was looking to port https://github.com/devWaves/SwitchBot-MQTT-BLE-ESP32, however the features regarding device registry and information are not possible (yet) with ESPHome. And for bluetooth devices, you could perhaps even add the mac address to the connection info.

Screenshots Current situation

Proposed situation:

(and with multiple devices, there would be multiple entries)

Please describe your use case for this integration and alternatives you've tried:

Prefixing all entities with the digital twin device name, however this will be messy at some point and doesn't show up nice in the Home Assistant device registry.

Additional context

This would mainly be a cosmetic change, so I can understand that this is not something which has any priority over the other issues. However, perhaps there is someone that would like to tackle this, or work with me to see how we can add this. (unfortunately my C++ is really limited, however I can do Python :-)).

Example YAML

# If not added to a device, it will be added to the main device
sensor:
  - platform: wifi_signal
    name: "WiFi Signal"
    update_interval: 60s

# If added to a device, it will create a new device in the Device Registry
device:
  desk:
    name: Desk Mick
    model: EK5
    manufacturer: Flexispot

  - platform: uart
    name: "Preset 1"
    id: switch_preset1
    icon: mdi:numeric-1-box
    data: [0x9b, 0x06, 0x02, 0x04, 0x00, 0xac, 0xa3, 0x9d]
    uart_id: desk_uart

[cliffordwhansen]

I would also like to see this, I have an ESP32 reading Xiaomi ble temp sensors, and it would be nice if they were different devices.

Might be possible to get the platform to register as sub device of the integration? The Plex, SynologyDSM, and Unifi integrations do something like that.

or something like this in yaml eg.

esp32_ble_tracker:

device:
  bedroom:
    name: Bedroom
    model: lywsdcgq
    manufacturer: Xiaomi
    sensor:
      - platform: xiaomi_lywsdcgq
        mac_address: xx:xx:xx:xx:xx:xx
        temperature:
          name: ${name} Temperature
          state_class: measurement
        humidity:
          name: ${name} Humidity
          state_class: measurement
        battery_level:
          name: ${name} Battery Level
          state_class: measurement

I also think this will require work on the HomeAssistant integration as well to add device support.

[jesserockz]

This is certainly possible from the HA side, and is also on our list TODO at some point. But will probably require quite a bit of work.

[iMicknl]

This is certainly possible from the HA side, and is also on our list TODO at some point. But will probably require quite a bit of work.

I am not super familiar with ESPHome development, however I am able and willing to help with the implementation in Home Assistant, where needed. And indeed, I can imagine that this requires a lot of work and planning.

[paulmonigatti]

I also think this will be an excellent feature, and have started some of the groundwork in esphome/esphome#2560. At the moment, this will only make the device registry more configurable for a single entry, but I'd be happy to participate in a follow-up PR to expand that to multiple devices.

[nagyrobi]

May be related to https://github.com/esphome/feature-requests/issues/1714

[kpfleming]

I've also been wanting to do this, and I've got the time to work on the implementation as well (it will definitely be a significant amount of work). This is the same request as in #1714 (which was closed) and in #2275.

As a first step, I've written a proposal document describing why this would be useful, and how I'd go about implementing it. The doc is here and comments are most welcome. For those who don't want to use Google Docs, I've attached V1 of the proposal doc to this comment, and I'll attach future versions as well as we make progress towards a decision.

V1 - Proposal Connected Devices in ESPHome.pdf

@nagyrobi If you want to close #2275 in favor of this one, so the discussion can live in one issue, that might be good.

[dougiteixeira]

I leave here the suggestion I made in #2275 to contribute to the discussion:

We often use the same ESP device to connect sensors that are not always related but are physically close, taking better advantage of the ESP's GPIO.

In these cases, things can get pretty confusing on the Home Assistant, as the device will have a lot of unrelated entities.

With that in mind, I would like to suggest a resource so that it is possible to configure in ESPHome which device each entity will be linked to when exposed by the API or MQTT.

It would look something like the code below (omitting device_id in the component would keep the current behavior).

esphome:
  friendly_name: Device Default
[…]

devices:
  - id: device_1
    friendly_name: Device 1
  - id: device_2
    friendly_name: Device 2

[…]

sensor: 
  - platform: xxxxx
    device_id: device_1
    name: Sensor device 1

  - platform: xxxxx
    name: Sensor device default

switch:
  - platform: xxxxx
    device_id: device_2
    name: Switch device 2

These secondary devices would be linked to the main (default) device by Home Assistant's via_device property, making it easier to navigate between them in Home Assistant.

I don't have the knowledge to implement such features, so if anyone is willing to evaluate this possibility I would be very grateful!

This configuration would only have an effect on exposing the entities to the Home Assistant API or via MQTT (maybe including the webserver's dashbord?).

[kpfleming]

If you take a look at the last example in the proposal document, it provides the functionality you are looking for (combining unrelated switch and cover devices into single "device" on the HA side).

[dougiteixeira]

I read the proposal and I also think it is good.

Greatly improves the user experience when the ESP board has multiple unrelated components.

Thank you @kpfleming for your willingness to make this a reality.

[zhaqianyuan]

this is which I need

[dougiteixeira]

I've also been wanting to do this, and I've got the time to work on the implementation as well (it will definitely be a significant amount of work). This is the same request as in #1714 (which was closed) and in #2275.

As a first step, I've written a proposal document describing why this would be useful, and how I'd go about implementing it. The doc is here and comments are most welcome. For those who don't want to use Google Docs, I've attached V1 of the proposal doc to this comment, and I'll attach future versions as well as we make progress towards a decision.

V1 - Proposal Connected Devices in ESPHome.pdf

@nagyrobi If you want to close #2275 in favor of this one, so the discussion can live in one issue, that might be good.

Hi @kpfleming, please let us know if you proceeded with the implementation based on your proposal. This feature would be really nice! Thanks.

[kpfleming]

I've got some non-work time coming up over the next two weeks so I plan to start working on this soon. Hopefully @jesserockz will get a few moments to give this idea a sanity check before I get too far into it!

[jesserockz]

I have nothing against the idea, as long as it doesnt complicate the codebase too much.

I would think something like this in config:

esphome:
  ...

sub_devices:
  - id: that_ble_thermometer
    name: ...
    manufacturer: ...
    mac: ...

sensor:
  - platform: some_ble_sensor_platform
    name: Temperature
    device_id: that_ble_thermometer
    ...

In terms of c++, maybe EntityBase just needs an optional pointer to a SubDevice and then the api and mqtt code can send an id of that alonf with the EntityInfo message, and also send the sub_devices by themselves before the entities so Ha can link them up

[dougiteixeira]

As a first step, I've written a proposal document describing why this would be useful, and how I'd go about implementing it. The doc is here and comments are most welcome.

@kpfleming reading your proposal I don't think that the components already defining their own device ID brings benefits... because in practice I can have things from different components on the same functional device in Home Assistant.

I would limit the device id to be a user option to be defined in the ESP board code, in line with this suggestion from @jesserockz above.

[jesserockz]

I totally didnt see your message above with examples @dougiteixeira. Thats exactly how I envision it being =)

[kpfleming]

@kpfleming reading your proposal I don't think that the components already defining their own device ID brings benefits... because in practice I can have things from different components on the same functional device in Home Assistant.

I think that's a misunderstanding; in the examples in the doc the 'device_id' attributes are references to device objects defined in the device block. They are not device definitions, and their purpose is exactly what your proposed, to allow any components (from any platform) to be combined into a single device.

[dougiteixeira]

I think that's a misunderstanding; in the examples in the doc the 'device_id' attributes are references to device objects defined in the device block. They are not device definitions, and their purpose is exactly what your proposed, to allow any components (from any platform) to be combined into a single device.

You're right, I think I confused options 1 and 3 thinking that the proposal was both. sorry...

[foxthefox]

I would also love to see this feature implemented, my use case are 2 identical BLE devices with a lot of sensors and controls.

[bzumik1]

I would really love to see this. There is integration of SAMSUNG ACs which would really benefit from this. SAMSUNG AC unit controller.

[dala318]

Started looking into the codebase to implement this but realized it can be done in many ways. All from very complex and integrated ways to very simplistic but maybe also a bit "hacky". Are there any others out there with ideas how this should be realized?

So a simple way to do this that I was thinking of was to do the config-changes as proposed above with a devices: section but only have it create an extra string attribute per entity (similar as Change #2113 ) that is then used in Home Assistant integration to modify the device_info.name which in theory should render a unique device.

The more complex (and more correct) way would be to dig in to the ESPHome device registration architecture and actually create virtual devices to which entities are associated. This would then also allow for the extra requests to assign different native areas etc. to each device. But for this option someone more familiar with the ESPHome architecture will have to do the change.

The DeviceRegistry part of Home Assistant is still a bit hazy to me and cant really say I know what the rules are to group entities together to a single device or if it should generate two individual devices. So input is welcomed.

[oliv3r]

I have the same issue, where I have an rf_transmitter node, which transmits codes for multiple devices. One of them, a awning, uses end-stop switches that are hooked up to a different node! So while I can make automatons work of course, having them (virtually) in the same device is only logical. Even if this was the same device, logically, the other remote control codes have nothing to do with the awning/end-stops and thus should be logically not grouped.

[jdgiddings]

I have an ESP32 acting as a DMX controller for 12 DMX lights. Having all 12 light controls in the same device looks odd. Really excited for this feature in the future