It all depends. That is why I keep asking for actual templates.
With that trigger, I was responding to mf_social who does not have those issues and thus specifically asked how to look at all state changes.
1 Like
well, I am so glad you phrased it in your own words now.
This is what its all about isnāt it? This exactly proves my point different users could require different solutions for identical code in different circumstances.
Where Marc has no issues whatsoever with that code, my system grinds to a halt. As always oneās mileage may vary.
This is the exact reason I try to ask for end-user configurability, on frequency and entity_id update limiting. If all is ok, no extra need for limiting the auto-updating of the current template engine. If the situation arises, we need these 2 options (no more than that, so itās not the world we ask here, and donāt forget, we hadā¦ ).
if so implemented, Marc would have this template run at all times, without further ado, and no extra limiters set (implemented the 115 way, not like it is now), and eg I would have to set a limiter (take sensor.date), and could run it only once, on demand.
But isnāt that in the eye of the beholder?
There have been several templates given in this thread (and I believe in that issue where the discussion was taking place) but apparently someone has deemed them āuselessā.
I could be wrong but at least some people found them āusefulā or they wouldnāt have spent time developing those templates in the first place. And others wouldnāt have adopted them.
So that said can anyone provide a definition of what the powers-that-be will deem āusefulā? (To them? To us? 
)
1 Like
Not at all, the changes in 0.116 address most of those examples with the rate limiter (including your two sensors mentioned in the GitHub issue).
I am asking for examples that still have problems. They just have to be useful to you but it is much better if they real, not a theoretical invention just to prove a theoretical point. Also, showing the actual template helps so much in understanding the prose that describes a problem.
Marius has admitted that his examples were not the best ones but did not provide other examples. And a few posts ago he says that there are no performance problems left, so I am actually not sure what the problem is at this point.
maybe this is a communication of non-native language problemā¦
really sorry, but when I spoke of performance problems in that sense, I meant no other performance issues in the instance, besides the issues of the templating engine. I would have thought that to be clear.
Is it so difficult to understand what the posters in this community are trying to bring across? It all boils down to what you have summarized yourself:
At least @123, @anon43302295 @klogg @finity and I have provided more than 1 template, that each in their own instance fills to their needs, and not always behaves the same, depending on configuration and instance. It is not very clear what more you could need.
The bottomline problem is that we donāt have the option anymore to limit the update frequency of the templates.
(The fact the new templating engine is upping the processor usage too is purposely kept out of this discussion, since I donāt want to risk you might think I want the new behavior of identifying states to be revertedā¦)
The language barrier definitely exists but I do understand that you liked it just fine with entity_id.
However, that could be due to change resistance, Stockholm syndrome, nostalgia or just misunderstandings.
I am not saying that it is any of those things but it could be. Not providing a single template when I ask three times is not helping me discard the suspicion.
That is not a problem. Using 11% CPU rather than 7% CPU is also not a problem by itself. Especially not if the increase is due to automatically including entities that were unknowingly missed by the manual setup.
A crashing system is a problem. Light actions being delayed for a second is a problem.
1 Like
we clearly live in another world. I am lost why you would use these phrases at all, and in all honesty, feel really affronted.
Ill leave this be for now, since it is going nowhere.
especially if this is the feeling of the core team:
and this is not true:
unless you translate āunknowinglyā by āhaving not read the documentationā.
1 Like
But, unfortunately that is a ham-fisted approach to fix a problem imposed by the template system change. An approach that not all people would necessarily desire to use if given any alternative.
The really unfortunate thing is that there were solutions proposed to allow the user to āhave their cake and eat it tooā that was summarily nixed because, as you said, there is a resistance to adding ābuttons & knobsā. Iām not sure if the person who pulled the plug noticed or not but this whole project is nothing but buttons & knobs. Itās baked in. Why is there a resistance to adding a couple more that would allow users the flexibility to ārate limitā or ānot rate limitā or āset another type of rate limitā?
Especially since the solutions were already created and all the work was already done and ready to be incorporatedā¦until it wasnātā¦and now never will be.
2 Likes
My biggest concern here is why is this affecting some users really badly and others didnāt notice a single bit of an issue? @finity 's system is more powerful than mine, but his system is heavily impacted by these changes and mine hasnāt skipped a beat.
To my mind this shows that there is something else going on somewhere and we need to discover it and address it, otherwise the devs will be chasing their tails trying to find an āideal solutionā for everyone in the wrong place.
2 Likes
Someone call the mods because I think amelchioās account has been hijacked. Only thing missing is that weāre all āDemocratsā. Otherwise, the amount of gaslighting and disingenuousness makes it a dead ringer for the Twitterer in Chief.
Iām not sure itās true but I hear people saying that ā¦
1 Like
ok so, im trying to keep up here, however I had a pretty big issue.
My irrigation didnt shut off and flooded my yard. Wife. Not. Happy.
here is what I have for shutting it off, that no longer is working. (worked fine for months) Unsure If related to these changes or not. Hoping someone can at least see the error. im on 0.115.6.
The automation:
- id: irrigation_zone_2_off
alias: Irrigation Zone 2 Off
initial_state: true
trigger:
- platform: numeric_state
entity_id: sensor.zone_2_time_remaining
below: 1
condition:
- condition: state
entity_id: switch.drip_system_zone
state: "on"
action:
- service: switch.turn_off
entity_id: switch.drip_system_zone
the sensor:
- platform: template
sensors:
zone_2_time_remaining:
friendly_name: "Time Remaining"
value_template: >
{% if is_state('switch.drip_system_zone', 'on') %}
{{ [ (states('input_number.zone_2_run_time')|int - (as_timestamp(now()) - as_timestamp(states.switch.drip_system_zone.last_changed))/60)|round(0) ,0 ] | max }}
{% else %}
0
{% endif %}
unit_of_measurement: "min"
It does not shut off if the time remaining goes below the set 1 minute. just keeps on keeping on.
Anyone know whats going on here?
Sorry, I was not intending to offend anyone. I was trying to explain why I keep asking for examples. Lamenting the loss of the old way is not quite sufficient to establish that the new way does not work.
Anyway, I agree that we are going nowhere so I will leave this thread as well.
1 Like
add states('sensor.time') to your template.
1 Like
Perfect. Thanks!
{% set x = states('sensor.time') %}
Did it use the entity_id option during all those months and you removed it recently?
yes probably so. I did go through and remove all the entity_id: like a week ago.
Without mitigating its removal? Iād warn you thatās a recipe for disaster but you already discovered it empirically:
I recommend you review every entity where you removed entity_id but overlooked to compensate for it. Those entities are now possibility compromised. See the first post of this thread for guidance.
1 Like
Lol. Yes that is a good idea and I did look over most of it and had to make a few changes such as adding the time or date sensor to a few others last week. Looking back now, I actually just commented out all the entity_id so I must not have had it in that template and it appears that the only other semi important stuff that might cause issues is the vacuum. but so far everything else has seemed to be okay except for this.
Great advice though! thanks.
hmmm, thatās not it, itās looking forward and trying to get User control over updating, instead of having a brute force machine always update on state changes, or, as is the case now in 116, at a fixed rate of once per minute. That might even be too frequently, when it needs to be only once a dayā¦
have a look here, weāre back to creating groups Template sensor stopped working on 0.116 Ā· Issue #41582 Ā· home-assistant/core Ā· GitHub which is fine of course. But a long time ago, we were told to have as few groups as possible, because that would only create overhead in the state machine, updating on all states in those groups.
Seems that for all previous template sensors with entity_id: we now best create dedicated groups and use the expand feature? That would at least cover the entity limiting control we need.
If we could find a way to have these {{states|ā¦}} template update only on request, and not each minute, we would have frequency control again.
wouldnāt that be the feature request we need now: have templates with {{states|...}} not update at all, adding a {% set trigger = states('sensor.time/date') %} to it to update automatically, or, donāt add anything, and create an automation/script with the timing and update.
update
this seems to have had a followup:
listing using expand(), with all single entities , where we previously used entity_id:
bit of a detour imho. and way less elegant than (sorry, dont want to look back too much now) entity_id: ā¦
need some help on python here, as Iāve previously used a group.all_lights_only with all lights listed individually and use that like this
group = 'group.all_lights_only'
fname = 'Lights'
on_format = 'Lights on: {} -- {}'
off_format = 'No lights on since '
filter = 'on'
pic = 'lamp_off|lamp'
icon = 'mdi:lightbulb'
# min_show = 0
count = 0
desc = ''
for entity_id in hass.states.get(group).attributes['entity_id']:
state = hass.states.get(entity_id)
etcetc
to count and show the individual lights being āonā.
now with the nested groups being
all_lights_only:
name: All lights only
icon: mdi:lightbulb-outline
entities:
- group.all_inside_lights
- group.all_outside_lights
all_inside_lights:
name: All inside lights
icon: mdi:lightbulb-outline
entities:
- group.main_inside_lights
- group.guest_inside_lights
- group.living_ceiling_spots
all_outside_lights:
name: All outside lights
icon: mdi:flood-light
entities:
- group.outside_flood_lights
- group.terrace_outdoors_spots
etc
etc
this python script sees the group.all_inside_lights as being on, and displays and counts that group,(which is correct, as it is the entity_idā¦) instead of counting and listing the individual lights in that group.
Please help me change this python script to again iterate over these nested groups?
thanks!
(sorry if this is not exactly on topic, but it a follow-through of the new templated options using expand() in HAā¦)
and to be back on topic, I wonder if this could be more compact now:
sequence:
service: light.turn_off
data:
entity_id: >
{% set ns = namespace(group=[]) %}
{% if is_state('group.guests','not_home') %}
{% set ns.group = expand('group.all_inside_lights') %}
{% else %}
{% set ns.group = expand('group.main_inside_lights' , 'group.living_ceiling_spots') %}
{% endif %}
{% set lights_on =
ns.group|selectattr('state','eq','on')|map(attribute='entity_id')|list %}
{{lights_on|join(', ') if lights_on|length > 0 else 'none'}}