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

[jwiseman (Mr. Wiseman (OH 4.2 Snapshot on Pi4))]

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

[chris (Chris Jackson)]

@jwiseman

Unresolved requirement: Import-Package: gnu.io

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.

[mstormi (Markus Storm)]

@chris

This is caused by not installing the serial driver. To be honest, I’m not sure what you mean about the “SERIAL1” binding.

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.

[shorty707]

@chris

• is the binding really running
• is the right binding really running
• is there only one binding really running
• clear the cache
• pray to the karaf gods since they seem to control upgrades

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

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) [?:?]

[mhilbush (Mark)]

@mstormi

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

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…

[jwiseman (Mr. Wiseman (OH 4.2 Snapshot on Pi4))]

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

[lsiepel]

@chris would look into this. More problems listed:

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

I got this error when the binding is stopped: 2018-08-22 11:57:54.589 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Stopped ZWave serial handler 2018-08-22 11:57:54.606 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.dispose()' on 'org.openhab.binding.zwave.handler.ZWaveSerialHandler@1e3badc': null java.lang.IllegalMonitorStateException: null at java.lang.Object.notify(Native Method) ~[?:?] at org.openhab.binding.zwave.int…

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

When i restart openhab the following IllegalMonitorStateException is shown. I’m not sure when this exception first occured and what the cause is, using 2018-08-20 binding version. 2018-08-22 22:08:15.130 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app 2018-08-22 22:08:15.189 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui 2018-08-22 22:08:54.374 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin 2018…

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

[chris (Chris Jackson)]

@lsiepel

More problems listed:

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.

[chris (Chris Jackson)]

@lsiepel

At what repo is that?

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

[jwiseman (Mr. Wiseman (OH 4.2 Snapshot on Pi4))]

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

[lsiepel]

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.

[shorty707]

@aradoorolesen

With the commit - Database update (#964), a new definition was added for the Fibaro smoke detector (FGSD002). The original defintion was changed to include:
versionMax" 3.1

My smoke detectors are version 3.3, and now when I try to add them from the inbox using PaperUI, I get an "Error: 404 - Not found, and the smoke detectors just remains in the inbox. Nothing in the log files! Even when logging zwave debug. Should I change log level on something else?
In the jsondb folder the DiscoveryResult file shows that it is using the new definition.

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

[lsiepel]

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

[chris (Chris Jackson)]

@shorty707

and then roll back

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.

[chris (Chris Jackson)]

@shorty707

I have the same smoke sensors… and same problem…

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

@shorty707

ediscover and readd them after a db update

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).

[shorty707]

@chris

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.

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

[chris (Chris Jackson)]

@shorty707

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.

[shorty707]

@chris

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).

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

[shorty707]

@chris

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

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

[chris (Chris Jackson)]

@shorty707

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

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.

@shorty707

Now it sits in the inbox and can not be added

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).