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') }}
Yup, that will have to be the suggested workaround wherever once-a-day evaluation is desired
Kind of a shame considering now() is a datetime object with many useful methods that will now have to be replicated via a more long-winded technique. Nevertheless, it’s an acceptable workaround for the few who wish to preserve the old behavior.
FWIW, I will need to amend the first post of this thread to reflect the changes implemented in 0.116 and the upcoming change in 0.117. The suggestions currently offered in the first post are no longer valid.
@Mariusthvdb@123@tom_l you don’t want to use as_timestamp. You want to use strptime(). as_timestamp assumes everything is UTC unless specified. The strptime method assumes local. the strptime method on a datetime object assumes local or utc depending on the object.
{{ strptime(x, format) }} # this is the method
{{ now().striptime(x, format) }} # this is the method on a datetime object
{% set weekday = strptime(states('sensor.date'), '%Y-%m-%d').strftime('%w') | int %}
{{ ( is_state('input_boolean.zone_1_mon', 'on') and weekday == 1 )
or ( is_state('input_boolean.zone_1_tue', 'on') and weekday == 2 )
or ( is_state('input_boolean.zone_1_wed', 'on') and weekday == 3 )
or ( is_state('input_boolean.zone_1_thu', 'on') and weekday == 4 )
or ( is_state('input_boolean.zone_1_fri', 'on') and weekday == 5 )
or ( is_state('input_boolean.zone_1_sat', 'on') and weekday == 6 )
or ( is_state('input_boolean.zone_1_sun', 'on') and weekday == 0 ) }}
but you can simplify to
{% set day = strptime(states('sensor.date'), '%Y-%m-%d').strftime('%a').lower() %}
{{ is_state('input_boolean.zone_1_' ~ day, 'on') }}
