[SOLVED] Neo pd03z using incorrect XML for config

Tags: #<Tag:0x00007f617e5d1790>

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.

2 Likes

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.

1 Like