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
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.
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.
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…)?