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/
Thank you VERY much
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)
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…
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.
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.
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|....
{{ expand(states.sensor, states.light) | etc ... }}
of course, not yet used to that completely… thanks!
{%- for s in expand(states.binary_sensor, states.sensor)
if 'diskstation' in s.entity_id %}
{{s.entity_id}}{% if not loop.last %}, {% endif %}
{%- endfor %}
though, it still would be (much) more efficient to create a true group and have that tracked.
This is a very fine way for us yaml users to easily select all entities to create the group with.
nice.
Devs are aware of the issues and it looks like they are already working on a fix. It isn’t just this sensor causing problems, it’s all states based templates. I had dozens of them scatted throughout my config. I’ve temporarily disabled them all and the performance difference is night and day. My UI is snappy even on mobile and it never was before.
I think maybe these templates were always causing an issue but most of them were being throttled by sensor.time or the other monitored entities so it wasn’t as apparent. Probably not as pointed out by @123
Really hope they get this worked out, the states based templates are very useful!
No. Prior to 0.115, states and domain-based variations like states.sensor, states.light, etc were never assigned listeners. As a result a template like this:
{{ states | list }}
would get no listeners and so the template would only be evaluated at startup and never again (until the next startup). That’s why you supplied:
entity_id: sensor.time
so that the template would be evaluated periodically (once a minute, corresponding to when sensor.time changes state).
In 0.115, the entity-identification technique is far more clever. Now it understands states means all entities so it listens to all entities. In other words, when any entity in your system changes state, the template get evaluated. For most users, that’s far more frequently than just once a minute.
Notice what the last line says for this template:
There are a few PRs in the pipeline designed to provide the user with more control over how the template is evaluated. For example, one PR introduces a means to control the frequency of evaluations (with far more flexibility than merely once a minute or once a day).
Thanks for clarifying. I haven’t had time to dig into the nuts and bolts of the changes. I guess the other improvements in v115 are the cause of all my giddiness right now. 
Seriously, for me the performance difference in the last couple versions has been nothing short of amazing. I’m still chugging along with a fairly extensive config and an RPi3 and an SD card so needless to say, I notice it!
I recall one post where bdraco calculated how many evaluations a user’s template was undergoing (based on the number of entities they had which was around 2500) and the result was several billion times a day. Clearly, that’s enough workload to become, to put it mildly, noticeable.
For the moment, the best solution is to, wherever possible, avoid using states in a Template Sensor. The proposed new controls will make it easier in the near future but for now, the simplest mitigation technique is to re-design the template.