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

James_Barnito · February 6, 2017, 7:56am

well, everything in the cfg is #### out, that means its not active correct?

chris · February 6, 2017, 8:58am

The security won’t stop you excluding devices. Also, even if the lock is securely included, it (probably) should still be recognised as the command class used for this is not normally secured. This depends on the device, but is the case for my lock.[quote=“James_Barnito, post:118, topic:21653”]
This is a new problem, not being able to use those commands.
[/quote]

If by “those commands” you mean the controller commands (soft reset, hard reset etc…) then if you are getting errors it’s nothing to do with any command to the device - any error would come elsewhere in the framework as there’s no feedback from the success (or otherwise) of these commands.

James_Barnito · February 6, 2017, 10:23am

I completely uninstalled and reinstalled everything, and added lock back, it is working again. Thank you for your help

chris · February 6, 2017, 5:00pm

I’ve updated the JAR - this mostly adds the database changes but also changes polling a little and doesn’t wait for responses for some transactions.

Same link as above.

Dim · February 6, 2017, 5:15pm

Testing now
It’s time for me to get a security device also (I will go for a door lock… it will help with the WAF)

JjS · February 6, 2017, 5:46pm

Can you see the network in HABmin with this experimental bindong?

In binding 2.0 there was a nice graph, now I see a single node (controller). In Config/Things tab all 38 nodes are green…

chris · February 6, 2017, 5:49pm

If by bindong, or mean binding then yes, this version should work better with the network heal if you have the nightly heal enabled…

At the end of the day, the graph is done in HABmin - the information that HABmin uses is the neighbours that you can see at the bottom of the attributes -:

This should be better updated, and therefore the graph should be more correct. I welcome feedback on this since it’s another major change in this binding.

Dim · February 6, 2017, 5:53pm

Note to testers: When you will follow the installation steps from post #6 in this thread here: Link and uninstall the existing Z-Wave binding from PaperUI: openHAB2 will also uninstall automatically the openhab-transport-serial feature.

After you manually deploy the new *.jar in your /usr/share/openhab2/addons (apt based installation) or /opt/openhab2/addons (manual installation) you need to issue the following command in the console (ssh openhab@localhost -p 8101 with password habopen)

feature:install openhab-transport-serial

Don’t forget to remove your existing Things first from PaperUI.

Mike_Bagdanoff · February 6, 2017, 6:00pm

@chris,

Thanks for getting this rolling. I’m getting everything set back up now and testing through some stuff. I’ll have more feedback in a few hours when the battery devices have all had a chance to wakey.

I do notice that two of my items are “marked failed by the controller” though, at least in the case of the motion sensor device, it still works as normal. Will functional devices be unmarked or should I “mark it as FAILed” in habmin and reinclude it? (I accidentally did that with the other device and saw that it excludes that device, so oops)

chris · February 6, 2017, 6:08pm

Yes - this is an area that may need some improvement in the binding… Firstly, to answer your question, yes, they will. The controller keeps a list of devices it thinks are working ok, and which ones it thinks are failed. In this version of the binding I’ve (currently!!) decided to use this function instead of keep an internal DEAD state - I figure the controller knows best.

Currently, if a device is marked as FAILED, the binding doesn’t try to initialise it - I’m open to be convinced to do something else if people find problems. The reason I did this is if a device is really FAILED, then trying to communicate with it just bogs the network down. Generally, if a device is just asleep, or whatever, then this changes to ‘not failed’ when it wakes, and things progress fine…

That’s what I’ve seen in my testing anyway - as I said, I’m open to discussion and being convinced there’s a better way to handle this sort of thing.

ptmuldoon · February 6, 2017, 6:12pm

I replaced with the update binding but still at work so can’t test for any performance.

But I do get these java errors until the Controller is started, and then they stop.

2017-02-06 13:02:36.568 [ERROR] [ome.core.thing.link.ThingLinkManager] - Exception occured while informing handler:null
java.lang.UnsupportedOperationException
	at java.util.AbstractList.add(AbstractList.java:148)[:1.8.0_121]
	at java.util.AbstractList.add(AbstractList.java:108)[:1.8.0_121]
	at org.openhab.binding.zwave.handler.ZWaveThingHandler.channelLinked(ZWaveThingHandler.java:432)[205:org.openhab.binding.zwave:2.1.0.201702052317]
	at org.eclipse.smarthome.core.thing.link.ThingLinkManager.informHandlerAboutLinkedChannel(ThingLinkManager.java:264)[105:org.eclipse.smarthome.core.thing:0.9.0.201701192225]
	at org.eclipse.smarthome.core.thing.link.ThingLinkManager.receiveTypedEvent(ThingLinkManager.java:304)[105:org.eclipse.smarthome.core.thing:0.9.0.201701192225]
	at org.eclipse.smarthome.core.thing.link.ThingLinkManager.receiveTypedEvent(ThingLinkManager.java:1)[105:org.eclipse.smarthome.core.thing:0.9.0.201701192225]
	at org.eclipse.smarthome.core.events.AbstractTypedEventSubscriber.receive(AbstractTypedEventSubscriber.java:50)[98:org.eclipse.smarthome.core:0.9.0.201701192225]
	at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:192)[98:org.eclipse.smarthome.core:0.9.0.201701192225]
	at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:1)[98:org.eclipse.smarthome.core:0.9.0.201701192225]
	at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:179)[98:org.eclipse.smarthome.core:0.9.0.201701192225]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
	at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]

chris · February 6, 2017, 6:16pm

Strange - I’m not seeing that here, but this is part of the new code I added so I’ll take a look at this ASAP.

Thanks.

Dim · February 6, 2017, 6:23pm

Reporting back: All is good and working. I had to wake up my battery based devices a couple of times to get them properly recognized (this is normal)
Devices used:

Aeotec Z-Stick Gen5
2 x FGMS001 Motion Sensors
2 x FGPB001 Push Buttons
1 x FGRGBW Controller
(no sec devices yet)

chris · February 6, 2017, 6:25pm

Updated again - I suspect that there might be a race condition on startup with initialising the polling list - depending on startup order links might be established before some initialisation.

Let me know if the exception is still there…

JjS · February 6, 2017, 6:30pm

It was a typo or my subconscious… This bind-thing still needs to earn the right for the binding name, at least with the network that I am struggling with.

As per the network graph, this is what I see in the controller attributes:

I wonder why for the controller I see much less data than for the other nodes

The graph is pretty empty:

ptmuldoon · February 6, 2017, 6:32pm

Replaced with the latest and the Error is gone.

chris · February 6, 2017, 6:33pm

No idea - maybe it has less neighbours. That’s what this means at least.

Not sure why that is, but it’s not related to the binding in any way.

chris · February 6, 2017, 6:35pm

Thanks.

JjS · February 6, 2017, 7:00pm

I am trying with today’s realease, dowloaded new jar replacing the older one downloaded from the same URL couple of days ago (same file name) and I get this in the log:

2017-02-06 19:55:01.046 [ERROR] [org.openhab.binding.zwave           ] - FrameworkEvent ERROR - org.openhab.binding.zwave
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [229]
  Another singleton bundle selected: osgi.identity; osgi.identity="org.openhab.binding.zwave"; type="osgi.bundle"; version:Version="2.1.0.201702061819"; singleton:="true"

	at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
2017-02-06 19:55:01.532 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0'
2017-02-06 19:55:02.067 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Serial port is initialized
2017-02-06 19:55:02.103 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2017-02-06 19:55:02.104 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.

I understand that for upgrade from the kar provided binding I needed to delete things and uninstall z-wave binding. Should I do the same now? If yes, how? Removing .jar from addons did not help.

Mike_Bagdanoff · February 6, 2017, 7:29pm

Trip report so far:

Schlage BE469 Touchscreen Deadbolt
XML: network_da5de716__node_68.xml (4.5 KB)
Currently shows up as: “Node is not communicating with controller” in Habmin, though it communicated enough to initialize

When I send a lock command I get:

11:05:50.390 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage inputMessage: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=17, callback=0, payload=00 11 03 30 03 FF
11:05:50.393 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lockMessage: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=17, callback=0, payload=00 11 03 30 03 FF
11:05:51.682 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'LockFrontDoor_Lock' received command ON
11:05:51.685 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 68: Command received zwave:device:bae255ae:node68:lock_door --> ON
11:05:51.688 [WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 68: Command class COMMAND_CLASS_DOOR_LOCK not found
11:05:51.689 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 68: No messages returned from converter
11:05:51.699 [INFO ] [ome.event.GroupItemStateChangedEvent] - gLocks changed from OFF to ON through LockFrontDoor_Lock
11:05:51.701 [INFO ] [marthome.event.ItemStateChangedEvent] - LockFrontDoor_Lock changed from OFF to ON

which seems strange, the xml from the 1.9 binding lists DOOR_LOCK as a command class but the new xml does not