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
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: 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.
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.
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’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!
@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…
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.
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.
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
