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
Seems like ping is missing identifiers then.
If identifiers are added… then it’s going to put them onto devices that have the same identifiers.
I.e. if integration a uses IP as an identifier and integration b also uses IP, they will both show up on the same device.
I have a bad feeling about this that “identifiers” is a bit uncommon property.
I already explained this above
Yaml integrations don’t create devices (aside from MQTT), which is why I said “typically”.
I’d wager the ping thing was just the code owner not supplying identifiers. I’d wager an issue should be raised for ping.
correction: This is not caused by identifiers, this caused by connections.