git pull origin
It’s one of my apps generating it, but it didn’t do it before python 3.6 or AD 2.0.4 (2.0.0 didn’t do it) I don’t know if it’s 3.6 related or 2.0.4 related. It’s the printer snmp app. we’ve been using it for around 6 months I think.
I restarted home assistant to bring in the cover component, and when it restarted, I started getting clock drift (see below). My problem app isn’t running either. It’s been going for about 5 minutes now.
2017-07-15 09:54:30.719850 INFO shed_lights: bit_mask - (231) state=65
2017-07-15 09:54:30.746062 INFO shed_lights: process_light_state - (99) state=65
2017-07-15 09:54:30.749967 INFO shed_lights: process_light_state - (103) state=65, ignoring state
2017-07-15 09:54:30.760409 INFO shed_lights: process_light_state - (103) state=65, ignoring state
2017-07-15 09:54:31.001793 WARNING Scheduler clock skew detected - delta = 16.001704931259155 - resetting
2017-07-15 09:54:32.002276 WARNING Scheduler clock skew detected - delta = 16.0021550655365 - resetting
2017-07-15 09:54:33.002372 WARNING Scheduler clock skew detected - delta = 16.00226402282715 - resetting
2017-07-15 09:54:34.002444 WARNING Scheduler clock skew detected - delta = 16.002322912216187 - resetting
2017-07-15 09:54:35.002488 WARNING Scheduler clock skew detected - delta = 16.002367973327637 - resetting
2017-07-15 09:54:36.002320 WARNING Scheduler clock skew detected - delta = 16.00224208831787 - resetting
2017-07-15 09:54:37.001871 WARNING Scheduler clock skew detected - delta = 16.001744985580444 - resetting
2017-07-15 09:54:38.001710 WARNING Scheduler clock skew detected - delta = 16.001621961593628 - resetting
2017-07-15 09:54:39.001913 WARNING Scheduler clock skew detected - delta = 16.001816987991333 - resetting
2017-07-15 09:54:40.002027 WARNING Scheduler clock skew detected - delta = 16.001900911331177 - resetting
2017-07-15 09:54:41.001700 WARNING Scheduler clock skew detected - delta = 16.001609086990356 - resetting
2017-07-15 09:54:42.002210 WARNING Scheduler clock skew detected - delta = 16.002084970474243 - resetting
2017-07-15 09:54:43.002126 WARNING Scheduler clock skew detected - delta = 16.002048015594482 - resetting
2017-07-15 09:54:44.002646 WARNING Scheduler clock skew detected - delta = 16.002515077590942 - resetting
2017-07-15 09:54:44.946908 INFO battery_control: Battery sensor.ring_front_door_battery is at 100%
2017-07-15 09:54:44.997882 INFO battery_control: level=4
2017-07-15 09:54:45.005570 WARNING Scheduler clock skew detected - delta = 16.0054988861084 - resetting
2017-07-15 09:54:46.001751 WARNING Scheduler clock skew detected - delta = 16.001636028289795 - resetting
2017-07-15 09:54:47.002782 WARNING Scheduler clock skew detected - delta = 16.00265598297119 - resetting
2017-07-15 09:54:48.002196 WARNING Scheduler clock skew detected - delta = 16.00206995010376 - resetting
2017-07-15 09:54:49.002267 WARNING Scheduler clock skew detected - delta = 16.00218391418457 - resetting
2017-07-15 09:54:50.002067 WARNING Scheduler clock skew detected - delta = 16.001949071884155 - resetting
2017-07-15 09:54:51.001910 WARNING Scheduler clock skew detected - delta = 16.001830101013184 - resetting
I’m restarting AD now, lets see if it goes away.
the clock skew went away after restarting AD. I can do that as a matter of practice, no problem. But I know it’s not the way you designed AD, so I though you would like to know.
Thanks for the heads up - it’s a coincidence because I am working on that area of code in the dev branch which is why I asked. Hopefully the next version will behave better. Also, I have not done any testing on Python 3.6 yet - I do have one python bug reported that I will be fixing but I don’t know if it is related.
I thought you were on 3.6 and that we were being pushed to python 3.6…
If something takes to much time, and causes a clock skew, that flag is getting cleared… Right?? LOL
Definitely not! As it happens I develop and test on 3.5 mainly because that is what my Ubuntu 16.04 server has installed. I also test occasionally on 3.4 with Pi - although there are so many people running pi that I am sure I would be told if something was amiss 
3.6 should work, but I rely on feedback from early adopters. Please don;t rush onto 3.6 on my account
The idea is that when a clock skew occurs, the warning is output, but AppDaemon should skip time to catch up. Also, even if time is skipped, anything that was due to be executed during the skipped period will just be immediately executed after the re-adjustment. In the current version, hass restarting will always cause a clock skew but that is not the case in the next version and there should be one fewer reasons for clock skew.
I think I found it. When the error is found, the code “returns” the real_time to put us back in synch with reality. But it’s returning from a generator so apparently in Python3.6 it needs to be a “yield” instead of a return. I did the following, and it seems to be working.
#return real_now
yield real_now
If that is indeed the solution, it probably needs to be done at the bottom of do_every_second where utc is returned.
Interesting - do_every_second() isn’t actually a generator so I’m not sure why the yield is helping. Also, this breaks in 3.5 so isn’t really a good solution.
There are some more changes to clock skew in 2.0.4 - give it a shot and see if it helps.
Ok, I’m on 2.0.5 now. It gave me a few clock skews after I loaded the printer thing that was giving me problems. But each one the delta was a little less, and it stopped after 6 of them. So that’s good.
If it’s not a generator why do you call it with a yields from like a generator?
It’s part of the way asyncio works in Python 3.4
Ok, I’m new to generators and asynchio. But I thought what the yields from did was just pull back one value from a long running query ( or one that is servicing a stack ), so that if nothing was available it could go on and do it’s thing. Or something like that.
Time for you to upgrade to Python 2.6. LOL
that would be a downgrade 
Oops, that’s right. 3.6
2 Likes