OH2 Z-Wave refactoring and testing... and SECURITY

Hi Chris,

Thanks for ALL your work on this! I know this wasn’t an easy undertaking . . .

Your 2.4 binding as of today works on OH2.3 but it wasn’t the easiest because of the SERIAL1 binding needed for the OH2.3 version that gets uninstalled with your OLD zWave binding. You can manually re-install it but it disappears on a reboot (after cleaning cache/tmp directories before the reboot). I had to add it to the addons.cfg parameter below in order to get it to stay.

A comma-separated list of bindings to install (e.g. “binding = sonos,knx,zwave”)

binding = serial1,sonos,mail,airquality,caldav-command1,caldav-personal1,nest,network,ntp,onkyo,plex1,samsungtv,weather1,wemo

Now i get this error when I reboot because it’s not there initially but it does get installed later on the reboot. Not your issue, just want people to know.

2018-08-24 19:09:55.512 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/volume1/homes/openhab/addons/org.openhab.binding.zwave-2.4.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [193]
Unresolved requirement: Import-Package: gnu.io

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) [9:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [9:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [9:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [9:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [9:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [9:org.apache.felix.fileinstall:3.6.4]

2018-08-24 19:09:55.555 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/volume1/homes/openhab/addons/org.openhab.binding.zwave-2.4.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [193]
Unresolved requirement: Import-Package: gnu.io

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) [9:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [9:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [9:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [9:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [9:org.apache.felix.fileinstall:3.6.4]

Best, Jay

This is caused by not installing the serial driver. To be honest, I’m not sure what you mean about the “SERIAL1” binding. If you mean the serial binding for OH1 (??) then this isn’t needed. What is needed is the serial driver and if it’s installed as suggested at the top of this thread, then it should install ok, and should not uninstall when you restart.

So, I suggest to install the serial driver with the following karaf command -:

feature:install openhab-transport-serial

It should solve your problems.

That’s a binding to talk to things over the serial bus and it’s not related to zwave in the first place.
If you install it, however, it’ll automatically also install the openhab-transport-serial serial driver.
Some intentionally use that as a trick to have OH install the driver automatically after updates, cache deletions etc, some others maybe just because they discovered this is “required” to get your zwave dev binding to work.

1 Like

ah did all that of course :wink: just not praying… will pray now until sunset and then roll back :smiley:

edit: just if it is interesting I get an error on startup (despite praying)

2018-08-25 12:50:37.552 [WARN ] [ome.core.thing.internal.ThingManager] - Disposing handler for thing 'zwave:device:15348538564:node34' takes more than 5000ms.
2018-08-25 12:50:48.118 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Stopped ZWave serial handler
2018-08-25 12:50:48.145 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.dispose()' on 'org.openhab.binding.zwave.handler.ZWaveSerialHandler@63395e': null
java.lang.IllegalMonitorStateException: null
	at java.lang.Object.notify(Native Method) ~[?:?]
	at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager.shutdown(ZWaveTransactionManager.java:207) [184:org.openhab.binding.zwave:2.4.0.201808231608]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController.shutdown(ZWaveController.java:118) [184:org.openhab.binding.zwave:2.4.0.201808231608]
	at org.openhab.binding.zwave.handler.ZWaveControllerHandler.dispose(ZWaveControllerHandler.java:247) [184:org.openhab.binding.zwave:2.4.0.201808231608]
	at org.openhab.binding.zwave.handler.ZWaveSerialHandler.dispose(ZWaveSerialHandler.java:133) [184:org.openhab.binding.zwave:2.4.0.201808231608]
	at sun.reflect.GeneratedMethodAccessor107.invoke(Unknown Source) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [98:org.eclipse.smarthome.core:0.10.0.201808011124]
	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [98:org.eclipse.smarthome.core:0.10.0.201808011124]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
	at java.lang.Thread.run(Thread.java:745) [?:?]
2018-08-25 12:50:48.180 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while disposing handler of thing 'zwave:serial_zstick:15348538564': null
java.lang.IllegalMonitorStateException: null
	at java.lang.Object.notify(Native Method) ~[?:?]
	at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager.shutdown(ZWaveTransactionManager.java:207) [184:org.openhab.binding.zwave:2.4.0.201808231608]
	at org.openhab.binding.zwave.internal.protocol.ZWaveController.shutdown(ZWaveController.java:118) [184:org.openhab.binding.zwave:2.4.0.201808231608]
	at org.openhab.binding.zwave.handler.ZWaveControllerHandler.dispose(ZWaveControllerHandler.java:247) [184:org.openhab.binding.zwave:2.4.0.201808231608]
	at org.openhab.binding.zwave.handler.ZWaveSerialHandler.dispose(ZWaveSerialHandler.java:133) [184:org.openhab.binding.zwave:2.4.0.201808231608]
	at sun.reflect.GeneratedMethodAccessor107.invoke(Unknown Source) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [98:org.eclipse.smarthome.core:0.10.0.201808011124]
	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [98:org.eclipse.smarthome.core:0.10.0.201808011124]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
	at java.lang.Thread.run(Thread.java:745) [?:?]

Yes, this is what I do, as I don’t want to have to remember to do a feature:install every time I update to a new OH snapshot.

I update OH snapshots pretty often on three different systems, so this saves me some time (and takes my poor memory out of the equation). The WARNS on startup are a small penalty for not having to remember to do the feature:install after every OH update. If you don’t update OH snapshots very often, then the feature:install is clearly the better way to go…

Thanks! I wasn’t even aware that I could get into the Karaf on a Synology. This post below helped me this morning do just that.

MartinKoMartin Korsrud

Jan 2

You can log into Karaf console by

ssh -p 8101 openhab@localhost

Password is habopen. There you can set debugging level and tail the log

Best, Jay

@chris would look into this. More problems listed:


@DanielMalmgren filed an issue. At what repo is that? couldn’t find the github issue.

Aren’t these just the same issue that was mentioned earlier? As I said a day or two back, I will look at this when I get a chance. This only seems to cause an exception on shutdown, so it’s not too important right now.

It’s in the ZWave repo (always a good place for ZWave issues :wink: ).

Need advice to get my zWave devices to ZW100 Multisensor 6 again after the upgrade?

I have the same 4 zWave sensor devices but only 1 of them is being assigned the ZW100 Multisensor 6. Any advice to force the issue on the other 3?

I did copy/paste the XML files for the other 3 and change the NODE info in them but NO luck still.

Z-Wave Node 002 - BASEMENT ONLINE
Unknown Device <—
zwave:device:ffffffd1ffffffb2ffffffdbffffffad:node2

Z-Wave Node 003 - LOFT ONLINE
ZW100 Multisensor 6 <-- Correct
zwave:device:ffffffd1ffffffb2ffffffdbffffffad:node3

Z-Wave Node 004 - GARAGE ONLINE
Unknown Device <—
zwave:device:ffffffd1ffffffb2ffffffdbffffffad:node4

Z-Wave Node 005 - ATTIC ONLINE
Unknown Device <—
zwave:device:ffffffd1ffffffb2ffffffdbffffffad:node5

Best, Jay

Yes the same issue’s and i wrote that you would look into those as you said earlier. It was a reply to Shorty707 who also posted about the same exception.

I have the same smoke sensors… and same problem…
I deleted them and the xml to rediscover and readd them after a db update…
they just sit in the inbox and no way to add them

I know the https://github.com/openhab/org.openhab.binding.zwave repo where it should go. Was asking where he raised the issue, because there is no issue listed at that repo with #641 or anything that looks like a IllegalMonitorStateException

1 Like

I’d be interested to see if this works - I don’t think your issue is related to the binding. The fundamental problems you’re seeing (like nothing in logs) indicates that the binding is probably not running. Rolling back isn’t really a solution - you need to work out what’s happening if possible.

When do you get 404? What does this mean exactly.

Ok, so there’s a problem in the database that will fix this? I’ve not seen anything relating to this device so must have missed it (sorry).

I just found the problem from @aradoorolesen and he had the same device and same problem…
so maybe he found the root cause whats stops this device from being readded after deletion

So the problem you reported earlier was only relating to one device? I clearly misunderstood this.

No - just an update to the database … not a fix.

That was the reason for me to delete the device and xml and to rediscover it.

Now it sits in the inbox and can not be added (all clearing cache and so done)…
Im habmin and in the log there happens just nothing at all when adding.

in paperui a small notificaton “404” appears when I try to add it
image

yes - everything else but this (2 same smoke sensors) works and can be added

Ok, sorry (again) I’m confused. You said a couple of posts back that you would re-add after the database update, so I assumed something had been fixed in the database.

I don’t know why this is, or why the database should influence this - I think we will need more information unless it is fixed somehow already (which I’m still a bit confused about - sorry).