you could use the python script I posted and use an automation to trigger on event state_changed.
As far as I understand it all now, that wouldn’t only be the best, but also the only way… you might not want it, but following Amelchios schedule, there’s no other way of using states, and have factual updating
hence my fist bullet in the reply to that, was especially aimed at your needs
Appreciate the suggestion, although I fear I’ve missed the python_script you’re talking about somewhere in the haze of all of this. Let’s call that a fallback option for now and see if anyone can think of a way to just adapt the template to fulfil the requirements
Yeah, I think that automation is going to be my preference then (I was holding off moving to it whilst I was watching all the changes and then got confused), although the condition only looks for ‘new_state’, can I presume that the opposite of that is ‘old_state’ so that it also updates when the entities come back online?
Thank you. I have corrected second/minute in my post to prevent misleading others.
That’s word-play. Here’s what you said:
I agree it is no longer simple to understand. The good news is that it is simple to use so a lot less people will have to understand it now.
…
Again, one should usually not have to think about this.
As for the following opinion:
Look around. This forum is filled with technical support questions asking why Home Assistant behaves the way it does. Quite a few people don’t merely shrug off Home Assistant’s behavioral quirks.
this of course is a viable option, but, viewing this from the minimizing-processor-impact effort, you now have created both a group and sensor, which both will be tracked on all state changes of the containing states.
Or, all states even, considering this:
Nicely done, employing all the new features introduced in 0.115.
It’s clear that some Template Sensors will have to be re-designed due to the new way templates are evaluated. This thread’s purpose is how to adapt one’s templates to the deprecation of entity_id. Over the course of this thread, it has been a struggle to convince the development team that some functionality was lost in 0.115 … and how do we adapt to it.
To their credit, they did address some of the deficiencies with changes in 0.116 and with more changes coming in 0.117.
I believe the sum of these changes will address most of the identified issues and maintain good overall performance (I look forward to confirming that in 0.117). The two exceptions are:
Some applications will require more complex solutions.
Templates like the one used by the ‘unavailability sensor’ will have to be re-engineered in the manner demonstrated by Petro or like Mariusthvdb did using a python_script. Yes, it becomes more complicated than in the past but the development team feels this represents a minority of applications. Time will tell.
No daily template evaluations.
There will be no practical way of ensuring a template is evaluated just once a day. If you use now() anywhere in the template, it will be evaluated once a minute. In a separate GitHub discussion, balloob stated that the extra processing (1440 times a day vs once) is not a significant amount of daily overhead, even for an RPi. In 0.117, keep an eye on CPU usage and see if the prediction proves to be true.
Based on my newfound understanding, I believe it will update minimally once a minute, due to the presence of now().
It will also update whenever any of the input_booleans change state (which is probably far less often given that you are using them to set the irrigation schedule).
You will be able to remove the reference to sensor.date because now() supersedes it in terms of frequency.
Yes, if you can perform the date/time calculation without employing now() then the evaluation frequency will be determined by the other entities within the template. In your case, that would be sensor.date, so just one evaluation per day.
It’s not as neat as using now().weekday() but at least it allows you to constrain the template’s evaluation frequency. Of course, all bets are off if the template employed states.DOMAIN.
BTW, I think this template achieves the same desired outcome:
- platform: template
sensors:
zone_1_day_active:
friendly_name: Irrigation Day Active
value_template: >-
{% set today = as_timestamp(states('sensor.date'))|timestamp_custom('%a') | lower %}
{{ is_state('input_boolean.zone_1_' ~ today, 'on') }}