NTP: enabling daylight savings or using local server time?

I’ve successfully defined a DateTime item using the ntp:ntp:local:dateTime channel in OpenHAB2, and have it displayed successfully on my test sitemap. I live in the UK and have it set to use a UK ntp pool server, and via the PaperUI I’ve set my Locale to Europe/London. However, Timezone keeps defaulting to GMT, when I try and reset it to be blank then on the next restart it appears as GMT again (not that this seems to have any effect anyway)

My issue is that, now we’re in British Summer Time, the OH time is one hour out. The QNAP server that OH2 is running on knows about BST, and has the correct time. So either I’d like to enable the OH NTP binding to know to change the time by an hour at the right time of year, or I’d like to ditch the NTP binding altogether and grab the time from the QNAP instead.

Anyone comes across this problem and solved it?

I think the problem with the resetting timezone is due to the current way discovery is working
see issue https://github.com/eclipse/smarthome/issues/951

Until this issue is fixed the simple workaround is to define an ntp item manually. (so anything else than ntp:ntp:local)
Than discovery will not overwrite the setting.

let me know if that solves your issue

Thanks so much for taking the time to reply. I’ve created an ntpLondon.things file in the conf/things directory, where it contains:

ntp:ntp:London [ ntpServer="0.uk.pool.ntp.org", refreshInterval=60, refreshNtp=30, locale="Europe/London", timeZone="BST" ]

And I’ve added a line to my date.items file so I can compare:

DateTime StuDate "Date [%1$ta, %1$td %1$tb %1$tY, %1$tT]" {channel="ntp:ntp:local:dateTime"}
DateTime StuDateNew "Date [%1$ta, %1$td %1$tb %1$tY, %1$tT]" {channel="ntp:ntp:London:dateTime"}

And I successfully get a regularly-updating date & time. Problem is it’s still the exact same non-daylight-savings adjusted one from the line above. I’ve tried:

  • omitting the timeZone term
  • omitting the locale
  • setting the locale to “Europe/Paris”
  • setting the ntpServer to “localhost” or my server’s static IP address on my LAN
    …but with every combo it successfully updates, but again to a time that’s one hour earlier than it actually is here in London.

For what it’s worth, all my OpenHAB debug logs are stamped with this same incorrect time too… is that why querying localhost also gives the wrong time? Typing ‘date’ at the command line on my server (i.e. not while in OpenHAB) gives the correct time, however.

Where am I going wrong?

Indeed that’s kind of odd. Config looks correct.

Can you run the binding in debug mode, and attach the log. Specifically I want to ensure that it actually gets the time from the ntp server and not from the local machine (which the binding dies as fall back mechanism)

If this indeed is an issue of the binding, please make an issue in the github tracker and I’ll add some sort of summertime checkbox that does the offset

So indeed you’re right it’s not accessing the ntp server, here’s the log:

2016-04-12 20:05:09.188 [INFO ] [smarthome.event.ThingAddedEvent     ] - Thing 'ntp:ntp:London' has been added.
2016-04-12 20:05:09.200 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'ntp:ntp:London' changed from UNINITIALIZED to INITIALIZING
2016-04-12 20:05:10.037 [INFO ] [home.event.ItemChannelLinkAddedEvent] - Link 'StuDate-ntp:ntp:local:dateTime' has been added.
2016-04-12 20:05:10.039 [INFO ] [home.event.ItemChannelLinkAddedEvent] - Link 'StuDateNew-ntp:ntp:London:dateTime' has been added.
2016-04-12 20:05:10.332 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'ntp:ntp:local' changed from INITIALIZING to ONLINE
2016-04-12 20:05:16.095 [WARN ] [thome.binding.ntp.handler.NtpHandler] - couldn't establish network connection [host 'null'] -> returning current sytem time instead
2016-04-12 20:05:16.100 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'ntp:ntp:London' changed from INITIALIZING to ONLINE (COMMUNICATION_ERROR): couldn't establish network connection [host 'null'] -> returning current sytem time instead
2016-04-12 20:05:16.105 [INFO ] [smarthome.event.ThingUpdatedEvent   ] - Thing 'ntp:ntp:London' has been updated.
2016-04-12 20:05:16.119 [DEBUG] [org.eclipse.jetty.io.WriteFlusher   ] - write: WriteFlusher@1aed6b5{IDLE} [HeapByteBuffer@1dbf4d8[p=0,l=7,c=1024,r=7]={<<<\r\n107\r\n>>>\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00},HeapByteBuffer@1f0436c[p=0,l=263,c=32768,r=263]={<<<event: message\nda...hangedEvent"}\n\n>>>D\\":\\"ntp:ntp:Lon...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00}]

I tried pinging 0.uk.pool.ntp.org, but got no response, so tried the address without the leading 0. and got a ping, so changed the thing definition to that instead. Still get the same error above though. However I remembered that I also had the 0. ntp server set on my QNAP itself, so amended to the one without, and now both the Date definitions above are showing the correct time.

…and now after a reboot they’re not :cry:

What is strange to me is that you get the error
couldn't establish network connection [host 'null'] -> returning current sytem time instead
which means that indeed it is using the local machine time. Esp the ‘host null’ I would not expect.
I have not really tried configuring with text files, instead used paperUI to configure.

btw to see the log easy you can use in karaf:
log:set debug org.eclipse.smarthome.binding.ntp
log.display org.eclipse.smarthome.binding.ntp

I think the issue is in the thing definition… it should be hostname instead of ntpServer (the example in the readme is wrong and should be ntp:ntp:demo [ hostname=“nl.pool.ntp.org”, refreshInterval=60, refreshNtp=30 ]
)

ntp:ntp:London [ hostname=“0.uk.pool.ntp.org”, refreshInterval=60, refreshNtp=30, locale=“Europe/London”, timeZone=“BST” ]

If I type date on at the CLI of my system, it displays (right now) Tue Apr 12 23:18:07 BST 2016, so the system is definitely right (albeit it has that BritishSummerTime modifier). date -u gives the time one hour earlier, and has UTC written instead of BST.

Not sure what prompted the OH time to be correct for those few minutes before I rebooted!