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

Tags: #<Tag:0x00007f1829f6cff0> #<Tag:0x00007f1829f6ce60>

(Scott Rushworth) #2291

Need to know what you did in order to know if you’re doing it wrong :wink: . Is it already securely included? Look in Habmin. If not, double check you have only one binding with the correct verion (from the top of this thread and newer than Jan 2). Then exclude the lock (select controller> Tools> Advanced> Exclude Devices. Then, using Habmin with controller < ~10 ft away from lock (closer is better), start an inclusion, enter programming code into lock and press 0. Then wait a minute or two so for inclusion to complete. Green checkmark on lock will flash and beep. Lock should show up in inbox. If this does not work, exclude again, then reset lock (unplug battery, press and hold Schlage button, then plug in battery), and include again. Your settings will need to be reentered. When I was testing, resetting was not necessary.

Once Habmin shows the lock is securely included (green checkmark under Attributes> Using Security), then put the lock back on the door.

(Scott Rushworth) #2292

This one took a while, but my Leviton switches and dimmers are now reporting instant status updates again. Long story short… I deleted the Thing and rediscovered. Taking it a step further, I removed the association and the updates stopped. Readding the association brought them back! So, device definition was out of date and somehow broke instant status updates even though they had been working. Updating the definitions fixed it. And another confirmation that adding/removing associations is working (for me).

Is there an easy way to delete all zwave things? If not, I’ll try to script something using the REST API. I guess I could then add default polling and temperature scale… :wink:

Sorry if you have already explained this before, but how much effort would it be to have the binding update existing device definitions after a binding update, so that Things would not need to be deleted and rediscovered? Lacking that, maybe a visual cue in Habmin, or a log entry at startup to notify that a device’s definition is out of date. Or maybe a separate channel on each device, so that a rule could be used for notifications?

(Chris Jackson) #2293

Not that I know of…

The default should now be 1 day :wink:

Probably not too much work (I think)…

This is probably more difficult as checking the definition is the same might not be simple.

I’ll have a look to see if I can simply add the update with a config action.

(Scott Rushworth) #2294

I think this would be a great addition. I will hold off updating my devices, in case you get it going.

(Chris Jackson) #2295

I think it’s easy - the binding updates the thing type routinely - the only thing I’m not sure about is if I set the same thing type that’s already set, if it will update or not. I have a feeling it might not in which case I might just set it back to the default “unknown” type and let the existing code redetect…

(Scott Rushworth) #2296

Definition clarification question: the device database holds Thing types, and deleting/rediscovering is updating the Thing type with the version from the binding?

I take it there is no versioning of the Thing type stored in the database, binding, and Thing configuration, so that the version in the binding and Thing configuration could be compared to check if there was an update when the binding starts? Although… setting to “unknown” shouldn’t be too bad if the type/ID can be pulled from the XML or existing Thing.

(Chris Jackson) #2297

Correct - in this context it’s in no way related to inclusion etc.

Also correct :wink: Maybe I should look to add this…

This is exactly how it works now. The device is always detected as unknown during discovery, then when the thing initialises it does the check and changes the thing type. Setting the type back to unknown will simply repeat this cycle - it doesn’t need to include, or do any discovery at all (assuming that was already completed of course).

(SiHui) #2298

The FGS222 is working fine with this channel setup:

Switch FibFGS222_DoubleRelay1_1 (gRestore) { channel="zwave:device:15ca6a108b9:node36:switch_binary"}
Switch FibFGS222_DoubleRelay1_2 (gRestore) { channel="zwave:device:15ca6a108b9:node36:switch_binary2"}

Also the physical switch presses are instantly visible in openHAB.
You need to find the problem in your setup … :sunglasses:

(Martin Eskildsen) #2299

Both the FGS221 and FGS222 is working as expected with the setup you describe. Even in my setup.
If I use switch_binary1 instead of switch_binary it doesn’t.
So it is either my expectations, the ZWave Binding or the Fibaro firmware that is the problem. My configuration works fine when using the suggested settings

(SiHui) #2300

Sorry, don’t get that: if it is working, why is there a problem?

(Martin Eskildsen) #2301

Well as I see it switch_binary1 doesn’t work as expected. using switch_binary is a workaround, I really loves workarounds, especially those that works :-). But if openHAB should be a intuitive HA solution, workarounds isn’t any good. I am not sure it is a problem in the binding, it could be a lot of other things. There might even be an obvious explanation why it is working that way.

(Kevin) #2302

Here’s what I’ve done…
Lock was originally connected to Vera. I unpaired it successfully. (which seems to be rare for me…)

Ive used openhab (docker container) in the past, using vera as my zwave controller. Well, I got the HUSBZB-1 for christmas! Yay, finally time to get rid of the horrible vera :wink:

Now onto Openhab…
It’s a new Openhab2 install, using a rpi3.
– Installed Raspbian Stretch Lite
– Installed Java (
– Installed Openhab2 from here (https://docs.openhab.org/installation/linux.html#manual-installation)
– updated permissions/groups for the pi and openhab user. Setup samba etc…

Initially added the z-wave binding through paperui. That didn’t work, found your updated bindings. Uninstaled the z-wave binding via paperui, downloaded the org.openhab.binding.zwave-2.2.0-SNAPSHOT.jar from the link above, and placed it my addons folder
Restarted openhab
In paperui, I got to my things, configure z-wave binding and point it to /dev/ttyUSB0 (/dev/ttyUSB1 is zigbee)
paperui (and also habmin) detect all my zwave things, including the Schlage lock.

I added the lock, but it never picks up the secure piece. (this lead to my post last night)

tonight I’ve removed the lock, and followed Schlage process to reset the lock (disconnect batteries, hold outside button, connect batteries) check blinks 3 times.
Using the programing code, I try adding the lock to habmin, but paperui and habmin already see the unsecure lock. I add it anyway, enter the programming code into the lock, after pressing 0, wait about 5 seconds and get the red x. The rpi is about 3 inches away from the lock. (hanging on the door lever).

I don’t see how to force security on the lock, am I doing it wrong? :slight_smile:

(Scott Rushworth) #2303

If the lock was already excluded from the network, just delete the Thing.

Just to be sure, did you also start zwave inclusion/discovery in OH? And did you do this before putting the lock in inclusion mode?

[EDIT} I reread your post a few more times :slight_smile:… if you have already included the lock, you will need to do another exclusion. Resetting the lock does not clear the zwave network.

(Kevin) #2304

Yeah, I’ve deleted it and readded the lock about a dozen times already, hoping for a different outcome, thinking I’m missing something along the way…

Not sure I’m doing the right thing for the exclusion…
For the exclusion I went to Tools > Show Advanced, then Tools > Remove device from controller.
waited a few minutes
Device was still showing within my things
checked the logs, it’s shoes that the node wasn’t found, but it’s still listed in m things.

2018-01-04 20:57:48.546 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 5: Remove failed node failed as node not found

restarted service, still showing,
deleted it, now it’s gone.
I was assuming Removing Device from controller would remove the device from my things list as well…

As far as adding my devices, as soon as I click the search, the device is seen and added, without me even having time to enter the code on the lock.

(Kevin) #2305

Are my z-wave device settings correct?

Inclusion is sett to Network Wide inclusion and Secure Inclusion is set to Entry Control Devices

(Scott Rushworth) #2306

Nope. Chris has commented on this, so you should be able to find it in this thread. You will need to manually delete the Thing after an exclude.

OK… this looks to be your issue. After starting exclusion, you need to do the same procedure on the lock that you do for inclusion (program code then 0). You should get a green checkmark. If not, the lock is still included. Your lock is still included. After excluding, delete the Thing.

If you only have the one controller, then it should be set to SUC. Was that the default setting?

(Kevin) #2307

Gotcha, I’ll search for his thread and go from there! Thanks for the insight!!

Yes, that was the default setting.

(Scott Rushworth) #2308

Here you go…

(Kevin) #2309

Ahhhh!!! Success!!! Thank you!!

I came across that thread while searching! I agree with him, there is confusion (at least I was confused, hopefully not the only one :wink: ) I’m sure they’ll get it resolved.

In the meantime, if anyone newbie that runs into the issue, See the Excluding Z-Wave Devices toward the bottom the page.

(Scott Rushworth) #2310

Excellent! How many other zwave devices do you have? Secure inclusion seemed to be failing for people with a large number of devices, but Chris put in a recent fix for this.