NTP Date sends dates in 1970-01-06

Hi guys,

I have the NTP Date binding installed and configured to send date and time to KNX bus

 14 Thing knx:device:knx_virtual "KNX-virtual" (knx:ip:zennio) {
 15   Type datetime-control : date [ ga="11.001:0/0/1" ]
 16   Type datetime-control : time [ ga="10.001:0/0/2" ]
 17 }

However from time to time I see in logs something like:

95 2023-03-28 17:16:52.905 [WARN ] [nx.internal.client.AbstractKNXClient] - Value '1970-01-06T17:16:11.000+0100' could not be sent to KNX bus using datapoint 'command DP 0/0/1 'knx:ip:zennio    ', DPT 11.001, low priority': 11.001 Date: invalid date: 1970-01-06. Giving up now.
 96 2023-03-28 17:16:52.906 [WARN ] [.internal.handler.DeviceThingHandler] - An error occurred on channel knx:device:knx_virtual:date: 11.001 Date: invalid date: 1970-01-06
 97 tuwien.auto.calimero.KNXFormatException: 11.001 Date: invalid date: 1970-01-06
 98   at tuwien.auto.calimero.dptxlator.DPTXlator.newException(DPTXlator.java:535) ~[?:?]
 99   at tuwien.auto.calimero.dptxlator.DPTXlatorDate.toDPT(DPTXlatorDate.java:318) ~[?:?]
100   at tuwien.auto.calimero.dptxlator.DPTXlator.setValue(DPTXlator.java:193) ~[?:?]
101   at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:398) ~[?:?]
102   at org.openhab.binding.knx.internal.client.AbstractKNXClient.sendToKNX(AbstractKNXClient.java:552) ~[?:?]
103   at org.openhab.binding.knx.internal.client.AbstractKNXClient.writeToKNX(AbstractKNXClient.java:512) ~[?:?]
104   at org.openhab.binding.knx.internal.handler.DeviceThingHandler.lambda$9(DeviceThingHandler.java:254) ~[?:?]
105   at org.openhab.binding.knx.internal.handler.DeviceThingHandler.withKNXType(DeviceThingHandler.java:147) ~[?:?]
106   at org.openhab.binding.knx.internal.handler.DeviceThingHandler.withKNXType(DeviceThingHandler.java:141) ~[?:?]
107   at org.openhab.binding.knx.internal.handler.DeviceThingHandler.handleCommand(DeviceThingHandler.java:249) ~[?:?]
108   at jdk.internal.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) ~[?:?]
109   at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
110   at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
111   at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:147) ~[?:?]
112   at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) ~[?:?]
113   at jdk.proxy141.$Proxy247.handleCommand(Unknown Source) ~[?:?]
114   at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:85) ~[?:?]
115   at org.openhab.core.thing.internal.profiles.SystemFollowProfile.onStateUpdateFromItem(SystemFollowProfile.java:60) ~[?:?]
116   at jdk.internal.reflect.GeneratedMethodAccessor75.invoke(Unknown Source) ~[?:?]
117   at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
118   at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
119   at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:147) ~[?:?]
120   at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) ~[?:?]
121   at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
122   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
123   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
124   at java.lang.Thread.run(Thread.java:833) ~[?:?]
125 Caused by: tuwien.auto.calimero.KNXIllegalArgumentException: year out of range [1990..2089]
126   at tuwien.auto.calimero.dptxlator.DPTXlatorDate.set(DPTXlatorDate.java:332) ~[?:?]
127   at tuwien.auto.calimero.dptxlator.DPTXlatorDate.toDPT(DPTXlatorDate.java:315) ~[?:?]
128   ... 25 more

NTP Date sets the date as Jan 1970, and this happens not on the startup, but randomly during the normal operation. Anyone had this issue?

The question is, or how to avoid NTP Date setting this date, or how to avoid sending it to KNX bus if its in 1970


How did you link the channels to ntp?

I have an item, which is defined like

 DateTime ntp_fecha  "[%1$tA, %1$td.%1$tm.%1$tY %1$tH:%1$tM]"  { channel="knx:device:knx_virtual:date, knx:device:knx_virtual:time, ntp:ntp:local:dateTime" }

Nice, I even captured this on screenshot, because right now is

How do you know that the data came from NTP?

I didn’t know that setting it up this way would ever send data from one channel to the others. I thought you’d need a follow profile for that, at the very least, if not a rule.

Try splitting this into three items, one for each channel, and see which one goes to 1970.

It was done a long time ago following this topic

I’m pretty sure @JimT is correct here: your Item will receive data from all three Channels, but won’t normally share/push that data to the other Channels by itself - as mentioned you would usually have to work with follow profiles, or rules.

I do this quite a bit with MQTT Channels, and certainly in those situations the data is not forwarded to the other Channel unless a follow profile is used.

Unless the KNX binding is doing some unusual magic…

I think the magic here is by using *-control type of channel. That is what allows you to not to use follow profile.
Date and time on my KNX device is indeed updated and it works: I can set random time on control KNX screen, and it will be corrected in a moment to a right one.

1 Like

Actually it works randomly as well:

2023-03-29 17:17:02.339 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ntp_fecha' received command 2023-03-29T00:00:00.000+0200
2023-03-29 17:17:02.340 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ntp_fecha' received command 1970-01-07T17:16:14.000+0100
2023-03-29 17:17:02.341 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ntp_fecha' predicted to become 2023-03-29T00:00:00.000+0200
2023-03-29 17:17:02.342 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ntp_fecha' predicted to become 1970-01-07T17:16:14.000+0100
2023-03-29 17:17:02.342 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ntp_fecha' changed from 2023-03-29T17:17:02.077+0200 to 2023-03-29T00:00:00.000+0200
2023-03-29 17:17:02.343 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ntp_fecha' changed from 2023-03-29T00:00:00.000+0200 to 1970-01-07T17:16:14.000+0100

2023-03-29 17:17:14.819 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ntp_fecha' changed from 1970-01-07T17:16:14.000+0100 to 2023-03-29T17:17:14.821+0200
2023-03-29 17:18:14.820 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ntp_fecha' changed from 2023-03-29T17:17:14.821+0200 to 2023-03-29T17:18:14.821+0200
2023-03-29 17:19:14.821 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ntp_fecha' changed from 2023-03-29T17:18:14.821+0200 to 2023-03-29T17:19:14.822+0200

2023-03-29 17:20:14.820 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ntp_fecha' changed from 2023-03-29T17:19:14.822+0200 to 2023-03-29T17:20:14.822+0200

You see, sometimes the dates are correct, sometimes the time is right but date is 1970, sometimes date is right but time is 00.00.00…

Will try to split into two items…

Well, seems ok, although channels should be set apart.

DateTime ntp_fecha  "[%1$tA, %1$td.%1$tm.%1$tY %1$tH:%1$tM]"  { channel="knx:device:knx_virtual:date", channel="knx:device:knx_virtual:time", channel="ntp:ntp:local:dateTime" }

And I would prefer to set ntp on top of the list:

DateTime ntp_fecha  "[%1$tA, %1$td.%1$tm.%1$tY %1$tH:%1$tM]"  { channel="ntp:ntp:local:dateTime", channel="knx:device:knx_virtual:date", channel="knx:device:knx_virtual:time" }

Is there any chance that some knx device sends on GA 0/0/2, as this would match to the issue (DPT10.001 is not time, but time and day of week (0 to 6…)?

Thanks Udo, I think it did the trick. I have split item in two and changed as you suggested

DateTime ntp_fecha  "[%1$td.%1$tm.%1$tY]"  { channel="ntp:ntp:local:dateTime", channel="knx:device:knx_virtual:date" }
DateTime ntp_hora  "[%1$tH:%1$tM]"  { channel="ntp:ntp:local:dateTime", channel="knx:device:knx_virtual:time" }

And for the last 15h I have not seen any errors in the log with regards to it.

Looks like it is fixed


This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.