Separate integration devices from other integrations in the integrations tab

Feature Requests
1

It’s hard to put in a title but for example, I have some Sonos speakers. I installed the Sonos integration, the Sonos Cloud integration and the Powercalc integration. As expected the speakers get associated with all three integrations.

Now when I go to the Sonos integration page and open a device the device page shows all the entities associated with all three integrations instead of just the entity associated with the Sonos integration:

image
image986×661 37.6 KB

So now I have to try to figure out which entities are provided by which integration.

And if you click on the integration list on the left you would think it would drill down and then only show the entities from that particular integration. But it doesn’t. It takes you right back to the exact same device page as before. Totally unhelpful.

To keep things straight I needed to figure out by trial and error and educated guessing which entities were provided by which integration and then name them all accordingly. And that’s the only reason the entities above are named correctly is because I did it myself. The default names gave no indication which was which.

And you can’t just rename a device associated with each integration differently either. So all the integrations end up having the same device name but different entity names depending on the integration.

If I click on the Sonos Cloud integration I don’t want or need to see all the entities from the Sonos or Powercalc integrations. If I wanted to see those I would have clicked on those integrations instead.

Definitely not very user friendly.

If someone wants to see all integrations that a device is associated with then there is a tab specifically for devices. And that would make sense under that context to show them all there.

But each integration page should only show the entities of the device that are associated to that integration.

IOW, there should be two device pages and they should each be context sensitive from where you navigated to them from. One would only show the device entities only associated with the specific integration and the other would show all the device entities associated with all integrations.

This was further discussed here

2

I would call this “a not good object model”.
A link between “integration”, “device” & “entity” should be revised.

1 Like
3

For what it’s worth, I voted for this, but I don’t think two device pages (one filtered by integration and another one unfiltered) make much sense, at least in my mind.
I’d rather have a single device page with the option to filter/filter out integrations.

This could be applied both on the device page itself, as well as a multi-filter in the Devices tab, where you could filter by device AND integration. Clicking on that device while the filters are applied would then take you to the (single) device page where the same filters are also applied.

1 Like
4

TBH, I it doesn’t really matter what the mechanism is as long it gets to the gist of the FR.

I’d be fine with a way to filter on the integration specific device entities.

But either way the end result presented to the user will be the same - one filtered device page showing only the device entities associated with a specific integration and a second device page showing all device entities from all integrations. In the end I think it’s a distinction without a difference.

1 Like
5

Yeah, that’s my point. You don’t really need a second device page. All you really need is a filter option on the (single) device page itself (and hopefully even in the devices tab in Settings) where it would show/hide selected integrations making use of the device.

6

Imho 1 device should be linked to 1 integration.
And probably one more object should be added - “composited device”.

7

I’m pretty sure I agreed with you.

:man_shrugging:

8

The duplicate Sonos entities were a stopgap solution as you’re using a custom component. I’d recommend trying to use just the built-in Sonos integration as the sound overlay feature has been added to it.

9

OTOH does it really matter which integration the entity came from? It’s just info about that device. If some of that info is provided by a different integration, who cares? (I may be missing something of course)

10

In case of any issues with a particular entity - it is important to know which integration created this entity. Next possible steps - reloading the integration, switching on debug logging, localizing a bug etc.

2 Likes
11

Not to mention just the simple basic organization that I like to maintain.

And If I’m using a particular integration and the decide I don’t need it I’d like to know ahead of time which entities I may be using from it in my system that may break. If they aren’t named properly to delineate which integration they are from then it becomes very hard to know what to search for in the config.

That’s good to know. Thanks.

But that’s just the first example that came to mind as the basis for the FR. I’m sure there are others.

And that also illustrates my point…since I can now delete the Sonos Cloud entities from my automations/scripts I have to know which entities are being provided by that integration vs the built-in integration.

And there’s no list anywhere that specifies only the entities associated with that integration.

12

{{ integration_entities('slug') }}

also, don’t get all upset that it’s a template, just providing a way to find it. This is the list you are asking for, just use it until it’s in the UI.

get the slug from url when you click on the integration in the integration page.

image
image694×44 1.84 KB

1 Like
13

So, an integration name is always same as given in a link?
изображение

14

I’m not sure. I believe it is, but it could not be. Either way, there are ways to get the slug with templates too.

15

Sry, work called. Here’s a 1 liner that gets you the list of integrations available for use

{{ states | map(attribute='entity_id') | map('device_attr', 'identifiers') | reject('none') | map('list') | map('first') | map('first') | reject('undefined') | unique | list }}
1 Like
16

Great, thank you!
Interesting, here is what I got:

изображение

and I wonder what “Home Assistant” stands for:

изображение
изображение694×177 7 KB

17

not sure. Could just be an issue with the template, doesn’t work for me either.

integrations:
{%- for integration in  states | map(attribute='entity_id') | map('device_attr', 'identifiers') | reject('none') | map('list') | map('first') | map('first') | reject('undefined') | unique | list %}
  {{ integration }}:
    {%- for entity in integration_entities(integration) %}
    - {{ entity }}
    {%- endfor %} 
{%- endfor %}

That will list out all the integrations and the entities. Keep in mind yaml integrations won’t typically show up in this.

EDIT: I altered the template, it seems there’s 1 entity that outputs Home Assistant.

It’s the sensor.current_version entity, which is the version integration. Looks like that’s an exception to the ‘rule’, however the URL method works for that.

18

You are using a very tricky template. Is there some kind of UML-like object diagram describing associations between terms “integration”, “device”, “entity”?

19

There’s a glossary that covers these terms.

The template is tricky because identifiers is a set, and you have to jump through hoops to use sets properly in jinja.

A set is a python object that has specific functionality. It’s very nice in python, but limited in jinja.

As for ‘object structure’ or UML. These are separate systems.

device_attr gets you attributes on a device, which is part of the device registry.

If you’re talking about HA. There’s 2 levels. Device and Entity. Integrations can add entities to any device. Most likely, you have 2 integrations with the same seed information so they get put on the same device. A device is meant to represent a physical device. So multiple integrations will add entities to the same device.

I highly doubt anything will come out of this FR because this is the intended design. I could see some change to the UI to potentially let users know what integration the entity comes from.

20

I recall that Taras said that sometimes this may not be used to get an integration - is it still valid?
(I have not analysed your template properly yet, so my question could be rather hasty)