Simple time trigger automation not working with Hue

Hi, I’m having a bit of a frustrating problem when trying to set up a very simple automation that turns off my Philips Hue light at a certain time. I set up the automation via the settings menu, tested it, but it never triggers at the given time. I tried with different lights, rooms, times, etc. but it still never works. I checked all of the time zone issues that others seemed to have but everything also checks out there.
I also tried to set it with a time helper instead of a given time but that still didn’t work.

Here is the .yaml code for the automation. I also tried to format the time differently (8:30, 20:30, 20:30:00)

alias: Light Off
description: ''
trigger:
  - platform: time
    at: '20:30'
condition: []
action:
  - type: turn_off
    device_id: 81e69595f2a53116a473fb6e59ebfccc
    entity_id: light.ceiling_1
    domain: light
mode: single

is there something that I’m missing?

Have you checked the trace feature of this automation?

1 Like

yeah, all of my tests had “no trace results” unless I manually triggered them. But last night one of them was finally triggered. Although it was at a very random time (12:57:24 AM) I had it set to 00:35:00. So it was 22min 24sec late.

alias: Bedroom Light Off
description: ''
trigger:
  - platform: time
    at: '00:35:00'
condition: []
action:
  - type: turn_off
    device_id: b55b7d823d10d04d8dff97a994ae25e2
    entity_id: light.hue_smart_plug_1
    domain: light
  - type: turn_off
    device_id: 6700724297a7b1b0c052451e570dd7a8
    entity_id: light.dresser
    domain: light
  - type: turn_off
    device_id: 77563a2f5814d8ff3cd0520a9d937d0f
    entity_id: light.nightstand
    domain: light
mode: single


Can you try using this?

alias: New Automation
description: ''
mode: single
trigger:
  - platform: time
    at: '20:00:00'
condition: []
action:
  - service: light.turn_off
    target:
      entity_id: light.ceiling_1

Also, can you go to Developer Tools → Services → In the service, type light.turn_off → In the target, choose light.ceiling_1 → Call service. Does the light.ceiling_1 turned off?

This is to verify if your device can communicate successfully with your HA.

I think I found the issue. It seems that the system clock of my VM is running slow. If I go to the CLI and check ha host info I see that the dt_utc is off by a random amount every time I check. use_ntc is set to true and use_rtc is set to false. I am running HA core on VirtualBox for reference.
I think this explains the random time that my automation was delayed. However, I have no idea how to fix the system clock…

@ardysusilo, I tried your automation but still no luck. Also the call service in developer tools did work and turned my light off so the communication seems to be okay.

Can you go to Configuration —> General to set your location and timezone?

Use TZ Database for reference.

If is still not possible, configure using Setup Basic Information via configuration.yaml.

After Home Assistant restart, verify the timezone by going to Developer Tools —> Templates —> Type {{ now() }} Does it match your local time?

Location and timezone is set correctly in the configuration settings and if I set a time_date integration it also shows everything correctly. The issue only shows up when I check the host info via the CLI. The strange part is that the delay is different evey time I check it sometimes its 18 min, sometimes is 42 min, etc.

The developer tools template time also is correct:
Screen Shot 2021-08-07 at 2.52.00 PM

here is the issue in the CLI:

Yes, but I think time trigger in automation uses local time.

Have you tried changing the time to, for example, 15:00:00? See if it works.

As far as I know, HA backend uses UTC. But it should not cause any issues as automation uses local time.

Please note that if you “run action” in the automation, it skips triggers and conditions - and only perform the “action” part of your automation.

Could it be that the automation is calculating the local time based off the incorrect host UTC time? Because when the automation was triggered by a set time last night, it was not a typical time zone offset of +/- 2 hours. It was 22min:24sec late which seems like the type of random delay seen in the host UTC.

I just tried the automation again with several different time and formats but still didn’t work…

I found similar issues that people had with their system time and it seems like the solution is to resync the NTP but I have no idea how to do this within HA on VirtualBox.

I see. Syncing NTP using CLI is also beyond my knowledge.

Just wait a bit more until someone with that technical know-how comes and help you.

Goodluck :slight_smile:

@ardysusilo thanks for your help so far, really appreciate it!

I’m having the exact same issue with HA 2021.7.4. This is a critical issue, I just noticed yesterday that all of my time trigger automations are running random times!

This is issue should be related with this one Timebased automations completely out of sync

Anyone knows if that have been fixed on the latest HA?

@SuRGeoNix, I actually found the problem for me (running HA OS on a 2010 Mac mini via a VirtualBox VM) was the “Paravirtualization Interface” option in the VirtualBox system settings. I had to switch it to “none” and that solved my time issue completely.

I’m guessing the older processor in my 2010 Mac was not working properly with the other paravirtualization options, although to be honest I’m not really sure what it does…

3 Likes

I’m using a raspberry pi 4 with Hass OS. However, that happened after a power corruption. it seems like the clock de-sync after that. I will have to look when it happens again for more details.

Have you checked your NTP settings to make sure it is synced?
see here: Wrong Time - How do you sync the time?

No but I will do. Shouldn’t HA OS come up with the ntp configuration already? Also, it shouldn’t retry on failure? I have a similar issue with KNX. If HA come up and the network is down, KNX will never come up. So I’ve created an automation to restarted every time. From the other hand I see a bunch of retries for adb that I dont really care. Z-wave has issues as well, dead nodes when retrying for interview after few days or something.

Why don’t you create a GitHub issue instead? Such bugs can be fixed once pointed out and reproduceable.

Well said, I just did If KNX fails because of network during HA start/boot, it will never be restored · Issue #55013 · home-assistant/core · GitHub

Thanks for your suggestion! I have turned this off and it seems to be working so far for me. I’ve been searching for a solution for a month. Finally I came across this solution!

Thank you so much for this. I am running HA in VirtualBox on Ubuntu and was getting weird run times for time based triggered automations. I changed the Paravirtualization setting to “none” (was default/kvm previously). My initial testing shows that automations are running at expected times now. I’ll keep an eye on it for a few days.

Documenting this mostly for myself, but just in case someone else wants to change this via command line:

vboxmanage showvminfo <vm name> | grep Paravirt  # shows current settings (mine were default/kvm)
vboxmanage controlvm <vm name> poweroff  # need to shutdown the VM to modify
vboxmanage modifyvm <vm name> --paravirtprovider none  # set the paravirtprovider
vboxmanage startvm <vm name> -type headless  # or start the vm however you normally do it
vboxmanage showvminfo <vm name> | grep Paravirt  # double check the settings