Vera failed to shut off my outside lights this morning at sunrise. Event seems to be set correctly. Seperate event turning lights on last night at sunset worked fine. Vera does not seem to be locked up or anything, commands and scenes can still be triggered ok. For some reason the sunrise event just failed to fire.
I did notice my internet connection went down this morning for a short period, but vera never lost power so the time should have still been stored and valid. Could that still have had an effect on my timer? Anyone else had any scenes not firing off in 899?
I know you asked for reports of failures, but I’m kind of in a celebratory mood so bear with me. My sunrise-based scenes (both the on and off) worked this morning. And the sunset scenes worked last night. Wuhu!
Now I don’t dare update from 899, even though the temptation is there.
BOSSTON, Fortunately I had your serial number from a prior email and you had Vera set to archive the logs on our server, and verbose logging is locked on. So I have everything I need to see the problem. The issue is that, for some reason, at 1:04:57.300 this morning the ntp client (this is the Linux module that synchronizes the date/time with an online server) set your time to 12/31/1999. At 8:57:54.920, it got the right time again. So, your timers that should have run at 6am and 7am didn’t run because at that time the date was wrong. This is a bit harder for us to fix because it’s a bug somewhere in the ntpclient, which is part of the Linux operating system. I suspect that you either (a) lost internet or (b) that the ntpserver (which is an online server that reports the current date/time) reported an invalid date/time of 1999. Probably a. Either way the ntp client should not have changed the system clock back to 1999. We’ll do some tests here to try to reproduce it and post a bug report with the ntp developers. Our internal bug tracking for this is: http://bugs.micasaverde.com/view.php?id=629
@MCV, would it make sense for Vera to periodically save the current date/time in non-volatile memory, and then do a comparison of NTP-issued timestamps with the last save, so she can refuse any oddball situations like this?
After all, Vera should know she cannot go back in time (except in October, when Daylight Savings ends).
Yes, I did lose internet this morning for some reason. I got to work and realized my home network was down at about 8am… came back up on its own by 9am or so. I cant come up with any reason for the time changing last night, vera is on a UPS and I did not shut her down last night. Probably a bug in the ntp client as you say… this could very well be the reason there are some widespread reports of scenes not activating at the correct times.
Thanks for checking into my problem here on the forums, I kind of lost hope in the bug tracker/support ticket system since my last couple tickets/phone calls went unanswered. I know you guys have a lot going on right now and appreciate the quick response. I think now that all of the major back-end Luup development is over we will notice some major improvements from MCV and vera.
On another note, my TED 5000 should be here today. I look forward to helping you guys test the complete energy tracking solution you have envisioned for vera since the start.
@MCV, would it make sense for Vera to periodically save the current date/time in non-volatile memory, and then do a comparison of NTP-issued timestamps with the last save
The code to set the system date/time has nothing to do with Vera. It’s part of the Linux operating system distro. We just read the system clock, but don’t set it. We have to find the fix in the ntpclient.
Same thing happened to me BOSSTON. I’m not sure why or how but it seems that a couple of full power cycles helped my Vera. Allow 30 seconds or more. It just seem as if some processes never get to finish up in the cache and linger around to mess things up. Wait that sounds like Windows. Wait I think I may be on to something here…good luck.
I don’t have my vera up at the moment to be able to check, but is there a way to specify a different NTP server, possibly one that’s running on the local network that will sync up to the outside world? Even if it’s just a temporary solution until the bug is found.
How often is the time check being done that it randomly changed it at 1am.
The NTP server seems to be consulted in conjunction with Vera’s resumption of her Internet connection:
Current time and date are probably maintained from that point onward, without much need for Vera to consult an NTP server. If Vera does invoke NTP at other times, it would be nice to have this job noted in Vera’s Logs.
Note, guessed and others, that NTP.org maintains a fairly robust “Bugzilla” reporting system, in case one of you suspects a flaw in their time-setting service:
I dont want to suggest by any means that the servers listed there are unstable or anything, but wouldn’t it be better to use time.nist.gov?
If the file is modified, will it hold through a reset?
And lastly, do they hit them in order, 0, then 1, then 2, then 3, reason for asking of that would be, hit 0, if it doesn’t respond hit 1
And set it up so that it could hit maybe time.nist.gov then 0.openwrt.pool.ntp.org, then a WindowsHomeServer on the local network, or even better, do a localhost as a last resort to have Vera query herself for the time so as to not loose it if no responses are received. That would be a crude hack way to do it, but I think it would work, if that’s how the protocol works.
Best Home Automation shopping experience. Shop at Ezlo!
