Clock stopped - February 8th 2018

[paulockenden]

I think it syncs to an NTP server running inside an antique grandfather clock at Honeywell Towers, which gets wound once a fortnight by the cleaning lady, but which stops if she has a few days off.

Unless anyone can think of a better explanation...

[DBMandrake]

Has anyone got around to wiresharking the traffic from the Evotouch yet ? Is there any naked ntp traffic visible or is all communication (including time setting) done through a TLS connection to the Honeywell servers ?

I keep meaning to set up a spare Raspberry Pi 2 as a hostapd style access point to connect the Evotouch to, and then do a tcpdump to a file for later analysis...

[G4RHL]

I think it syncs to an NTP server running inside an antique grandfather clock at Honeywell Towers, which gets wound once a fortnight by the cleaning lady, but which stops if she has a few days off.

Unless anyone can think of a better explanation...

Narr. The time lag has to be the server is on another planet. Indeed it may now be in a Tesla car on the front end of a rocket heading to Mars. Honeywell are not alone with these quirks. LightwaveRF are convinced dusk is the same as sunset and dawn is sunrise. In a way it’s funny. We have all these gadgets and complicated systems around us. We have had atomic clocks for ages and yet one simple clock cannot keep the right time. It gives us something to moan about though.

[IM35461]

Every other clock in my living room and of course every computer and smartphone knows the exact time.

One clock does not, evohome and I suspect the time server information must be no longer valid. If it was valid but wrong, all our controllers would be wrong by the same offset.

Still if I dig into the menus it now for some owners displays the possible outside temperature updated heaven knows how often

[CT1]

Einstein did show that time is relative.

[Wobbin]

I seem to recall a problem with NTP a few years back where Windows XP based clients would ignore the NTP server because they were too far away from its 'correct' time. I guess they thought that the time they were being given was implausible?

Wish we could just point it to our own choice, my pfSense box would handle this nicely. Oh well...

[DBMandrake]

I seem to recall a problem with NTP a few years back where Windows XP based clients would ignore the NTP server because they were too far away from its 'correct' time. I guess they thought that the time they were being given was implausible?

Actually it's part of typical ntp implementations that clients won't (without being forced/overridden) accept a time update that is more than 1000 seconds out from the time it currently believes the time to be. This is to prevent a rogue NTP server doing something stupid like setting your date/time days/weeks/months/years into the past/future.

If your time is genuinely wrong by more than that amount, you can have a problem. This is the case on a device like a Raspberry Pi where there is no real time clock so every time you turn it on it defaults to January 1st 1970. Because of this ntp on devices without real time clocks is configured to ignore large errors on the initial ntp sync during boot to allow the time to jump by 48 years to the correct time.... But once it is up and running it will not accept any implausible time jumps.