My automations with set time triggers always trigger later than requested

Configuration
1

Hi team HA :slight_smile: Wondering if anyone has had a similar issue.
All my automations have varied and large delays on time triggers.

This wasn’t a problem for a few months, but started happening lately. Nothing has changed except for updates.

Simple example is my towel rail turn on automation;

image
image740Ă—441 13.4 KB

Triggered by the time at May 17, 2022, 9:01:44 AM
turn_on Shelly 1PM - Towel Rail
Shelly 1PM - Towel Rail (switch.shelly1pm_a4cf12f3d864) turned on
Finished at May 17, 2022, 9:01:44 AM (runtime: 0.03 seconds)

image

Automation is pretty basic;

trigger:
  - platform: time
    at: '08:00:00'

I have a lot of time based automations. They all have weird delays like this.
My 9PM air conditioner automation triggers at 9:12PM
12AM off turns off at 12:11
Grow light 1PM, triggers 2:46PM
Grow light off 1AM, triggers 1:17AM,

If I look at the history of each trigger they are always delayed by different amounts.

I have tried fixed values, and also used input.datetime helpers. Same issues.

1 Like
2

Just to add, my devices on schedules are all different integrations.
Grow Light: Philips HUE via ZHA
Towel Rail: Shelly 1PM
AC: AirTouch4

3

Do the automations actually trigger on time though?

i.e. is this just because the system time for the device you are running the web browser / app on is incorrect, which will cause the displayed time to be wrong?

Or are the triggers actually delayed?

In which case it is likely that your Home Assistant system time is incorrect because it can’t contact an NTP service to keep it in sync.

1 Like
4

The actual triggers are definitely delayed because my towels are not warm for after my shower :rofl:
First world problems.

Settings > General is the correct time zone.
Date at terminal produces the right date, time, timezone, year.

HA hosted on ESXi hosts with correct dates, but I did just find one host has NTP set up and my new host doesn’t (but has correct time). I will fix this issue now anyway - but it would be strange to cause this problem.
Edit: There was 2 mins difference between hosts before I repaired this. Seconds difference between HA and hosts.

5

What about in the template editor?

{{ now() }}
{{ now().astimezone() }}
{{ utcnow().astimezone() }}
{{ now().now() }}
{{ now().today() }}
{{ now().utcnow() }}
{{ utcnow() }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}
{{ utcnow().tzinfo }}
1 Like
6

When working with HA and time make sure to always provide timezone where possibly.
HA works in UTC and if you do not state a timezone, then times are sometimes taken as UTC too.
This could make sense for some of the delay on the tower rail.

Some of the delay you see is also the response time.
You script might run in 3 secs, but HA first see the change when the device has reported back that the state has changed.
Here local push is the best with low response times while cloud pull can be with really high response times.

7

2022-05-19 00:12:00.000950+12:00
2022-05-19 00:12:00.000961+12:00
2022-05-19 00:12:00.001001+12:00
2022-05-19 00:12:00.001029
2022-05-19 00:12:00.001050
2022-05-18 12:12:00.001066
2022-05-18 12:12:00.001072+00:00
Pacific/Auckland
NZST
UTC

Above was all correct out of template editor. Good check thank you.

Fixing that ntp issue solved nothing unfortunately.
My 9pm trigger last night went off at 1127pm. The off trigger for midnight triggers at 2am. Pretty werid!

8 
alias: SCHEDULE / Light / Turn ON
description: ''
trigger:
  - platform: time
    at: '13:00:00'
condition: []
action:
  - type: turn_on
    device_id: 123
    entity_id: 456
    domain: switch
mode: single

Execution history;
Executed: May 18, 2022, 3:26:44 PM
Executed: May 17, 2022, 2:33:42 PM
Executed: May 16, 2022, 2:46:30 PM
Executed: May 15, 2022, 3:05:56 PM
Executed: May 14, 2022, 1:04:53 PM

alias: SCHEDULE / Light / Turn OFF
description: ''
trigger:
  - platform: time
    at: '01:00:00'
condition: []
action:
  - type: turn_off
    device_id: 123
    entity_id: 456
    domain: switch
mode: single

Execution history
Executed: May 19, 2022, 3:22:00 AM
Executed: May 18, 2022, 3:32:08 AM
Executed: May 17, 2022, 1:17:35 AM
Executed: May 16, 2022, 1:35:30 AM

[SCHEDULE / Light / Turn OFF](http://.../trace/...#) has been triggered by time
1:35:30 AM - 3 days ago

Executed: May 15, 2022, 2:06:24 AM

Nothing seems to add up. Times are varied. This is a 12 hour schedule for growing chilies.

9

Thanks for the input WallyR.

The trigger is time (time state?) rather than a state of a device. Regardless of a device response the trigger would occur at the time given anyway.
UTC would make sense if the times were always the same but my execution history doesn’t align with that.

10

I made a new automation with a turn on light 8:11AM and turn off 8:12AM right now (it was 8:10AM).
It worked perfectly…

I might just duplicate all of these, disable the originals and see what happens…

11

The execution history really shows the variation. It would have been nice to have had that in the first post :slight_smile:

I am at a loss to why that is so random.

1 Like
12

That’s why I said this originally, but I guess the detail makes it plain to see. :slight_smile:

First automation duplicate not great: Set to 1PM, actual 1:11PM. Will update tomorrow and see how they all went.

13

Duplicates did not work. 9pm passed and two of the automations did not trigger.
Next I might try making them from scratch.

14

I know, but my imagination did not really stick up to reality here. delays can for some be a few seconds to a couple of minutes, but that is not the case here and the list really shows it.

1 Like
15

This is a far fecthed try, but I can not see an id entry in your automations.
Could you add such one?

It is just a guess that the HA for some obscure, strange and crazy reason see some of the automations as the same and the “mode: single” then cause problems.

16

Sorry, I just edited them out. No particular reason, just automatic like removing IPs, but pointless :wink:
Really appreciate your input WallyR. :100:

That is an interesting thought. A lot of my automations start at 9PM for a free power time (9-midnight).
But I also have delays on anything else like my light on / off example at the bottom. This automation is at a completely times. Is that what you mean by mode:single being an issue or have I misunderstood?

Full YAML: This one is slightly different because it also starts a timer. But all the others are very basic turn on at X time;

alias: TIMER / Towel Rail / Start Timer
description: ''
trigger:
  - platform: device
    type: turned_on
    device_id: 07173303400abf9b02db42713950a30d
    entity_id: switch.shelly1pm_a4cf12f3d864
    domain: switch
    for:
      hours: 0
      minutes: 0
      seconds: 0
condition: []
action:
  - service: timer.start
    data:
      duration: '0'
    target:
      entity_id: timer.towel_rail
mode: single

Results of my duplicates vs originals;

My original light on
1PM actual 3:36PM
Original light off
1AM actual 3:22AM

New light on
1PM actual 1:11PM
New light off
1AM actual 1:12AM

Then my towel rail original on
9PM actual 11:22PM
Towel rail original off
12AM actual 2:21AM

New towel rail on
9PM actual 10:05PM
New towel rail off
12AM actual 12:05AM
17

I was referring to the fact that HA needs an id on the automation itself.
You can set this in the automations.yaml file where the automations normally have id: as the first line.
If one of those numbers are the same, then weird things starts to happen when using mode: single and mode: queue. because HA thinks one automation is already running, but in fact it is another one with the same id.

18

Got ya. :slight_smile:

I exported all ids out of that file, and definitely no duplicates.
All were created via the GUI, so I guess that did it’s job correctly.

I have shut down a second host, and will run it on an isolated host for 24h. See if that makes any difference.

19

With my second host offline and HA on my original host my light triggered at 1:00PM on the second.
So I think maybe if the automations all work tonight I can at least rule out HA being the issue (or just not the cause)

Pretty weird given all the above verification, both hosts with identical config (nuc11, esx 7.03).

:unamused:

20

This is the first mention of a “second host”.

Could you please explain your Home Assistant server set up?