I am trying to turn on my hotplate based on a time before candle lighting as set in the sensor “jewish_calendar_upcoming_candle_lighting”.
I have tested the trigger code using the “Developer Tools” and the logic transitions from false to true correctly, but when I paste the code into the automation trigger it doesn’t want to trigger.
Any suggestions please as to how to get it to trigger.
Thanks
Mike Paneth
alias: Hotplate ON night
description: Turn hotplate ON at night. Time is set to 3hr before candle
trigger:
- platform: template
value_template: >
"{% set ho = 3 %}
{(as_timestamp(states('sensor.jewish_calendar_upcoming_candle_lighting')))|int
- (ho*60*60) < as_timestamp(utcnow())|int}}"
condition: []
action:
- type: turn_on
device_id: 837b83506685d815c22c13df77f30eb9
entity_id: switch.hot1
domain: switch
- type: turn_on
device_id: 837b83506685d815c22c13df77f30eb9
entity_id: switch.hot1_led
domain: switch
mode: single
I copied the template into the Developer tools and substituted a timestamp of 60 seconds from now (in place of ho * 60 * 60) and the code executed correctly (false -> true).
However when I did the same experiment by plugging in a new timestamp into both the automation and Developer tools it again executed correctly in Developer tools but did not trigger the automation?
Logger: homeassistant
Source: components/template/trigger.py:55
First occurred: 12:32:00 PM (1 occurrences)
Last logged: 12:32:00 PM
Error doing job: Exception in callback async_track_point_in_utc_time.<locals>.run_action() at /usr/src/homeassistant/homeassistant/helpers/event.py:1137
Traceback (most recent call last):
File "/usr/local/lib/python3.8/asyncio/events.py", line 81, in _run
self._context.run(self._callback, *self._args)
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 1156, in run_action
hass.async_run_hass_job(job, utc_point_in_time)
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 1362, in pattern_time_change_listener
hass.async_run_hass_job(job, dt_util.as_local(now) if local else now)
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 811, in _refresh_from_time
self._refresh(None, track_templates=track_templates)
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 960, in _refresh
self.hass.async_run_hass_job(self._job, event, updates)
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/usr/src/homeassistant/homeassistant/components/template/trigger.py", line 55, in template_listener
entity_id = event.data.get("entity_id")
AttributeError: 'NoneType' object has no attribute 'data'
I just created the following automation in my set up:
- alias: Hotplate ON night
description: Turn hotplate ON at night. Time is set to 3hr before candle
trigger:
- platform: template
value_template: >
{% set update = states('sensor.one_second_update') %}
{% set ho = 3 %}
{{(as_timestamp(states('input_datetime.both_date_and_time')))|int - (ho*60) < as_timestamp(now())|int}}
condition: []
action:
- service: input_boolean.turn_on
entity_id: input_boolean.test
mode: single
And it worked with no errors.
Obviously, I don’t have your entities so I needed to use my own but the automation syntax is basically the same. I changed the multiplier because I didn’t want to wait hours for it to switch.
The only thing I added was a one second update. If you use now() it will only ever update no more frequently than one minute intervals. So using only that it could be up to 59 seconds off on when the automation triggers.
But I didn’t get the same error you did so there must be something missing from your system that the template is looking for (as hinted at by the “Nonetype” error).
While playing around I see that while now() gives a different result to utcnow() depending on your timezone. However as_timestamp(now()) returns the same value as as_timestamp(utcnow()).
interestingly this has been a known issue for a while. And I had commented on the bug report a few weeks ago but completely forgot about it (and honestly assumed it would have been fixed) until I got a notification this morning from the github issue that there has been activity there. Sucks getting old…
I saw the same thing and I assume it’s correct but I would have to investigate further to see exactly why.
Time functions have a bunch of little intracacies and it’s possible that the “as_timestamp” function has a directive that always assumes your local timezone in the conversion unless specified otherwise.