Heads up! Upcoming breaking change in the Template integration

[bdraco (J. Nick Koston)]

If you want specific time control (or more control in general since automations are far more powerful) of when an entity is updated, an automation makes a lot more sense for the use case:

Heads up! Upcoming breaking change in the Template integration

If you want to limit updates to only a specific interval, something like this will work: - id: '1600355905751' alias: Update Unavailable Entities description: '' trigger: - platform: time_pattern hours: '*' minutes: '15' seconds: '0' condition: [] action: - service: input_text.set_value data: value: "{{ states | selectattr('state', 'in', ['unavailable', 'unknown', 'none']) | list | length }}" entity_id: input_text.unavailable_entities mode: single

[123 (Taras)]

@amelchio

Do you really mean that? If it could be made very fast you would still prefer to have a delayed update?

It’s possible you took what I wrote out of context. I was referring specifically to mf_social’s template whose purpose is to identify unavailable entities.

What are the odds of entities in these domains being unavailable: automation, zone, script, scene, etc?

If the odds are next to zero then it stands to reason one shouldn’t check them. In other words, for the purpose of this specific template, we don’t need to assign listeners to entities in those domains. However, that’s precisely what happens given that the template begins with {{ states | etc ... }}. Therefore the template is evaluated for every possible state-change in the system, including entities that have no practical impact on this particular template.

That’s why I suggested narrowing the field by using something like {{ expand(states.sensor, states.binary_sensor, states.light, states.switch) | etc ... }}. At least this way listeners are assigned exclusively to the kind of entities this template is interested in and updated only when one of these ‘entities of interest’ changes state.

[123 (Taras)]

The automation won’t supersede the listeners that the system will automatically assign to the entities it detects in the complex template.

That was my point; there’s no longer a means of superseding the automatic assignment of listeners. My automation might be evaluating the template every 15 or whatever minutes but that complex template will also be evaluated by the boatload of automatically assigned listeners.

[bdraco (J. Nick Koston)]

The automation isn’t using a template entity.

[Mutt (Muttley)]

@bdraco

The automation isn’t using a template entity.

AND its not a sensor.
It writes to an input text

[123 (Taras)]

I see what you mean; use an automation instead of a Template Sensor.

That begs the question, how are the results of this automation supposed to be reported? I know I can publish via an MQTT Sensor but, man oh man, this is a long way around for what was easy-peasy with a Template Sensor.

@Mutt

AND its not a sensor.
It writes to an input text

Precisely and feh!

[amelchio]

@123

It’s possible you took you what I wrote out of context.

Sorry, I read it again now and see that I picked a poor quote to frame my point. The point still stands, though … just skip my first paragraph

[Mutt (Muttley)]

So create a sensor that reads the input text

Early flagelation of post animation equus ferus negated

(cpu death prevented)

[bdraco (J. Nick Koston)]

Based on some of the provided templates, and feedback there are a few more template performance improvements coming in 0.116

https://github.com/home-assistant/core/pull/40012 (merged)

https://github.com/home-assistant/core/pull/40250 (waiting for review)

https://github.com/home-assistant/core/pull/40272 (builds on #40250)

https://github.com/home-assistant/core/pull/40323 (builds on #40272)

[123 (Taras)]

Can you elaborate on what the PRs mean when they state they improve performance of templates involving “counting states”?

What comes to mind is the count filter but I doubt that’s what the PRs mean.

[bdraco (J. Nick Koston)]

It is anything that looks at the number of states but does not access the state object attributes. The count filter is a good example of this.

[sparkydave (🇦🇺 Dave)]

@Mutt

Dave currently resides in the UK

Thanks heaps for the code help, I’ve copied it across not, time to test . I’m actually in Kangaroo land though

EDIT: and in the west here we don’t have daylight savings because the farmers are worried that the cows will get confused

[petro]

That explains the sideways picture

[Mutt (Muttley)]

@sparkydave

EDIT: and in the west here we don’t have daylight savings because the farmers are worried that the cows will get confused

Sod the cows (just don’t give them watches), it’s me that gets confused with DST

I’m working out a ‘foolproof’ way (if it works for me it’s foolproof) of sorting this, I hope to come back to it soon.

So are you doing a Priscilla thing, visiting family or back for good ? (and is that because I called you Mike ?)

Cheers

[DavidFW1960 (David)]

At least we put our clocks forward by 1 hour so that’s one less hour of 2020 we have to endure…

[Mutt (Muttley)]

Don’t worry, come October there’s an hour in there we’ll make you live twice (a la groundhog day)

[DavidFW1960 (David)]

No that will be April 2021. We go forward an hour in a week or so.

[Mutt (Muttley)]

Ah, southern hemisphere…

[Mutt (Muttley)]

We are last weekend in March and last weekend in October (forward and back)
So you are back and forward in???

[anon43302295]

@123

What are the odds of entities in these domains being unavailable: automation, zone, script, scene, etc?

I don’t actually use scenes and zones, but I’m fairly confident that their state objects never change, they are just either there (scening and zoning) or not.

So I think that only listening to automations and scripts is ‘extraneous’, but I don’t think it’s ‘expensive’.