Both Tapo integrations are Custom
And? They probably use identifiers connections properly.
yes, that is a very nice feature, even do that manually on a large set of individually created entities (if only the device would do that, it would be even simpler, but this is second best):
mqtt:
##########################################################################################
# Mqtt sensor
##########################################################################################
sensor:
- unique_id: watermeter_smart_gateways_mac_address
state_topic: watermeter/smart_gateways/mac_address
name: Watermeter Mac address
entity_category: diagnostic
device: {
"identifiers":[
"watermeter_smart_gateways"
],
"name": "Watermeter",
"model": "Watermeter",
"manufacturer": "SmartGateways",
"configuration_url": "http://192.168.3.226:82/"
}
- unique_id: watermeter_smart_gateways_running_firmware_version
state_topic: watermeter/smart_gateways/running_firmware_version
name: Watermeter firmware version
entity_category: diagnostic
<<: &device
device:
identifiers:
- watermeter_smart_gateways
#etceetc for all other individual entities, just set the *device anchor on them
and have this in the device panel on Watermeter:
1 Like
And now we’re back to Integrations , which was my point, It’s not HA which “causes this”
And it’s a “Tracker”, Not an i.e “foreign” template-sensor, tampering with anything, it just as you mention, it’s probably just a registrar of the MAC , that the only thing which “Combine them” in this case, MQTT might be different, But that’s MQTT
So i still find it difficult how HA should make an universal solution, to add entities from other integrations, To A device, or tamper a Device, an add a “permanent” template-sensor to the registry, of the Device
The integration might, if some find it a useful/safe approach
BTW, Why don’t you all just +1 on The FR , im out, couldn’t care less anyway 
It would be very easy. Without showing you the exact code, it’s a moot point. You’ll just have to trust what I’m saying.
The problem is not technical, it just needs approval.
1 Like
Yes, i know where the device registry lives
A simple button on deviceless entities with “add to device” would get the job done and work on any entity with a unique_id. There would need to be some plumbing to let the system know the entity was created without a device and only allow those entities to “swap devices”.
2 Likes
I did. But I’ve also noticed that:
- People making an FR often forget about it (or they don’t know they can/should) → IMHO it should be automatic.
- Some people don’t vote for other reasons.
- “Nerdy” topics like this one always get little votes count anyway, so I don’t care for the count. Make a FR about possibility to change some freakin colors → lots of views/votes. Make a FR about security strategy → no views/votes. Life
2 Likes
I Could vote for it, but partly i don’t have any use-cases which would help me, and i don’t find OP’s clear enough , but as i said, sure for the i.e templates etc where the Device_ID is present, ( Or better any of the devices entities is present) it would be an easy welcoming task, to add it under i.e Automation.
Templates/Helpers ( In The Device Page )
It give people a better overview of where and which parts a Device is present, beside automation/script/scenes
Add Group etc as well ( Thou i guess they then have to go for name, or some entity_id ) and i also got a feeling that OP in some scenarios actually wanted to “bind” an entity/function/value to another/specific “Entity” in The Device, not the Device it self, which is another “Story”
I do have Devices with no entities thou, so this i doubt is even possible to add some functional entity to. Likevice as one can’t add a “new/nonexistent” feature to a Device, But one can change/tamper with another entity ( Which is not the Device it self )
So basically is still just a Template-sensor/Helper addressing an entity, not the Device
Correction: identifiers does not link multiple integrations to a device, connections does.
Not sure how i should interpret this , considered the “exchange” of Opinions above, where DvdNwk an in particular You were trying to prove me wrong.
You can still vote for it, as you find it easy to accomplice, and also though it would be helpful for your self ( No, i don’t yet have MQTT, so i don’t know what people doing there, nor how they interpret this ) (Maybe im just “confused” about the use of the words “extend/combine” , as this to me still will be a fictive Device, similar to an automation where i use a motion-sensor(x) to turn on another switch(y) , Or state of a temperature/door sensor , to raise the thermostat-sensor upper level
I was clarifying that identifiers is not what links multiple integrations to a single device, connections is. I mixed up the device attribute. All my comments stand as-is. I wasn’t trying to prove you wrong, I was describing how the system works. If you think what I’m saying is wrong, then yes, I guess I proved you wrong.
Ok, thou i still don’t know/understand what you mean by “connections” ( could be as simple as just a “connection” ) But yes a “device_attribute” is not to be compared as a “connection”
I really think you should spend time learning about core.device_registry or MQTT discovery before trying to reply to my responses. What you’re saying just doesn’t make sense.
Eventually i believe i will have to learn about MQTT, however im not there yet, and this Topic aint about MQTT. And as i haven’t read much about MQTT, i also don’t know what people mean, or put in their words, nor how they interpret the functions of i.e a MQTT feature
Right, this topic ain’t about MQTT, it’s about devices. Which are controlled by the device registry. MQTT is the only integration that allows a user to create a device. So you as a user can create entities and attach them to devices. I.e. Extending devices or creating custom devices, as mentioned before:
1 Like
There was movement on this in 2024.7. Shout out to @dougiteixeira, who added the ability to add template entities created through the UI to existing devices. Here’s hoping this gets extended to other helpers going forward.
1 Like
There has been no movement to add what was requested in this feature request, personally I find it difficult for the HA core team to implement this in the short term.
UI configuration for more types of template helpers is being done, even though with fewer features than YAML, this would already address many use cases. In a second moment we can try to “equalize” the YAML and UI resources, but doing so and maintaining the organization of the config flow is an obstacle.
1 Like
Sorry, didn’t mean to imply this FR was being addressed, more that the change you provided in the latest release moves HA in that general direction. I do not expect my FR to stop the train 
.
1 Like