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.

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.

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.

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.

May be related to #1714

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.

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?).

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).

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.

this is which I need

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.

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!

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

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.

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

@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.

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...

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

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

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.

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.

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

Another use case:
https://github.com/Fabian-Schmidt/esphome-victron_ble
This is to get sensors and so on from several Victron BLE devices - would really make sense to have them as several devices in Home Assistant as well.

With introduction of esphome/esphome#8187 this feature could be even more relevant to add.

my EPS32-S3 reads out multiple devices in my Camping-Van and publish the state to mqtt with HA-Discovery.

1x victron ble
3x atc_mithermometer
1x jbd_bms_ble
1x gps module

i really like to split them in multiple devices

Got curious if I after some more experiences with ESPHome could solve this in another attempt. My local compare PR dala318/esphome#8 is in many parts the same as previous but actually implements a SubDevice section in the device registry which entities can reference by its id.
For this to take any effect there is also need for a matching implementation in ESPHome HomeAssistant component more specifically ESPHomeManager and also underlying aioesphomeapi library

But since it's necessary to fiddle around with a lot of Core components it should be at least partially approved by the maintainers of project before any more work is put in to it.

For this to take any effect there is also need for a matching implementation in ESPHome HomeAssistant component more specifically ESPHomeManager and also underlying aioesphomeapi library

This would exclude any/all using MQTT, no?

I have not looked in to MQTT at all in this implementation, feel free to investigate where that would make sense to add if possible.

Official PRs are now submitted for Core maintainers of ESPHome to have a look at it and give feedback on the approach.
I hope the fact that they are in draft will not prevent them from looking at it, if it does, do anyone has any idea how to bring this to their attention? (Have not added for all entity-types since it's such tedious job, in wait for concept approval)