chuckl Posted September 4, 2009 Posted September 4, 2009 So this morning I'm awakened by the ISY like any other typical morning looking forward to the long weekend. While getting ready for work, I noticed it getting light out and then glanced at the clock. It was about an hour later than what it should have been. Had to stay an hour over to make up for coming in late. Grrr... After getting home, I checked my HomeSeer setup and PC and they had the correct time. I then viewed the time on the ISY via the Admin console and it was running exactly one hour behind. I remember reading Mark's previous post on time issues and recovered the same way. "Synchronize Now" to reset time. This worked fine. System time is correct, as are "next run" times in program summary. Also as in the previous post, I have my ntp server configured to pool.ntp.org, and syncs every 12 hours. Next, I downloaded the log and saw the following: - first entry line in the log is Friday 08/14/2009 6:05AM - everything ok until Thurs 09/03/2009 06:03AM - next entry is Sat 8/16/1941 02:25AM - 1941 entries continue listing until Sat 8/16/1941 02:01PM - next entry is Thurs 09/03/209 05:07PM (should have been 6:07) From above, it looks like my ISY visited 1941 for 12 hours between time syncs. Apparently, it started right before/after a time sync yesterday morning and ended yesterday afternoon just before/after a time sync. I'm guessing this by the first line entry in the log which lists 6:05AM which is the first log entry after a reboot and then time syncing every 12 hours. Unlike Mark in the previous post, I have no strange log entries or odd Program Summary time entries. I have saved my log with the 1941 entries and is available upon request. At first I thought Mark's post was about a fluke behavior but judging by my experience, both our ISY's visited 1941 on Saturday, August 16th! That's a really big coincidence given the vastness of the space/time continuum. I'm in California. Where are you located Mark? Chuck
markens Posted September 5, 2009 Posted September 5, 2009 Interesting. I think the evidence is pretty strong at this point that we both hit a bum ntp server which was giving out bogus time info Weds night/Thurs morning. Unfortunately, it's difficult to know which server it was since pool.ntp.org resolves to many different ip addresses (round-robin), so the actual server we each used is somewhat indeterminate. I'm in Oregon, which does lead some credence to the possibility that we did get the same server. Suggestion to the UDI folks: As a safety precaution when processing ntp data, dp not allow a time difference greater than some reasonable amount to be applied automatically. Or at the very least note and log the time update, with IP address of the ntp server the data came from. (It would actually be useful for all ntp server queries to be logged in the downloadable log, with server ip address.) --Mark
krenzk Posted September 5, 2009 Posted September 5, 2009 Just for the record . . . it happened to me last Saturday around 5:11 p.m. One thing different though, all my lights came on (Insteon & X10).
IndyMike Posted September 5, 2009 Posted September 5, 2009 Curious, Just returned home from a road trip to find the ISY time 1 hour off (re-synch worked properly). In going through the log, I found the same time warp to 1941. The other curious item is that the ISY was performing exactly the same task on it's trip to 1941 and back. The F5 status is a response to an X10 Poll of my outside flood lamps. It's a program that runs every 15 minutes during daylight hours. The "A Extended Code" is a transmission from my CM15a to my Leviton Dimmers. The program is triggered by a X10 motion sensor, and executes a direct dim command to the Leviton switch. While the F5 status response is a synchronous event controlled by the ISY, the "A extended code" is very definitely a asynchronous event completely outside the ISY's control. Coincidence that these events happen to line up with the time warp? My automatic re-synch is set for 24 hours.
Michel Kohanim Posted September 6, 2009 Posted September 6, 2009 Hello all, This is a serious issue which we will have to take quite seriously. In the mean time, would you guys change the interval to every 1 hour. For now, this is considered a bug and any information would sincerely be appreciated. With kind regards, Michel
Algorithm Posted September 7, 2009 Posted September 7, 2009 An additional data point: just checked my log, which goes back to 2009/08/05; there was no 1941 at all. My NTP server is not set to pool.ntp.org. krenzk and IndyMike, is your server set to pool.ntp.org?
MikeB Posted September 7, 2009 Posted September 7, 2009 Just a note - a couple of months back I was having some issues with pool.ntp.org on some Windows Servers. Nothing as dramatic as 1941, but a good 10-15 minutes off, which really isn't acceptable for me. I've switched to: 1.north-america.pool.ntp.org 2.north-america.pool.ntp.org 3.north-america.pool.ntp.org ..and haven't had any issues since. I also switched my ISY over (to 2.north-america.pool.ntp.org). I can't help but wonder if these are issues with a server or 2 on pool.ntp.org. I searched my ISY log and did not find any 1941 entries.
jca001 Posted September 18, 2009 Posted September 18, 2009 I had the problem today while trouble shooting another problem as to why programs were not running in a folder with a schedule condition on the folder. I was looking at the next scheduled time for the folder and the programs and was just looking at the time part. Then I noticed the year was wrong. It would seem the way the ISY-99i schedules certain things is to evaluate the schedule condition and then get the current time and add them and put that as the time it will run next. The when the time is met it runs. Well after doing that and then indicating it would run next at 2009/09/18 11:00 AM and then have the clock changed to 1941 it is going to be a very long time before the scheduled time is met. I will second the statement made by the first poster, the time should NOT be changed if it is plus or minus a certain value. This could be an option that can be set when you enable NTP. Then if the change would exceeds the threshold the notify feature could be used to alert someone. Along with this and/or if the notify feature is not being used, the red LED could be set to blink. Based on the last idea, there may be other things that should use the notify feature and blink the red LED and should be configurable. Then there would have to be an option to stop the blinking or automatically after 24 hours and no other new error conditions have happened.
Brian H Posted September 18, 2009 Posted September 18, 2009 Do you have any of the optional modules installed? I have Weatherbug and the Network Modules.
jca001 Posted September 18, 2009 Posted September 18, 2009 I do not have any other modules installed. Mine is a base ISY99i.
Brian H Posted September 19, 2009 Posted September 19, 2009 Jack; That information maybe a help on finding the problem. I was asked if I was using added modules in my 1941 thread. Some with the problem. Also where using added modules.
Michel Kohanim Posted September 20, 2009 Posted September 20, 2009 Hi all, Please note that ISY recalculates schedules every time the time difference is more than the grace period. So, if your ISY goes back to 1941 and then after the next NTP it comes back to 2009, then ISY will automatically re-evaluate all the schedules. At the moment, I believe the problem is in the GUI itself as reported by Chuck and not in ISY. We are working on it. With kind regards, Michel
Recommended Posts