I agree with Peter that iterating through an IP address range should not be done, also if there is no other discovery method available, like UPnP or mdns, then discovery really isn’t possible. 
I read a bit about the possibilies in java and the testing of a ip group seems to be a usuall way.
But I think a limitation to a /24 network is useful. In private use this is absolutly ok.
I go through the IP range of every private /24 up and not local IP4 network and try a socket connection with timeout to port 80. In second step a try whether its a KMXXX device.
OK, but this approach can still have unwanted side effects in a private /24 network. For example, some devices only allow a fixed number of connections on port 80, so your discovery process will at least for a time potentially exhaust the number of allowed connections to that device, leaving the user wondering why he cannot connect to his device when he expects to. It might also cause mysterious logging in a device that doesn’t recognize the HTTP request, or possibly other as yet unknown side effects.
Yes, you’re right. On other side it happens only once on the start of the service and should take longer as some seconds on the address. But I’m still looking for a different method.
1 Like
Looking at other bindings (e.g. the Max! Binding) it should be good enough to manually add the KM200 in the paper UI and having a configuration mask to enter the IP address and the required credentials to log into the device.
After the connection works fine the binding can discover the available values / services.
So there is no network load from scanning the IP range but still enough functionality to benefit from auto discovery.
Having one single device in a common setup this is a small trade off from my perspective.
It seems like I discovered a new problem. After the plugin runs for a while (based on my not so much experience of 2 days having it installed) it gets “kind of stuck” after a couple of hours and the only output (after the last successful update of all values) I see in the log is
2017-01-19 11:17:53.209 [DEBUG] [.b.km200.internal.KM200Binding] - KM200 execute
Unfortunately there is no kind of exception between the last successful update (around 11:16 today) and now.
Hmm, I didn’t see such abnormal behaviour here in my heating system. Did it work after openhab restart again?
Between this and the next one log is only the start of the runnable. No idea why it should stop there… strange.
yes, after a restart it works again and at some moment in time (still not deterministic to me) it doesn’t do anything than putting the “execute” lines in the log.
Maybe to many debug outputs? It runns here some days now, without problems.
Try without debug, please.
I added a try/catch to the start of the runnable. Maybe we can see something:
–link removed–
will give that a try - i turned on debug output for the km200 plugin only after i recognized that values from the km200 do not get updated anymore, hence I don’t think that turning off debug output will lead us to the root cause.
so - I think now we have a starting point to find the cause:
2017-01-20 12:31:37.682 [DEBUG] [nding.km200.internal.KM200Comm] - Check state of: /dhwCircuits/dhw1/operationMode type: null item: org.openhab.core.library.items.S
tringItem
2017-01-20 12:31:37.741 [ERROR] [.b.km200.internal.KM200Binding] - Could not get item state, Error: {}
java.lang.RuntimeException: Communication is not possible!
at org.openhab.binding.km200.internal.KM200Comm.getProvidersState(KM200Comm.java:579) ~[na:na]
at org.openhab.binding.km200.internal.KM200Binding$GetKM200Runnable.run(KM200Binding.java:322) ~[na:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_91]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_91]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
2017-01-20 12:31:37.741 [DEBUG] [nding.km200.internal.KM200Comm] - Check state of: /system/brand type: null item: org.openhab.core.library.items.StringItem
2017-01-20 12:31:37.741 [WARN ] [nding.km200.internal.KM200Comm] - Service is not in the determined device service list: /system/brand
2017-01-20 12:31:37.741 [DEBUG] [nding.km200.internal.KM200Comm] - Check state of: /dhwCircuits/dhw1/actualTemp type: null item: org.openhab.core.library.items.NumberItem
2017-01-20 12:31:37.741 [DEBUG] [nding.km200.internal.KM200Comm] - Check state of: /dhwCircuits/dhw1/actualTemp type: null item: org.openhab.core.library.items.NumberItem
2017-01-20 12:31:37.821 [ERROR] [.b.km200.internal.KM200Binding] - Could not get item state, Error: {}
java.lang.RuntimeException: Communication is not possible!
at org.openhab.binding.km200.internal.KM200Comm.getProvidersState(KM200Comm.java:579) ~[na:na]
at org.openhab.binding.km200.internal.KM200Binding$GetKM200Runnable.run(KM200Binding.java:322) ~[na:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_91]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_91]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
2017-01-20 12:32:33.282 [DEBUG] [.b.km200.internal.KM200Binding] - KM200 execute
2017-01-20 12:32:33.282 [DEBUG] [.b.km200.internal.KM200Binding] - Starting runnable
2017-01-20 12:32:33.283 [DEBUG] [.b.km200.internal.KM200Binding] - GetKM200Runnable
afterwards the plugin does not update values any more:
2017-01-20 12:33:33.283 [DEBUG] [.b.km200.internal.KM200Binding] - KM200 execute
2017-01-20 12:33:33.283 [DEBUG] [.b.km200.internal.KM200Binding] - Starting runnable
2017-01-20 12:34:33.284 [DEBUG] [.b.km200.internal.KM200Binding] - KM200 execute
2017-01-20 12:34:33.285 [DEBUG] [.b.km200.internal.KM200Binding] - Starting runnable
2017-01-20 12:35:33.286 [DEBUG] [.b.km200.internal.KM200Binding] - KM200 execute
2017-01-20 12:35:33.287 [DEBUG] [.b.km200.internal.KM200Binding] - Starting runnable
2017-01-20 12:36:33.288 [DEBUG] [.b.km200.internal.KM200Binding] - KM200 execute
2017-01-20 12:36:33.289 [DEBUG] [.b.km200.internal.KM200Binding] - Starting runnable
Thanks for these informations.
I changed the error and runnable handling. Test this please.
–link removed–
so, after being suspicious about the network switch in my storage room I connected the km200 directly to my core switch and thereby found a way to reproduce the behavior also with the latest version - just disconnect the km200 from the network 
2017-01-20 17:17:42.482 [DEBUG] [.b.km200.internal.KM200Binding] - KM200 execute
2017-01-20 17:17:42.483 [DEBUG] [.b.km200.internal.KM200Binding] - Starting runnable
2017-01-20 17:17:42.483 [INFO ] [.b.km200.internal.KM200Binding] - Old runnable is still running
2017-01-20 17:18:42.484 [DEBUG] [.b.km200.internal.KM200Binding] - KM200 execute
2017-01-20 17:18:42.484 [DEBUG] [.b.km200.internal.KM200Binding] - Starting runnable
2017-01-20 17:18:42.484 [INFO ] [.b.km200.internal.KM200Binding] - Old runnable has to be canceled
2017-01-20 17:19:42.485 [DEBUG] [.b.km200.internal.KM200Binding] - KM200 execute
2017-01-20 17:19:42.485 [DEBUG] [.b.km200.internal.KM200Binding] - Starting runnable
2017-01-20 17:20:42.486 [DEBUG] [.b.km200.internal.KM200Binding] - KM200 execute
2017-01-20 17:20:42.486 [DEBUG] [.b.km200.internal.KM200Binding] - Starting runnable
2017-01-20 17:20:42.486 [INFO ] [.b.km200.internal.KM200Binding] - Old runnable is still running
2017-01-20 17:21:42.487 [DEBUG] [.b.km200.internal.KM200Binding] - KM200 execute
2017-01-20 17:21:42.487 [DEBUG] [.b.km200.internal.KM200Binding] - Starting runnable
2017-01-20 17:21:42.488 [INFO ] [.b.km200.internal.KM200Binding] - Old runnable has to be canceled
2017-01-20 17:22:42.489 [DEBUG] [.b.km200.internal.KM200Binding] - KM200 execute
2017-01-20 17:22:42.489 [DEBUG] [.b.km200.internal.KM200Binding] - Starting runnable
Strange, I pulled the network cable from KM200 out and get this:
2017-01-20 19:24:11.224 [ERROR] [nding.km200.internal.KM200Comm] - Fatal transport error: No route to host
2017-01-20 19:24:11.229 [ERROR] [nding.km200.internal.KM200Comm] - Communication is not possible!
2017-01-20 19:24:14.225 [ERROR] [nding.km200.internal.KM200Comm] - Fatal transport error: No route to host
2017-01-20 19:24:14.229 [ERROR] [nding.km200.internal.KM200Comm] - Communication is not possible!
2017-01-20 19:24:17.224 [ERROR] [nding.km200.internal.KM200Comm] - Fatal transport error: No route to host
2017-01-20 19:24:17.228 [ERROR] [nding.km200.internal.KM200Comm] - Communication is not possible!
2017-01-20 19:24:20.224 [ERROR] [nding.km200.internal.KM200Comm] - Fatal transport error: No route to host
2017-01-20 19:24:20.233 [ERROR] [nding.km200.internal.KM200Comm] - Communication is not possible!
2017-01-20 19:24:23.225 [ERROR] [nding.km200.internal.KM200Comm] - Fatal transport error: No route to host
2017-01-20 19:24:23.226 [ERROR] [nding.km200.internal.KM200Comm] - Communication is not possible!
Without problems…
And after i put the cable in again all stuff works imidiatly again. Where is the difference?
Wait, I’m using here the OH release 1.83 as base… you? OH2 ?
i’m also running OH 1.83, with
OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-3ubuntu1~15.10.1-b14)
OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
java version "1.8.0_65"
Java™ SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot™ Client VM (build 25.65-b01, mixed mode)
Test is maybe again. It has to work. Download it again and restart openhab without debug.
Then you should see exact this what I posted (Its without debug). Maybe something in replacing was wrong.
I don’t know whether the diferent Java could be a reason.
…so - pulling the NW cable of the KM200 is not the right way to reproduce it - i turned off debug mode and the plugin still gets stuck after a while