Many people aren’t. I just had a random thought based on @jazzyisj comment about the pi, and I’m wondering if those that are having performance issues are all on arm processors or there is some other correlation that needs to be looked into.
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 
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? 
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 
) 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 
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(',') }}
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 
Now I have to go through all my stuff and do this 
haha yes, that really neat, never thought of a custom attribute like type. as @SupremeSports says, opens up a whole new world
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|....