I guess I misunderstood the meaning of your closing statement:
Yeah, that could be caused by some Dutch-English 
Thanks however for your detailled example. Thatâs even a cleaner way to solve it.
I just posted it so someone else can benifit from it. With the closing statement I meant that removing entity_id from the template sensor can cause some issues, but the link bdraco shared shows us that it was already taken into consideration 
please let me ask if I would need the sensor.time here at all (obviously had them, but now rethinking I would believe not, because the (as_timestamp(state_attr(âsun.sunâ,âsunsetâ)) would âtriggerâ this anyhow at which time the now() function would be evaluated? Or notâŠ)
daylight_remaining_min:
friendly_name: Daylight remaining minutes
# entity_id: sensor.time
value_template: >
{% set t = states('sensor.time') %}
{{((as_timestamp(state_attr('sun.sun','sunset')) - now().timestamp())/60)|int}}
unit_of_measurement: min
daylight_remaining_hm:
friendly_name: 'Daylight remaining hh:mm'
# entity_id: sensor.time
value_template: >
{% set t = states('sensor.time') %}
{{(as_timestamp(state_attr('sun.sun','sunset')) - now().timestamp())
|timestamp_custom('%H:%M', false)}}
or, bit more complex:
value_template: >
{% set t = states('sensor.time') %}
{% set nw = as_timestamp(now()) %}
{% set ss = as_timestamp(state_attr('sun.sun','sunrise')) %}
{{'- ' if nw < ss}}{{(nw - ss)|abs|timestamp_custom('%H:%M:%S',false)}}
I think youâre right; you probably could remove sensor.time without any significant drawbacks.
Unlike sensor.time, which updates every minute, sun.sun isnât updated at a regular frequency. I recall reading something a long time ago that it used to be regular but it was determined that it was unnecessary. It was changed to be variable (faster updates at sunset/sunrise, slower updates at other times of the day ⊠or something like that).
That variability shouldnât be a problem for your Template Sensorâs purpose (determining remaining daylight time).
right! this is very important yes! sun.sun isnt a very reliable update trigger because of that, except for these specific templatesâŠ
still if one would want it to be minute perfect, to would need some more frequent updatingâŠ
thanks for reminding me.
Yup, I think thereâs no reason for your template to update itself any faster than sun.sun generates new data for it to use. Moments after sun.sun posts (new) data, your template will update and thatâs about as âminute perfectâ as one can expect. 
another on the expand(), which doesnât seem to do what it is supposed to when I change it accordingly :
from
{% set lights_on = states.light
|selectattr('entity_id','in',state_attr('group.all_inside_lights','entity_id'))
|selectattr('state','eq','on')|map(attribute='name')|list %}
{% if lights_on|length == 0 %}
No lights on. Sleep well..
{% elif lights_on|length == 1 %}
The {{lights_on[0]}} light is on.
{% elif lights_on|length == 2 %}
The {{lights_on[0]}} and {{lights_on[1]}} lights are on.
{% else %}
The {{lights_on[:-1]|join(', ')}}, and {{lights_on[-1]}} lights are on.
{% endif %}
to
{% set lights_on = states.light
|selectattr('entity_id','in',expand('group.all_inside_lights'))
|selectattr('state','eq','on')|map(attribute='name')|list %}
{% if lights_on|length == 0 %}
No lights on. Sleep well..
{% elif lights_on|length == 1 %}
The {{lights_on[0]}} light is on.
{% elif lights_on|length == 2 %}
The {{lights_on[0]}} and {{lights_on[1]}} lights are on.
{% else %}
The {{lights_on[:-1]|join(', ')}}, and {{lights_on[-1]}} lights are on.
{% endif %}
it does see and updates on all relevant entities, but it doesnt count the âonâ lights. cant this be done like this?
Nvm! sorry:
{% set lights_on = expand('group.all_inside_lights')
|selectattr('state','eq','on')|map(attribute='name')|list %}
{% if lights_on|length == 0 %}
No lights on. Sleep well..
{% elif lights_on|length == 1 %}
The {{lights_on[0]}} light is on.
{% elif lights_on|length == 2 %}
The {{lights_on[0]}} and {{lights_on[1]}} lights are on.
{% else %}
The {{lights_on[:-1]|join(', ')}}, and {{lights_on[-1]}} lights are on.
{% endif %}
does the job⊠duh
âweâ lost the TdF today, so still somewhat offâŠ
If /60 would fire at the top of every hour then I donât think it was actually working as expected because /60 would indicate an interval of 60 minutes. So it was triggered at 7:15 it should fire again at 8:15, not 8:00 which would be the case with /0.
Wouldnât a better replacement be hours: '/1' ? Or am I misunderstanding something here?
Any reason my system still wouldnât show this update as available? Currently sitting on 0.114.4. Running Hassio as a VM on a Windows box.
The minutes: /60 pattern would never trigger at 7:15, it would trigger at 7:00. There are multiple possible replacements:
minutes: 0hours: /1hours: "*"
All of them will trigger every hour on the hour so I donât know if any of them can be said to be better than the others.
It is not really an interval, /59 will match at 0 and 59 and then again one minute later at 0.
Am I the only one having issues with history stats? First I changed the unit_percentage to percentage and then get a ton of errors with domain not found from the new init py.
Hi there,
I am constantly getting âUnable to connect to Home Assistant.â after a few minutes of HA working across different browsers and Android App. Its only until I purge the data/cache or cookie then I am able to log back in. Can anyone explain why the latest update would be causing this issue? I am unable to see anything within the logs which is relevant to this issue.
Then I am definitely misunderstanding something. I understand how the 3 examples you gave are equivalent but your last statement has me confused about the difference between these two.
minutes: 59 <- triggers at 7:59, 8:59, 9:59
minutes: â/59â <- triggers ?
I also donât understand why /59 would trigger at 0 and 59.
I have several time pattern triggers in my config and they always appeared to function as I thought they should. Guess I wasnât playing close enough attention. Now time to bounce me head off a wall until I fully understand this.
Great work!!!
Unfortunately, Environment Canada is broken in 0.115.1
I updated from 0.114.4 to 0.115.1
Environment Canada was working find and it is not mentioned in breaking changes. HA wonât start after the upgrade until I commented out Environment Canada. Hereâs the error:
Platform error camera.environment_canada - Requirements for environment_canada not found: [âenv_canada==0.2.0â]
Jason
Imagine that you type
minutes: 5
Thatâs like a crown job that will run at (just) 5 minutes past the hour
However
minutes: /5
Will fire when the result at x minutes divided by 5 is exactly 0
So 0, 5, 10, 15 etc.
So the replacement for your â/60â is just â0â
1 Like
Yeah thanks Mutt. I was just playing with it and Iâve got my head wrapped my head around it now (please donât ever quote me here out of context!). The docs for this arenât very clear at all (to me anyway) and I had always assumed an automation triggered at 7:21 with an âintervalâ of /15 would trigger again 15 minutes later at 7:36, much like an alert repeat would. In guess in my case the difference obviously wasnât critical enough from me to have noticed!! 
Still donât get why /59 would fire at 1:59 AND 2:00 but whatevs Iâve moved on tonnes of work to get the config caught up!
Managed to fix the history stats (by just updating unit_percentage to percentage) but now broadlink alarm is not working. It was working before on 0.115 when history stats was broken. 
There are breaking changes to the broadlink integration
yep I know. Got it working fine during a test with 0.115, had to rollback due to issues with history stats but now just canât get s1c alarm to work again. The new integration was picked up the first time.
Managed to get the S1c alarm back by using:
sensor.broadlink_s1c_key_fob:
friendly_name: S1C Key Fob
icon: mdi:remote
show_last_changed: true
templates:
rgb_color: if (state === 'alarm_disarmed') return [10, 170, 10]; if (state ===
'Alarm_Armed_Home') return [51, 153, 255]; if (state === 'Alarm_Armed_Away')
return [255, 0, 0]; if (state === 'Alarm_SOS') return [255, 0, 125]; else return
[255, 0, 0];
1 Like