Currently there is no way to get a name of integration for some entity_id (correct me if I am wrong).
We have an “integration_entities” which gives a list of entity_ids for some integration - but I am asking for opposite.
Definitely. I often look at stuff and think “where did that come from?”
A possible workaround could be adding an attribute by “customize” (or explicitly for template sensors) with a name of integration (or a package’s name). But using a dedicated function which may be used in templates is better )).
1 Like
One issue with your request might be the entity could be governed by more than one integration and I don’t know if HA distinguishes between the original creator of the entity and subsequent integrations which may include it (i.e the battery_notes integration comes to mind).
I would say - this is WRONG.
Please post a screenshot proving that this “battery_notes” integration creates entities belonging to several integrations.
Sorry, you are correct…it’s the device which may be governed my more than one integration.
The entities belonging to that device are integration specific.
I see, earlier I myself posted an example when a device created by iPhoneDetect integration was confusingly associated with ASUSWRT integration. The author of iPhoneDetect already fixed the integration - now it’s devices do not have this wrong connection.
IMHO a device should be only associated to ONE integration.
If we observe a different behaviour - I would call it a wrong object model & implementation.
The current way may give us a device associated with 3 integrations:
which seems a bit weird.
IMHO a device may need to be associated with more than one integration and Battery Notes is a perfect (and my only) example. When I look at the device I see the entities that the native integration created as well as the entitites which Battery Notes added to it. Your way would be quite laborious and unintuitive IMO. For other integrations though, this might not be the case. I truly believe the integration needs to have the choice to add entities to another integration’s devices or create it’s own device. The internal code for battery_notes (which I’ve been inside of) would be much more complex if it did not have that choice…
As a device is modelled as a physical object, it is not wrong to have it associated with several integrations. The problem is, the entities attached to the device do not show which integration they come from.
To clearly see which entities belong to a particular integration - a device should be associated with ONE integration. Also, there are should be a possibility to aggregate devices in a some kind of a group - specially for cases like described.