Wait… I am not sure that this is linked to your KNX setup…this is a warning from org.eclipse.smarthome.core.internal.common.WrappedScheduledExecutorService so this may be something else.
by the way @ByteBandito : I would disable readInterval=3600 if I was you
You have alooot of GAs and if you poll every 3600 secs = 1 h all of them, you may saturate the KNX Bus at that moment
You don’t really need readInterval in most of the cases (set to 0)
Also, you use fetch=true : not really needed… This will also create a small “storm” when the binding starts up.
Also: ping is also too fast (300 secs = 5 mins). Not really needed to ping faster than 10 mins (even this is fast)
Please avoid readInterval. This is only to force a read request for each GA which is readable per openHAB configuration. In most cases, there is no need for frequent read requests, as the most knx devices provide either send by change or send frequently (of both methods), this option is only for devices which must be triggered by a read request.
fetch is a nice option, to get additional information about the device. I don’t know if this fetch will de done once (when knx2 binding starts up) or frequently. I see some errors when using this option, so I disabled this for the most devices.
pinginterval is not reliable (i.e. the device is shown as OFFLINE although each command is executed correctly).
I changed the 4/0/60 to 5.001 (and the other similar devices also).
heizungsaktor_1_240 is no typo. But I dont know why i did this… cant remember
I enabled trace to calimero and knx. And right now i am a bit flashed… tons of information ;-)… I will try to collect errors / warnings beeing showed.
I changed pinginterval to 900, which is 15 minutes and set readinterval to 0. We’ll see if it changes anything… The peaks of my knx-bus are at about 45% utilization.
I kept Fetch. If i disable it, the knx-actors are shown offline in my paperui, which may not be a huge problem, but it helps me finding problems to have a look there.
@Udo_Hartmann
Nop, no rules for heizung_stellwert_108 (and no rules for heizing at all…).
But what I do have is a persistence for influxdb:
@Both of you:
Big thanks for helping me with that!
If you are some time near frankfurt/germany i will be happy to share a good glas of wine or something else with you. Thanks!
That’s strange… I have fetch=false for all Things and I still have them Online in PaperUI.
I think that the pinginterval is the one that affects the Online status but I am not 100% sure.
Yes, maybe you did not get a correct value for the channel and openHAB tries to restore a NULL value.
As this is a mass of items, I recommend not to use restoreOnStartup. Please reduce persistence to those items which need to be persisted (this will also reduce size of data store in influxdb )
Best practice for restoreOnStartup is only to restore those items which can’t be restored through the binding itself.
As knx will request the status for each readable GA, there is absolutely no need for restoreOnStartup.
Also, you will get better performance if you go with MapDB for restoreOnStartup (since MapDB only stores the value of the last state)
Use InfluxDB for storing historical data that you can graph and in parallel, setup a simple MapDB persistence service for whatever you want to restore.
I use 2 groups for this:
gMapDB
gInfluxDB
If I want to restore + graph = I make the Item (or other Groups) member of both Groups.
Then, you use the Group names in your persistence configs:
for influxdb.persist
Items {
// persist all members of gInfluxDB Group
gInfluxDB* : strategy = everyChange, everyHour, everyDay
}
same story for mapdb.persist
Items {
// persist all members of gMapDB Group
gMapDB* : strategy = everyChange, restoreOnStartup
}
2018-11-13 12:09:46.386 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: java.lang.IllegalArgumentException: Value must be between 0 and 100
?
hopefully you have disabled TRACE logging on calimero and KNXv2 binding
By the way: the first warn is due to the fetch. you should disable the fetch and the warn should go away and the Thing should stay online
I think most problems disappeared… I have to watch some more
Yet it did not minimize the persistance-usage… but thats the only thing left. I hope.
The only problems of the last 6 hours:
2018-11-22 15:06:20.994 [WARN ] [net/IP Tunneling 1xx.1xx.1x.101:3671] - response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->1.2.50 L_Data.req, system priority hop count 6 repeat, tpdu 81
at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:244) ~[?:?]
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:258) ~[?:?]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:178) ~[?:?]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:243) ~[?:?]
at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:351) ~[?:?]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:222) ~[?:?]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.sendDisconnect(TransportLayerImpl.java:612) ~[?:?]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.disconnectIndicate(TransportLayerImpl.java:600) ~[?:?]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.disconnect(TransportLayerImpl.java:342) ~[?:?]
at tuwien.auto.calimero.mgmt.Destination.destroy(Destination.java:371) ~[?:?]
at tuwien.auto.calimero.mgmt.Destination.close(Destination.java:383) ~[?:?]
at tuwien.auto.calimero.mgmt.ManagementProceduresImpl.isAddressOccupied(ManagementProceduresImpl.java:311) ~[?:?]
at org.openhab.binding.knx.internal.client.AbstractKNXClient.isReachable(AbstractKNXClient.java:338) ~[?:?]
at org.openhab.binding.knx.handler.AbstractKNXThingHandler.pollDeviceStatus(AbstractKNXThingHandler.java:144) ~[?:?]
at org.openhab.binding.knx.handler.AbstractKNXThingHandler.lambda$1(AbstractKNXThingHandler.java:184) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2018-11-22 15:06:20.998 [WARN ] [calimero.mgmt.TL 1xx.1xx.1x.101:3671] - disconnected not gracefully (timeout)
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->1.2.50 L_Data.req, system priority hop count 6 repeat, tpdu 81
at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:244) ~[?:?]
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:258) ~[?:?]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:178) ~[?:?]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:243) ~[?:?]
at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:351) ~[?:?]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:222) ~[?:?]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.sendDisconnect(TransportLayerImpl.java:612) ~[?:?]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.disconnectIndicate(TransportLayerImpl.java:600) ~[?:?]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.disconnect(TransportLayerImpl.java:342) ~[?:?]
at tuwien.auto.calimero.mgmt.Destination.destroy(Destination.java:371) ~[?:?]
at tuwien.auto.calimero.mgmt.Destination.close(Destination.java:383) ~[?:?]
at tuwien.auto.calimero.mgmt.ManagementProceduresImpl.isAddressOccupied(ManagementProceduresImpl.java:311) ~[?:?]
at org.openhab.binding.knx.internal.client.AbstractKNXClient.isReachable(AbstractKNXClient.java:338) ~[?:?]
at org.openhab.binding.knx.handler.AbstractKNXThingHandler.pollDeviceStatus(AbstractKNXThingHandler.java:144) ~[?:?]
at org.openhab.binding.knx.handler.AbstractKNXThingHandler.lambda$1(AbstractKNXThingHandler.java:184) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2018-11-22 20:05:47.575 [WARN ] [net/IP Tunneling 1xx.1xx.1x.101:3671] - response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->1.2.14 L_Data.req, system priority hop count 6 repeat, tpdu 81
at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:244) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:258) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:178) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:243) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:351) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:222) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.sendDisconnect(TransportLayerImpl.java:612) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.handleConnected(TransportLayerImpl.java:528) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.access$400(TransportLayerImpl.java:87) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.mgmt.TransportLayerImpl$NLListener.indication(TransportLayerImpl.java:127) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.link.AbstractLink$LinkNotifier.lambda$frameReceived$1(AbstractLink.java:159) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.internal.EventListeners.fire(EventListeners.java:129) [236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.link.EventNotifier.fire(EventNotifier.java:164) [236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.link.EventNotifier.run(EventNotifier.java:101) [236:org.openhab.binding.knx:2.4.0.201811221124]
2018-11-22 20:05:47.576 [WARN ] [calimero.mgmt.TL 1xx.1xx.1x.101:3671] - disconnected not gracefully (timeout)
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->1.2.14 L_Data.req, system priority hop count 6 repeat, tpdu 81
at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:244) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:258) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:178) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:243) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:351) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:222) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.sendDisconnect(TransportLayerImpl.java:612) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.handleConnected(TransportLayerImpl.java:528) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.access$400(TransportLayerImpl.java:87) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.mgmt.TransportLayerImpl$NLListener.indication(TransportLayerImpl.java:127) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.link.AbstractLink$LinkNotifier.lambda$frameReceived$1(AbstractLink.java:159) ~[236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.internal.EventListeners.fire(EventListeners.java:129) [236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.link.EventNotifier.fire(EventNotifier.java:164) [236:org.openhab.binding.knx:2.4.0.201811221124]
at tuwien.auto.calimero.link.EventNotifier.run(EventNotifier.java:101) [236:org.openhab.binding.knx:2.4.0.201811221124]
These are timeouts that happen between your KNX binding and the KNX devices…
Can you check if the KNX Bus is overloaded at these moments in time?
Also: I would try to set the localSourceAddr="x.y.z" to something that the KNXnet/IP Tunneling interface provides for its clients.
Look into the configuration of your Tunneling interface to see which IAs it provides and use one of them in the binding config to see if things improve.
sorry to say, but it seems that there is something seriously wrong with your OH2 installation…
you need to go into debug mode and identify the issues (most likely caused by mis-configurations)
I have my system controlling 10+ bindings (KNX included) with uptime >1 month (due to frequent upgrades) and the cpu is:
I can’t say for sure… but definitely it doesn’t help to have a binding running that cannot connect to its destination and retries all the time… If you don’t/can’t use it: uninstall it.