Elk Time or Daylight savings mess up

[apostolakisl]

More on time servers - the Elk sometimes has issues with DNS which is why I used an IP address; also I would think it's better to have your time sync after 2:00AM when the time shifts that way it corrects sometime in the night.

That isn't how time servers work. The time server does not tell you what time it is where you are and it does not tell you the new time after switching on/off of DST. When you query a time server you get the same number regardless of where your machine is or whether it is on DST or not. It is up to the local machine to run a formula to turn that time server number into the local time.

The Elk is supposed to change the clock at 2am based on its internal clock. The time server is just there to "tweak" the clock when it drifts a few seconds off. Of course the time server info will also full out set the clock on a new install or full power cycle, but again, it is the local machine that decides what hour it is.

For example, I am using the exact same time server on my routers, my isy, and my server. None of them screwed up.

 

[Smarty]

After upgrading firmware from 5.2.6 to the (latest) 5.2.8, my time now seems OK.

 

[apostolakisl]

After upgrading firmware from 5.2.6 to the (latest) 5.2.8, my time now seems OK.

Not to bum you out, but there are a few others that had 5.2.8 from the start and still had the problem. My suspicion is that the correction you saw had more to do with the system reboot than the firmware. I guess you'll find out next year (or maybe in the spring).

 

[tmbrown97]

That isn't how time servers work. The time server does not tell you what time it is where you are and it does not tell you the new time after switching on/off of DST. When you query a time server you get the same number regardless of where your machine is or whether it is on DST or not. It is up to the local machine to run a formula to turn that time server number into the local time.

The Elk is supposed to change the clock at 2am based on its internal clock. The time server is just there to "tweak" the clock when it drifts a few seconds off. Of course the time server info will also full out set the clock on a new install or full power cycle, but again, it is the local machine that decides what hour it is.

For example, I am using the exact same time server on my routers, my isy, and my server. None of them screwed up.

I'm really not sure of your point... but I don't care much... my system figured itself out so apparently I got this right a few years ago when it irritated me.

 

[apostolakisl]

I'm really not sure of your point... but I don't care much... my system figured itself out so apparently I got this right a few years ago when it irritated me.

The point is that the local device doesn't set dst or undue dst by asking the nts what time it is. So checking it at 2am is irrelevant. Imagine if this were the case, everyone would set their device to check at 2am. So US time servers would be whacked every day with all that traffic at one of only 4 hour spots on the hour, and the rest of the time they would do nothing.

I don't know why you didn't have the trouble, but I wouldn't report that checking the nts at 2am is how to fix it.

 

[tmbrown97]

OK - I'll concede - if I think about it, you're right... What the time server should be reporting is a generic UTC time and the elk should be translating that into the current time based on everything it knows, such as DST flag and time zone offset. My brain wasn't working right last night.

And irony sure is a b*tch... the time on mine was correct up until, and even the day of the switch (I was checking it often until then) - it handled everything correctly... then a day or two later, it advanced an hour... then after 2 more days or so, it fixed itself. Dunno what's up with that, but figures it happened after I said mine was golden. I don't have too many rules I'd notice after I stopped really watching the time, but I was walking up the stairs at 10:30 when I watched my porch lights go off... they're set for 11:30.

 

[video321]

... the time on mine was correct up until, and even the day of the switch (I was checking it often until then) - it handled everything correctly... then a day or two later, it advanced an hour... then after 2 more days or so, it fixed itself.

Same here. Mine was only wrong on Monday (which makes no sense to me) and then it fixed itself by Tuesday morning and it has been fine since.

 

[apostolakisl]

Clearly something is very screwy with Elk's algorithm. It would seem that it is getting sent down different paths at different times and comming up with different answers.

And, work2play, after I thought about it, what time you have it check the nts may play a role, because it may be sending the elk down either a correct or incorrect path of time calculation. The nts isn't responsible, but it may be that when it does an nts check, it runs a time calc that may be written incorrectly (or correctly), while other triggers for running a time calc are written correctly (or incorrectly). In my opinion, this is probably what is going on. The firmware probably has a number of "if" situations that send it into a current time calculation, and some of those "if's" have a "then" section that is wrong while others are correct.

And unlike years past, this year I have a very obvious situation with timing of rules. My chickens head into the chicken coup at sunset and I have the door close at sunset. The door was closing an hour early, locking the poor chickens out!

 

[gatchel]

My chickens head into the chicken coup at sunset and I have the door close at sunset. The door was closing an hour early, locking the poor chickens out!

Home Automation doesn't get much better than that :rockon:

 

[tmbrown97]

The poor chickens! :rofl: Too funny... poor guys gettin' locked out in the cold!

I do remember something from years past about timing having something to do with the correctness and that's when I decided to put the time check after 2:00AM because at one point it did fix itself after a time check.

Would sure be nice if Spanky would show his face in here and chime in!

 

[WayneW]

Would sure be nice if Spanky would show his face in here and chime in!

We are too busy beta testing new firmware Rest assured, they know there is a problem and are working on it.

He did say this in a beta email, so it looks like trying to be more space efficient bit them in the butt.

M1 software version before 5.2.8 had a different algorithm for the Daylite Savings Time Change, but required over 1000 bytes of additional code space. If you have a M1 software version before 5.2.8, the Daylite Savings Time Change worked properly.

 

[apostolakisl]

He did say this in a beta email, so it looks like trying to be more space efficient bit them in the butt.
Quote

M1 software version before 5.2.8 had a different algorithm for the Daylite Savings Time Change, but required over 1000 bytes of additional code space. If you have a M1 software version before 5.2.8, the Daylite Savings Time Change worked properly

So are they saying that by updating to the latest firmware we actually introduced the problem? I had read that people have been having trouble with this for quite a few years now.

 

[video321]

Quoted from above:
"M1 software version before 5.2.8 had a different algorithm for the Daylite Savings Time Change, but required over 1000 bytes of additional code space. If you have a M1 software version before 5.2.8, the Daylite Savings Time Change worked properly."


......Almost worked properly.
As I've stated, I'm on 5.2.6 and DST went smooth on Sunday, but Monday was an hour ahead and Tues it was correct again and has been since.

 

[Spanky]

It is fixed in the next M1 software update.

 

[video321]

Thanks, Spanky!