Getting off topic but petro is there any reason you have a preference for the function lower() rather than the filter |lower?
oh itâs just natural from my coding days, you can use | lower
1 Like
It appears to handle that. The big difference is that a timestamp derived from sensor.date is at midnight. Depending on the calculation, that can be useful or produce an incorrect result.
So would now() be if you use sensor.date to trigger it once per day 
Except if you only want the template to update just once a day you wouldnât use now() in the template because, in 0.117, itâll make the template update every minute.
Yes?
Wasnât the point that relying on sensor.date instead does exactly the same thing as relying on sensor.date would do before?
That statement omits a lot of important context.
This entire thread is about adapting templates to behave the same way they did before entity_id was deprecated. The fact is there is still no one way to duplicate what entity_id: sensor.date did for all cases, pre-0.115. For people who have arrived late to this thread, Iâm afraid you will have to review previous posts to understand why.
Suffice to say that itâs still possible to create a âonce-a-dayâ template so long as the template restricts itself to being a date/time calculation and devoid of referring to now(), states, states.DOMAIN, and most entities. Otherwise, their state-changes override the templateâs intended goal of only updating once a day.
Pre 0.115, the template could contain whatever you want and you could restrict its evaluation to once-a-day simply by specifying entity_id: sensor.date. Thatâs the functionality that no longer exists and is unlikely to ever be re-introduced (alternative solutions have already been developed).
2 Likes
is this pretty much a nice and proper way to evaluate how much time it takes for each custom block of template code to be processed and evaluated by the âcode engineâ ? / drag on cpu?
what? they changed this again?! Im sorry but i dont have time to pinpoint where in this thread it was explained what to replace that with but wtf is going on over here with these changes that has yet to be explained as benefiting anyone at all? and if you come across the fix for that please link me. I thought this stuff was for a âsmart homeâ and not a reason i get fired from a full time job trying to understand the devolving changes. no wonder this stuff hasnt taken off to the public yet.
Why do you get fired from your full time job for trying to understand the changes in a beta software?
This thread has served as a wonderful demonstration of open source where a lot of ideas have been thrown around, causing a piecemeal evolution towards a definite improvement of the feature. Following the thread has indeed been a time-consuming challenge but I am happy to say that everyone has kept quite civil even as frustration has built up when some of the other participants did not agree with their point of view (I like to think that goes for me as well). So that is whatâs going on, development. The changes that have actually been released have been a lot fewer than what this thread would suggest. It is unfortunate that the changes have now spanned three releases but I see no way this could have been avoided because this kind of feedback is simply not generated from a pre-releases.
My first post was an explanation of the benefits: Heads up! Upcoming breaking change in the Template integration - #116 by amelchio. Most of the following discussion has been about performance impact and how to get time-related templates to update automatically.
Itâs not clear what your that is referring to but if itâs the now() change that is now in the 0.117 beta, you do not have to change anything. If you want, you can remove any sensor.date or sensor.time that were only put in to make the template sensor update periodically. You may have a problem if you have a template that you do not want to update automatically. In that case, please show it here and the open source wonder can probably find a solution.
5 Likes
If running 0.117 can I remove sensor.time from this or will that result in the template only updating when the input_datetimes are changed?
value_template: >-
{% set update = states('sensor.time') %}
{% set d = now().strftime("%Y-%m-%d ") %}
{% set t = now().timestamp() %}
{% set pm_start = strptime(d + states('input_datetime.sp_bedrm_pm_on_time'), '%Y-%m-%d %H:%M:%S').timestamp() %}
{% set pm_end = strptime(d + states('input_datetime.sp_bedrm_pm_off_time'), '%Y-%m-%d %H:%M:%S').timestamp() %}
{{ pm_start <= t <= pm_end }}
Itâs my understanding that the presence of the now() function in that template will (in 0.117) ensure the template is evaluated once a minute.
Ok I thought it was if no entity to monitor was found. Was half way through deleting them all for the beta when I had a âwait a minuteâ moment and ctrl-zâd like mad.
Taras is right, it will still update once a minute. However, it will no longer update as the minute changes. If you want to maintain that, keep states('sensor.time').
If you were theoretically changing the input_datetime every 30 seconds, no other updates will happen. If you stop changing it at 12:00:23, the next update will happen at 12:01:23.
1 Like
sensor.time triggers on the minute so when will now() trigger? Is it 5 seconds after the minute changes? I seem to recall a comment in the PR about it being delayed slightly.
Maybe now() triggers for the first time one minute after Home Assistant started?
The now() refresh is not on a static schedule, it runs if (and only if) nothing else has refreshed the template for 60 seconds. This is to avoid redundant updates which is popular in some circles.
OK, if I understood you correctly, the presence of now() ensures the template is updated at a minimum rate of every minute. For example, if the template contains another entity that changes every 20 seconds or so then now() will remain dormant. However, it no other entity changes its state for a full minute, now() will trigger an update. Is that correct?
Correct! 
2 Likes