Metrics: how to access advanced integration, Supervisor and HA internal information

[e-raser]

Hi,

for some statistics template sensors I need the following information, which doesn’t seem to be available in the recorder database (using {{ states.something | list | length }} unfortunately.

Where is this information stored? (wild guesses: a) database but not exposed to Jinja therefore SQL selects needed, b) directly in e. g. core.device_registry file of hidden config subfolder)

And much more important: How can I access that information the easiest way?

Few examples what I’m currently specifically looking for:

1. INTEGRATION INFORMATION

1. Number of devices integrated by a specific integration (e. g. Shelly, deCONZ, …)
   → Using a command_line sensor with command: 'cat /config/.storage/core.device_registry | grep 'deleted_devices' -B 100000 | grep -c '"integration_shortname"'' where integration_shortname can be e. g. deconz, shelly, mobile_app, kodi, fritz etc.

2. Number of entities integrated/provided by a specific integration (e. g. Shelly, deCONZ, …)
   → See solution for 1.1 above, but use the core.entity_registry file instead: using a command_line sensor with command: 'cat /config/.storage/core.entity_registry | grep -c '"integration_shortname"'' where integration_shortname again can be shelly etc.
   → There’s a much smarter solution for this, see Metrics: how to access advanced integration, Supervisor and HA internal information - #12 by e-raser / Metrics: how to access advanced integration, Supervisor and HA internal information - #8 by CentralCommand.

3. Number of instances of a specific integration (e. g. number of mobile devices integrated using HA Companion App/“Mobile App”)
   → Depends on how the integration handles multiple instances. E. g. for kodi and mobile_app integrations every device integrated with that integration is handled as “instance”. Therefore see solution for 1.1 above.

4. Attribute information of a device, e. g.:
   
   → This information is also stored in the core.device_registry file, see 1.1 above. Without deep diving into “how to query a json file using the command line (with all the limitations HASS OS has)” it’s a bit tricky to exactly get what is needed, but it’s there. To get the version string information from the screenshot I used 'cat /config/.storage/core.device_registry | grep -A 3 "Dresden Elektronik" | grep "sw_version" | cut -c32- | rev | cut -c3- | rev' as command for a command_line sensor, so it’s very specific. I could not find an easier way unfortunately.
   → There’s a much smarter solution for this, see Metrics: how to access advanced integration, Supervisor and HA internal information - #12 by e-raser / Metrics: how to access advanced integration, Supervisor and HA internal information - #8 by CentralCommand.

2. SUPERVISOR INFORMATION

1. Number of installed Supervisor addons
   → Using a command_line sensor with command: 'curl http://supervisor/supervisor/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | grep -o '"name"' | wc -l'
   → Alternative command with same output: curl http://supervisor/addons -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | grep -o '"installed": true,' | wc -l
   → There’s a smarter solution for this if using the hassio (Supervisor) integration, see Metrics: how to access advanced integration, Supervisor and HA internal information - #12 by e-raser / Metrics: how to access advanced integration, Supervisor and HA internal information - #8 by CentralCommand.

2. Number of (in)active Supervisor addons
   → Using a command_line sensor with command: 'curl http://supervisor/supervisor/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | grep -o '"state": "started",' | wc -l'
   → There’s a smarter solution for this if using the hassio (Supervisor) integration, see Metrics: how to access advanced integration, Supervisor and HA internal information - #12 by e-raser / Metrics: how to access advanced integration, Supervisor and HA internal information - #8 by CentralCommand.

3. HA INTERNAL INFORMATION

1. Number of (active) HA user accounts (not persons, that´s easy using {{ states.person | list | length }})
   → Using a command_line sensor with command: 'cat /config/.storage/auth_provider.homeassistant | grep -c '"username":'''

2. Number of existing blueprints of type “automation” or “script”
   → Using a command_line sensor with command: 'find /config/blueprints/automation/ -type f | wc -l' (gives all blueprints of type automation, use folder /script for Scripts, using /blueprints will count all blueprints)

3. Number of areas
   → Using either a command_line sensor with cat /config/.storage/core.area_registry | grep -o '"name": ' | wc -l (counts all areas, doesn’t matter if there are devices or entities assigned to it)
   → Or {{ states|map(attribute='entity_id')|map('area_name')|reject("==",None)|unique|sort|list|count }} (thanks to @MizterB (see Metrics: how to access advanced integration, Supervisor and HA internal information - #13 by MizterB) which only works if all areas contain at least one active entity.
   → Hint: Remove | wc -l or |count for a list of all area names, otherwise all areas are count.

Thankful for everything - from a simple hint “maybe you wanna try this direction…” up to “here it is: use this magical piece of code…!”

---

Update: job done!

A few hours of investigation, research, mostly try & error I made everything on my own, step by step. I added what I found/used on every single step / information demand above. Without any guarantee, some things are very specific to my environment (integrations, hardware and so on I use). Without investing further hours I could not find smarter ways to get the information I need.

Update: added smarter solutions!

Smarter solutions have been added, highlighted with the icon. Always referring to Metrics: how to access advanced integration, Supervisor and HA internal information - #12 by e-raser / Metrics: how to access advanced integration, Supervisor and HA internal information - #8 by CentralCommand.

• Quite helpful resource:
  Entities: integrating devices & services | Home Assistant Developer Docs explaining area, entity and device registry (the places HA stores everything which is not kept in the database, so those are really the base for whole HA) - see e. g. /config/.storage/core.area_registry but CAUTION don’t change or delete anything (reading should be safe)! Backup is key anyway.
• For basic information (the stuff you usually start with and which should be sufficient for basic statistics needs) have a look at How much entities do you have in Homeassistant?, particularly this posting with a simple 3-liner: How much entities do you have in Homeassistant? - #9 by poudenes.

[e-raser]

No one with an idea? Impossible…

[aceindy]

Is this helpful?

How much entities do you have in Homeassistant?

I believe my hobby of home automation is getting a bit out of control . To check how bad my addiction is I would like to understand how many devices/automations/sensors other people have integrated into Homeassistant. Figuring this out is easy: just go to to the developer tools -> Template and put the below code in there. Sum the total and use that in the poll (feel free to copy paste the result in the comments :-)) Sensors: {{ states.sensor | count }} Lights: {{ states.light | count }} S…

[e-raser]

Thanks. Basically yes, helpful. But for my current state/need: no, not helpful, I got all those basic numbers already. I miss some more advanced one, a bit more difficult to get.

I updated what I have and what I still miss in the op.

[e-raser]

Getting the number of integrated devices. Not bulletproof, but should work for most cases:

devices_total

command_line sensor with command: 'cat /config/.storage/core.device_registry | grep -c '"config_entries": ''

+ devices_active

command_line sensor with command: 'cat /config/.storage/core.device_registry | grep 'deleted_devices' -B 100000 | grep -c '"config_entries": ''

+ devices_inactive/devices_disabled

command_line sensor with command: 'cat /config/.storage/core.device_registry | grep 'deleted_devices' -A 50000 | grep -c '"config_entries": ''

[e-raser]

Update: Job done . Original posting updated.

[CentralCommand (Mike)]

@e-raser

Number of entities integrated/provided by a specific integration (e. g. Shelly, deCONZ, …)

The integration_entities filter just answers this I believe, no need to parse files in .storage.

{% set integration_name = 'deconz' %}
{{ integration_name | integration_entities }}

@e-raser

Attribute information of a device, e. g.:

If you need a specific attribute of a device then use the device_attr filter. That firmware field is sw_version in the registry, so like this:

{% set entity_id_in_device = 'sensor.basement_dehumidifier_outlet_energy' %}
{{ device_attr(entity_id_in_device, 'sw_version') }}

@e-raser

Number of installed Supervisor addons

@e-raser

Number of (in)active Supervisor addons

I see you solved these but if you want to do it without curling supervisor you can just query the hassio integration. For number of installed:

{{ integration_entities('hassio')
    | select('search', '_running$')
    | list | count }}

And for just the ones running:

{{ integration_entities('hassio')
    | select('search', '_running$')
    | expand | selectattr('state', 'eq', 'on')
    | list | count }}

Just a thought. I know I’ve been working on my main update notifications stuff to do less curling of supervisor now that we can simply query the hassio integration and its devices in a template.

[e-raser]

Thanks a lot! I will have a look at your querys (which should always be preferred over file based or command line stuff) tomorrow and probably very likely update most of my sensor definitions.

Most important keywords (exactly what I was looking for - for days) that got me started:

• “integration_entities filter”
• “device_attr filter”

Thanks for learning more advanced YAML stuff

[tom_l]

Please don’t tag people like that. See point 16 here

How to help us help you - or How to ask a good question

Before we begin… This forum is not a helpdesk The people here don’t work for Home Assistant, that’s an open source project. We are volunteering our free time to help others. Not all topics may get an answer, never mind one that helps you solve your problem. [image] This also isn’t a general home automation forum, this is a forum for Home Assistant and things related to it. Any question about Home Assistant, and about using things with Home Assistant, is welcome here. We can’t help you with e…

[e-raser]

Good point. It’s been five days and I simply wasn’t aware of that rule 16 out of 42

[e-raser]

Alright thanks once again @CentralCommand. I took a closer look at it, still looking for two smart solutions (most important devices, also areas):

Entities of a specific integration: fine, perfect. Works even shorter without set a variable when directly using

{{ integration_entities('deconz') | list | length }}

General limitation (!): only gives entities which are active and available. Does not give unavailable or disabled entities.

Attribute information: works for devices (that don’t offer an entity) only if I know the device id - which is not exposed to the UI (but can be found in the core.device_registry file).

Supervisor addons: agree, that’s the smartest way. BUT I of course need to use all of those entities (enable them once) which I currently don’t and don’t want to (only because of this statistics requirement it’s an unnecessary overhead). Think I’ll stick to the command_line sensor path for the moment. Basically because it’s working automatically, whereas for the hassio integration I need to manually configure everything. If I install a new addon and forget to activate the corrensponding entities, this addon won’t be count. Grabbing it live from the Supervisor instead always works.

Devices: not possible, double checked Templating - Home Assistant twice. Could not find a smarter way to solve the tasks “Give me a list of all devices” or “Give me a list of all devices integrated by integration ABC” instead looking in the core.device_registry file. Very interested in a (smarter) solution for this.

Areas: “Give me a list of all areas by name” - could not be solved used the information provided at Templating - Home Assistant. I’m pretty sure it’s possible, I just don’t know why (yet). Probably some special syntax in a for loop? Very interested in a (smarter) solution for this.
Update: see Metrics: how to access advanced integration, Supervisor and HA internal information - #13 by MizterB for a solution with a states objects query (template sensor).

Blueprints: Definitely something which can only be achieved by looking at the config/blueprints folder. No YAML/Jinja magic possible here.

Updated the original post.

[MizterB]

I have also been very interested in retrieving all available area names, so I can iterate over them in a template. I finally figured out how to do so - however, this approach only works for areas that have entities assigned to them.

{{ states|map(attribute='entity_id')|map('area_name')|reject("==",None)|unique|sort|list }}

EDIT: This same approach can be applied to devices:

{{ states|map(attribute='entity_id')|map('device_id')|reject("==",None)|unique|sort|list }}

[e-raser]

Those are helpful, indeed. I’ll update the OP and reference your post.
Unfortunately it really only works if at least one entity is assigned to that area.

I have a use-case where I store device_tracker devices of my guest wifi in a dedicated area. All entities of those devices are disabled. So this area is not count. That seems to be a common issue with all states objects: they only care about entities, not about devices.

Unless someone finds a way to list devices in areas too, the command_line sensor (cat /config/.storage/core.area_registry | grep -o '"name": ' | wc -l seems to still be my way to go).

[Sand]

Nice template. Adding a bit to it we can get the list of device names etc…

{% set device_ids = states|map(attribute='entity_id') | map('device_id') | reject("==",None)|unique|sort|list %}
{%- for device_id in device_ids %}
{{ device_attr(device_id, 'name') }}
{%- endfor -%}