Ok, so I guess you mean what I normally call the interrogation?
This gets the data from the device - it will ALWAYS return the value from the device and this is what is placed into the XML that OH creates. This value is then used to correlate the data in the database which brings us back to the same issue I mentioned a few days back -:
Then somewhere in the DB lookup and if I follow right is what gets into paperUI I end up with: manufacturerRef: 0003:0083,0003:008D,0003:1083,0003:108D
Sorry for taking time on this one just trying to understand what is going on under the hood.
Looking at the 2.50 branch they look correct. I have tried to compile myself and failed miserably so I haven’t built from the latest to try. So looking at them I not able to see the issue myself.
I’d suggest to ensure you are using the latest binding since from a quick search in the database for 0003:108D (ie your devices ID) it only shows the correct entry (ie the PD03Z) and this also seems to be consistent if I search for this in Github.
This is not the latest compiled binding - it’s the latest milestone release, but as it’s quite old now I’d suggest to use the latest snapshot which will have the database we see in Github.
019-07-08 18:36:39.931 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [249]
Unresolved requirement: Import-Package: com.thoughtworks.xstream; version="[1.4.0,2.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
I updated my 2.5M1 to the zwave snapshot this past weekend with no issues.
Did you delete the managed zwave binding before placeing the new jar in the addons directory?
You could also try restarting OH.
This probably just means that the device is not initialised.
The binding is not running. It looks like you need to add the package com.thoughtworks.xstream. I’m not sure why this has started happening - it’s something to do with the new build environment.
Ah magic thank you both to your help. Between updating to the new snapshot and deleting then readding (I thought reinitialization would sort) problem is solved.
Again thank you for all the help.
Out of interesting within the boundaries of OH is there a way it could be coded to fetch xml from the DB and cache locally?
The database is embedded in the JAR - this is a limitation of openHAB - not the binding. If we wanted to work around this, I’d need to re-implement a lot of the code from OH that does all the database stuff.
It also would introduce a load of other issues since the database is linked to the source so really the two need to be updated together.