indeed:
and change that to my if:
now with your edit, and yes those are identical:
but the |default does not work
that makes no sense, eitehr way don’t use that template anymore. You don’t need namespace.
This template will build a list of your integration, the entities, and the count. Sorted on the count.
{% set ns = namespace(items = []) %}
{% for item in states | map(attribute='entity_id') | map('device_attr', 'identifiers') | reject('none') | map('first') | select('defined') | map(attribute='0') | unique %}
{% set entities = integration_entities(item) %}
{% set ns.items = ns.items + [ { 'integration': item, 'count': entities | count, 'entities': entities } ] %}
{% endfor %}
{{ ns.items | sort(attribute='count', reverse=true) }}
well, dont shoot the messenger, I only showing what’s been returned. moving forward, that counting orde is indeed what I was after, thank you!
no need for the list of entities (now…) so took those out for the moment:
{% set ns = namespace(items = []) %}
{% for item in states | map(attribute='entity_id')
| map('device_attr', 'identifiers') | reject('none')
| map('first') | select('defined')
| map(attribute='0') | unique %}
{% set entities = integration_entities(item) %}
{% set ns.items = ns.items + [ { 'integration': item, 'count': entities | count} ] %}
{% endfor %}
{{ ns.items | sort(attribute='count', reverse=true) }}
id love the output to be a bit cleaner though, and only show Hue: 474, Wave-js: 394 etc etc so made this
{% for integration in ns.items| sort(attribute='count', reverse=true) %}
{{integration}}
{% endfor %}
but of course it still uses those dictionaries:
what would be the shortest way to that?
in the main namespace(items = []) or clearing that in the final section
Marius, how else do you get attributes out of dictionaries? You know how to do this, you’ve done it thousands of times before.
I’ve been trying to use the method described above to get information about browser_mod users and I’be been getting a strangely high number. I then came across a different technique that seems to be doing the same thing but gets a strangely low number. Can anyone help me understand what is going on? I believe neither of them is enumerating to a credible number, which by looking browser_mod integation is 16.
Technique 1 from this thread enumerates to 90:
{%- set devices = states | map(attribute='entity_id') | map('device_id') | unique | reject('eq',None) | list %}
{%- set ns = namespace(entities = []) %}
{%- for device in devices %}
{%- set ids = device_attr(device, 'identifiers') | list | first | default %}
{%- if ids[0] == 'browser_mod' %}
{%- set ns.entities = ns.entities + [ids[1]] %}
{%- endif %}
{%- endfor %}
{{ ns.entities |count }}
Technique 2 enumerates to 5:
{{integration_entities('browser_mod')|select('contains','browser_user')|reject('contains','browser_useragent')|list|count }}
The first is finding all entities created by browser mod, the second is finding only entities with a specific enitty_id.
The first method is specifically finding unique devices as well. It’s unnecessary for your application if you’re looking for entities.
{{ integration_entities('browser_mod') }}
Hi all, been following this with interest, yet I noticed that Tasmota seems to be one of those integrations for which entities cannot be enumerated using these templates. Any suggestions on how to reach a similar result with that integration?
I’m using the Tasmota integration so this lists all entities belonging to it:
{{ integration_entities('tasmota') }}
Why does Home Assistant still make it so hard to find the identifier for an integration???
custom:auto-entities allows you to filter by governing integration but that paramater requires the “secret” integration identifier…
The integration’s friendly name can be seen in several places but that is not at all useful.
I shouldn’t have to locate this topic, copy and paste @petro’s magic template into Dev Tools > Template and then visually inspect the list for the correct identifier!
It should be available to easily view from somewhere in the UI like here…
or here…
or even here…
You mean apart from the fact that you installed that custom integration in a directory named smartthinq_sensors?
No great secret really.
Yes it is quite a pain in the ass.
It’s not apparent what the domain is. The domain can be different than the name of the integration or even the friendly name of the integration. The selector should accept the friendly name. I’m not sure if @dbrunt tried it, but it would be worth trying to use the friendly name of the integration to see if it works. I’m not sure if it does. Regardless, there does need to be any easier way to get the ‘slug’.
If you’re happy to find it manually, it’s in the URL of that link and its landing page.
And i am supposed to remember that?? 
I tried it but no go…
Happy? Hmmm. That’s a great tip, and not too difficult to remember! It’ll do for now. Thanks!
1 Like
The domain is per entity and is the leading part of the entity. Like light in light.bedroom.
The integration concerned provides entities (on my system) in the light, sensor, climate, binary_sensor and switch domains. But that doesn’t seem to be what @dbrunt was after.
The integration is the directory the source code is in. In this case smartthinq_sensors. Because I know it is a custom component I can go ls /config/custom_components to fairly easily find it. I can also go to the documentation link which in two clicks ends up here ha-smartthinq-sensors/custom_components at master · ollo69/ha-smartthinq-sensors · GitHub and there is the directory name.
For an invite integration I can do the same - click the documentation link, click the link to the source, read the name.
Or do as @Troon suggests.
I was referring to the code driven domain, or ‘platform’.
e.g.
Which is what is used for config flow & config_entries (I.e. the exact information needed for selectors)
As I understand (and I am probably about to be educated) platform and domain are different. But as I say my understanding may be limited.
Ideally, it would be nice if auto-entities were enhanced to provide a selector list of available integrations. Same for the other filter selections. I’ll propose it as a feature request…
1 Like
imagine having more than 1 config_entry under the same integration
example: 1 for each Hue bridge looking like:
we can template those in HA with
{{integration_entities('Philips Hue 1')}}
but cant use that in auto_entities unfortunately
we can only use the integration filter on the main integration, like
include:
- integration: hue
But, fortunately, there is the template filter option, which allows us to use the jinja template and return entities for the individual config_entries
type: entities
entities:
- type: custom:auto-entities
card:
type: entities
filter:
template: >
{{integration_entities('Philips Hue 1')}}
in its basic form
btw, there is also the option to do:
type: entities
entities:
- type: custom:auto-entities
card:
type: entities
filter:
include:
- device: Philips Hue 1
but that only lists the entities on the device itself (some bridge automations, scenes etc) and not the lights or sensors connected to the bridge.
2 Likes
Here’s my slightly improved version which removes the No first item, sequence was empty message in Dev Tools, and sorts the list…
{% set devices = states | map(attribute='entity_id') | map('device_id') | unique | reject('eq',None) | list %}
{%- set ns = namespace(integrations = []) %}
{%- for device in devices %}
{%- set ids = device_attr(device, 'identifiers') | list | first | default %}
{%- if ids and ids | length == 2 %}
{%- set integration, something_unique = ids %}
{%- if integration not in ns.integrations %}
{%- set ns.integrations = ns.integrations + [ integration ] %}
{%- endif %}
{%- endif %}
{%- endfor %}
{{ ns.integrations | sort }}
1 Like
This can all be shortened to a 1 liner now.
I posted this here yesterday.
{{ states | map(attribute='entity_id') | map('device_attr', 'identifiers') | reject('none') | map('list') | map('first') | map('first') | reject('undefined') | unique | list }}
sorted
{{ states | map(attribute='entity_id') | map('device_attr', 'identifiers') | reject('none') | map('list') | map('first') | map('first') | reject('undefined') | unique | sort }}
warningless
{{ states | map(attribute='entity_id') | map('device_attr', 'identifiers') | reject('none') | map('list') | reject('eq', []) | map('first') | map('first') | unique | list }}
warningless sorted
{{ states | map(attribute='entity_id') | map('device_attr', 'identifiers') | reject('none') | map('list') | reject('eq', []) | map('first') | map('first') | unique | sort }}
3 Likes