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
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.
{{ 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.
1 Like
So, an integration name is always same as given in a link?
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.
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
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.
You are using a very tricky template. Is there some kind of UML-like object diagram describing associations between terms “integration”, “device”, “entity”?
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.
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)
That’s because whoever made the discovery for that device didn’t make it correctly. MQTT is the only integration that will have that. All other integrations, that would be considered a bug. But because MQTT has the unique ability to create devices via configuration or discovery (which is controlled by the user), then you’ll run into those situations.
EDIT: I.e. if you set up your MQTT discovery information but omit device_identifiers, that’s how it won’t show up in the list.
good
{
"name":null,
"device_class":"motion",
"state_topic":"homeassistant/binary_sensor/garden/state",
"unique_id":"motion01ad",
"device":{
"identifiers":[
"01ad"
],
"name":"Garden"
}
}
won’t show up
{
"name":null,
"device_class":"motion",
"state_topic":"homeassistant/binary_sensor/garden/state",
"unique_id":"motion01ad",
"device":{
"name":"Garden"
}
}
I could be mistaken but I thought the difference between a FR and a bug report is that the FR is requesting a change in the intended design? (no disrespect intended…)
But again as long as there is a way to differentiate between device entities coming from different integrations that would meet the spirit of the FR and I’m OK with that.
even just adding an entity attribute like “integration: zwave_js” so we could filter on it would be fine.
One other thing, if you know how to abuse identifiers with MQTT, you can attach an MQTT entity to any device. Which is a long standing WTH that many people want to do with template entities.
You aren’t mistaken, but this FR is trying to undo the past ~5 years of work. What would be easier? Making something work in the current design paradigm or scrapping it completely like this FR is requesting.
And when I say easier, I’m talking development wise & convincing the people who make these decisions. It’ll be an uphill battle, which is why I said:
the 2nd part of that is implying that something could come out of this if we keep the device page but have a way to show what integration it’s coming from.
Is there a way to eliminate the warning in dev tools?
ya
{{ states | map(attribute='entity_id') | map('device_attr', 'identifiers') | reject('none') | map('list') | reject('eq', []) | map('first') | map('first') | unique | list }}
1 Like
I thought tasmota just provided discovery for MQTT. So the entities would show up under MQTT. I don’t use tasmota, so I’m basing this off second hand information.
I’m not sure for ping either.
Do this
{{ device_attr('sensor.whatever_ping_you_have', 'identifiers') }}
and post results
