Unavailable / Unknown Entity Monitoring - Template Sensor

Quite the difference in observed performance. I agree with mf_social that perhaps system architecture might be responsible. Basic template processing should not overtax an RPI3.

1 Like

Maybe one of you could try this (warning, it grinds my Rpi4 to a halt)

 {% set ns = namespace(domains=[]) %}
 {% for d in states|groupby('domain') %}
 {% set ns.domains = ns.domains + [d[0]] %}
 {% endfor %}

 {% set list = ns.domains|join('\n') %}
 {{list if list|count < 255 else
   list|replace('input','inp')|truncate(255,true)}}

And about the unavailable sensor, do try the python script, it is so fast, totally controllable and breaks no sweat at all

I can’t test the template as I’m not home until the weekend, but I’ve noted before that these templates causing issues seem to be doing so on arm processors, and I thought I’d mention it again so that maybe anyone that does test it can say what architecture they’re on when they report the results, as if there is a correlation then maybe the devs need to look at these changes again and make sure they are ‘computable’ on all architectures.

yes, that’s why I posted, so maybe see if this would be platform induced too. As said, using an Rpi4, 4 gb mem.

btw, I’ve moved this particular sensor to a python script too, some time ago. Which seems do much more reliable, and doesn’t harm at all.

Where can I find this script as I don’t seem to find it in this page? I’m not well versed in python and not sure how to do this…

here you go: Develop and rebuild template sensor to python_script

you need to enable python scripts in your config, using

python_script:

in your configuration.yaml
and after that, you can call the python script as a service, see https://www.home-assistant.io/integrations/python_script/

1 Like

Thank you VERY much

1 Like

YW :wink:
got a few more of those, eg creating all the counters you need… 1 click, bam, all domains/entities counted. Beats any jinja template (and wont burden the processor)

1 Like

Any chance you have them on a GitHub or anything? :flushed:

I’d like to create a dynamic group according to entity id, I’ve got plenty of pond and pool entities that I’d like to ignore for winter time as I shut power to them. Can I create a dynamic group that would exclude them in the UUN?

I had only two of these “types” of sensors (the one in this thread and another that counted various entities that I stole from Marius :wink: ) and those were the sole reason that my system was very bogged down as discussed in the other thread. It didn’t grind things to a halt but they definitely made a hit in the performance of my system. Once I removed those two sensors everything returned to normal.

I’m on an intel NUC i3.

That’s surprising as my system isn’t as powerful as yours and mine is unaffected :man_shrugging:

no, but if allowed, I gladly post here, they are rather short.

would know why not, just add the group to the exclude_entities (to exclude the group itself), and to the exclude_groups, to exclude the entities in that group.

No, I realise I forgot few words in my request, I meant how to auto generate a group with all entities that has pool or pond in the entity id

like this:

  - alias: Create Pool group
    trigger:
      platform: homeassistant
      event: start
    action:
      service: group.set
      data:
        object_id: pool_sensors
        entities: >-
          {%- for s in states.sensor
            if ('pool' in s.entity_id or
                'pond' in s.entity_id) %}
            {{s.entity_id}}{% if not loop.last %}, {% endif %}
          {%- endfor %}

this is for the domain sensors, if you other domains , you should add these of course

you could do:

          {%- for s in states
            if ('pool' in s.entity_id or
                'pond' in s.entity_id) %}
            {{s.entity_id}}{% if not loop.last %}, {% endif %}
          {%- endfor %}

but beware that this listens to ALL state changes… which is very very costly nowadays and should really be prevented. It might be better to create the 1 extra group for that by hand…

1 Like

Tip

As an alternative to using the entity’s name to store characteristics, consider storing them as custom attributes. It makes selecting entities, with common characteristics, very easy.

For example, I have created a custom attribute called type for two Hue Dimmer Switches and assigned the value CR2450. This is easily done using the UI (Configuration > Customizations) or by editing customize.yaml (see Customizing Entities).

customize.yaml

 sensor.hue_dimmer_switch_battery:
  type: 'CR2450'
 sensor.hue_dimmer_switch_battery_2:
  type: 'CR2450'

After executing Reload Location & Customizations, the new, custom attribute appears as the last item in the entity’s attributes:

Now if I wish to select all sensors whose type is CR2450 (or CR2032) I can use this template:

{{ states.sensor 
  | selectattr('attributes.type', 'in', ['CR2450', 'CR2032'])
  | map(attribute='entity_id') | list | join(',') }}

Screenshot from 2020-10-01 15-38-28

If we were to apply this technique to your example, it would look something like this:

  - alias: Create Pool group
    trigger:
      platform: homeassistant
      event: start
    action:
      service: group.set
      data:
        object_id: pool_sensors
        entities: >-
          {{ states.sensor 
            | selectattr('attributes.type', 'in', ['pool', 'pond'])
            | map(attribute='entity_id') | list | join(',') }}

The advantage of this technique is that it lets you specify as many characteristics as you wish while keeping the entity’s name short and tidy.

Note

I used the word type for the custom attribute’s name but it could be anything as long as it isn’t an existing attribute’s name.

3 Likes

That’s an awesome idea :open_mouth: Now I have to go through all my stuff and do this :rofl:

haha yes, that really neat, never thought of a custom attribute like type. as @SupremeSports says, opens up a whole new world :wink:

in the example I gave, would you know an easy (the easiest…) way to select entity_id’s from more than 1 domain, say sensor and light, without having to use states|....

{{ expand(states.sensor, states.light) | etc ... }}
2 Likes