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 -:
Yes thank you too used to SNMP terms.
So I understand more then the way the z-wave plugin works is that it interrogates the “node” and in this case gets:
<manufacturer>0x258</manufacturer>
<deviceId>0x108d</deviceId>
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.
Yes - you roughly have it correct.
Thank you appropriate your help.
Looking at the XML themselves:
motionsensor_0_0.xml
motionsensorin_0_0.xml
pd03z_0_0.xml
pd03z_3_80.xml
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.
I am using the latest compiled release 2.5.0 M1. I would agree with what you are saying about the using the latest binding.
Just check it is using:
2504810 Feb 6 22:24 org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar
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.
Dam sorry you right.
I will change now and post back.
Right I have updated restarted OpenHab then the whole OS (As still wasn’t right) with no joys.
2728536 Jul 8 18:12 org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar
Interesting the reinitialize option under advanced is missing now.
This has popped up in the logs since.
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.
Right I have deleted the jar again. Cleared out the cache and tmp the put back.
It is now saying I am missing org.eclipse.smarthome.io.transport.serial so ran:
feature:install openhab-transport-serial
now it is missing com.thoughtworks.xstream so sorted from Latest Zwave binding missing module?
The moduel is back up and running now but the sensors are still using the wrong config DB XML.
I have tried a reinitialise but still pulling the wrong one.
You will need to delete the thing and add it back so that it picks up the new database.
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?
No - the XML from the database is stored inside the JAR file only - there is no local cache etc that you can manipulate.
Thank you Chris I undstand that is how it currently work but I was wondering if it is possible.
No - it’s not possible.
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.
Cool thanks Chris.
Just trying to learn how it hangs together. Thank you for your prectimeious time to help me understand the inner workings.