There was a error, download it again.
–link removed–
Still getting this values
2017-01-18 11:50:01.818 [INFO ] [b.binding.km200.internal.KM200Device] - ##################################################################
2017-01-18 11:50:01.823 [INFO ] [.binding.km200.internal.KM200Binding] - ... Update of the KM200 Binding configuration completed
2017-01-18 11:50:01.828 [INFO ] [b.core.service.AbstractActiveService] - KM200 Binding has been started
==> /var/log/openhab2/events.log <==
2017-01-18 11:50:02.366 [ItemStateChangedEvent ] - HeatingSupplyTemp changed from 11.19999980926513671875 to 11.3999996185302734375
2017-01-18 11:51:02.369 [ItemStateChangedEvent ] - HeatingSupplyTemp changed from 11.3999996185302734375 to 11.19999980926513671875
2017-01-18 11:52:02.387 [ItemStateChangedEvent ] - HeatingSupplyTemp changed from 11.19999980926513671875 to 11.3999996185302734375
with the newest version too? hmm strange…
looks like.
deleted from addons
copied over the new one
waited till completed
! I NEED HELP FROM USERS!
I made a function for automatic device detection.(OH2 preparations). In this testversion this function will be called.
You can see something like:
Device is a KMXXX geteway: 192.168.90.60
It would be great if everyone could test it whether the right IP address is discovered.
–link removed–
I did today a clean fresh installation of a oh2 on a pi3.
I copied over from another pi3 the binding and the config.
I am getting following errors:
2017-01-18 16:17:05.037 [INFO ] [.binding.km200.internal.KM200Binding] - Update KM200 Binding configuration, it takes a minute....
2017-01-18 16:17:05.042 [INFO ] [.binding.km200.internal.KM200Binding] - Starting communication test..
2017-01-18 16:17:05.095 [INFO ] [.binding.km200.internal.KM200Binding] - Deactivated
2017-01-18 16:17:05.240 [INFO ] [.binding.km200.internal.KM200Binding] - Received data..
2017-01-18 16:17:05.241 [INFO ] [.binding.km200.internal.KM200Binding] - Activated
2017-01-18 16:17:05.254 [ERROR] [hab.binding.km200.internal.KM200Comm] - Exception on encoding: {}
java.security.InvalidKeyException: Illegal key size or default parameters
at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1026)[:1.8.0_60]
at javax.crypto.Cipher.implInit(Cipher.java:801)[:1.8.0_60]
at javax.crypto.Cipher.chooseProvider(Cipher.java:864)[:1.8.0_60]
at javax.crypto.Cipher.init(Cipher.java:1249)[:1.8.0_60]
at javax.crypto.Cipher.init(Cipher.java:1186)[:1.8.0_60]
at org.openhab.binding.km200.internal.KM200Comm.decodeMessage(KM200Comm.java:260)[229:org.openhab.binding.km200:1.9.0.201701180918]
at org.openhab.binding.km200.internal.KM200Binding.updated(KM200Binding.java:161)[229:org.openhab.binding.km200:1.9.0.201701180918]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1461)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1417)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)[3:org.apache.felix.configadmin:1.8.12]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
2017-01-18 16:17:05.257 [ERROR] [org.apache.felix.configadmin ] - [org.osgi.service.cm.ManagedService, org.osgi.service.event.EventHandler, id=389, unregistered]: Unexpected problem updating configuration org.openhab.km200
java.lang.RuntimeException: Decoding of the KM200 message is not possible!
at org.openhab.binding.km200.internal.KM200Binding.updated(KM200Binding.java:163)[229:org.openhab.binding.km200:1.9.0.201701180918]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1461)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1417)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)[3:org.apache.felix.configadmin:1.8.12]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
2017-01-18 16:17:05.261 [INFO ] [.binding.km200.internal.KM200Binding] - Update KM200 Binding configuration, it takes a minute....
2017-01-18 16:17:05.265 [INFO ] [.binding.km200.internal.KM200Binding] - Starting communication test..
2017-01-18 16:17:05.460 [INFO ] [.binding.km200.internal.KM200Binding] - Received data..
2017-01-18 16:17:05.464 [ERROR] [hab.binding.km200.internal.KM200Comm] - Exception on encoding: {}
java.security.InvalidKeyException: Illegal key size or default parameters
at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1026)[:1.8.0_60]
at javax.crypto.Cipher.implInit(Cipher.java:801)[:1.8.0_60]
at javax.crypto.Cipher.chooseProvider(Cipher.java:864)[:1.8.0_60]
at javax.crypto.Cipher.init(Cipher.java:1249)[:1.8.0_60]
What did I wrong? Missed something to install?
wiki:
Important: If the communication is not working and you see in the logfile errors like “illegal key size” then you have to change the Java Cryptography Extension to the Unlimited Strength Jurisdiction.
1 Like
! I NEED HELP FROM USERS!
I made a function for automatic device detection.(OH2 preparations). In this testversion this function will be called.
You can see something like:
Device is a KMXXX geteway: 192.168.90.60
It would be great if everyone could test it whether the right IP address is discovered.
–link removed–
Can you be a more specific with the test case
You have to set the IP address. In OH2 the binding should find the device itself.
in this version I included a method to find the IP automaticly.
It works like usuall. The only change is a output in the logfile like this:
Device is a KMXXX geteway: 192.168.90.60
I want to know whether it works on users network configurations…
(Btw. don’t remove the ip4 entry from the cfg file. It’s still used for the real communication)
I can confirm that my gateway is discovered in a /24 netmask.
The discovery methodology of iterating through all ip addresses and testing them for availability of a kmxxx restful service might not scale very good and be identified as somehow offensive - think about someone having a /16 netmask where you have 65534 potential hosts in contrast to a /24 netmask (this is most probably the most common one in home environments) where you have only 254 hosts. This even gets worse in a v6 environment (which the gateways currently do not support). Especially when the IP address is already configured this test delays the startup and you might want to consider to let it only run, when nothing is configured.
Yes, it is a problem, but java doesn’t support something like icmp methods. It works only on one host. I wanted to do it with a kind of broadcast ping but it is not supportet by java 
(I have all broadcast addresses of relevant private interfaces but cannot realy use it ). UPNP is not supported by KMXXX.
I limited it to 254 addresses, /16 networks are not supported. If someone has a better idea …
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.