1 device
It’s Just Grouping entities in, Right, in A Device 
(Fictive such) Or “something” conveniently called/Defined with a Device_ID(Maybe) , By The Integration,
Or does this “New Device” still entirely exist in the Orig Integration only ? ( With some Pointers to the DeviceTools Integration ?
hmmm, sorry i don’t quite get the Logic, in fact im very confused
Im Glad Labels “talks” to my Logic, those helped me dumping some old-style-groups and some Templates-Changes to simpler versions, without making changes to any Integrations
lol, thats was a “lame” answer, sorry for my wording
1 device ? what? … I assume Exposed from MQTT, and this Not because HA made the Change in the MQTT-Integration, nor on the Device
Right, And how are those “linked”
I have that as well
In Fact both my Tapo-Integrations And Asus-Router “act” this way , and is only doo to a Device-Tracker
However Local_Tuya Don’t
PS: Do you find this Device_tracker in your Shelly Integration ?, or Do you only find it in You UniFi ? ( Where it belongs )
They are linked through identifiers connections. In the case above, most likely the ip ot MAC address.
Local tuya is custom and probably doesn’t use connections
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”