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

Still haven’t gotten secure inclusion of the lock working. My next step would seem to be including it in a clean (no other devices) network. But, I don’t want to reset my current stick and go through the effort of re-including all my existing devices. I did that for a clean OH1->OH2 transfer, and it sucked.

[Edit: Ignore below. I tried a multi-stick install it and it seems to be working… but lock inclusion still doesn’t. So, continuing to play around with that.]

Does the binding support a multi-instance installation? My thinking is to get another USB Zwave stick, and try including only the secure device on that stick, with all other devices on the existing stick. But, I’m not sure how to include a binding twice, or have a single binding use two sticks.

Chris, you mentioned in a year-old thread that OH2 “should (in theory)” support this… but I didn’t see any evidence that theory and reality ever converged, or how to make it work…

Multiple z-wave bindings

In general, would having the secure and not-secure devices on different zwave networks/sticks offer any benefits in terms of either reliability or security?

No - there isn’t a way to run the binding twice, but this isn’t what you really want is it? You just want to have two sticks - right?

Sure - this is perfectly possible in OH2 - just add two interfaces.

Probably not any advantages. You might have issues with interference, but hopefully it won’t cause too many issues.

Thanks for the quick reply… after writing the post I tried it and it worked. You responded while I was editing. Too quick! :slight_smile: Lock inclusion still doesn’t work, but the log files are much cleaner so it’s easier to see what’s happening. I’ll play with that for a while.

Just an update… it works now. What I ended up doing was getting a second USB zwave stick, and adding it as another interface. Just trying to add the new device after adding the usb stick didn’t work… (I’m not sure how to specifically enable zwave inclusion on one interface of the binding?) So, I pulled the ‘main’ zwave stick out, and just ran inclusion on the second stick. This worked the third time I tried.

At this point, I can send commands (door lock/unlock works) but the updates from the device don’t seem to be reflected in the items… if I manually lock/unlock I don’t see events, and the alarm, battery, etc., are not updated. Stlll debugging that.

Thanks for all your hard work on zwave and openhab, Chris!

Yes, that is one of the shortcomings in the current dev version when using 2 sticks. Would be nice to have that more controllable.

This is a limitation of the system - not the binding. I opened an issue about this some time back…

Interesting. What about extending the mechanism used to ‘Exclude Devices’ in the Advanced Settings part of each instance; putting a ‘Include Devices’ mechanism there, and some way of having the binding discovery just query the interfaces for newly included devices would be hacky and less convenient for users with only one interface (ie. almost everyone…). Maybe an additional port configuration, “Interface enters Include Mode on Discovery”,or such, that defaults to true, but multi-interface users could disable and trigger inclusion manually for each interface?

Sorry, getting off the ‘Security’ topic of the thread (which works! Yay!), but given my experience the reliability of secure inclusion will drive more people to try multiple sticks, and the multiple-interface use case might become more common…

This is really a hack. The system should support this and I’d prefer not to try and hack something into the binding.

I’d prefer to put time into solving the issue to avoid this - it’s likely to cause other problems, and isn’t nice. I’ll likely look to invest more into getting the info needed to resolve this.

1 Like

I have the inclusion issue on a second lock I bought. Anything I can do to help you find the issue?

Probably not - I’m happy to look at a log, but I suspect that it will just show the device not responding which is what I’ve seen in other logs.

I’m considering investing in the full developers kit to try and get this resolved - let’s see…

So I’ve been working through a lot of my problems so far without resorting to asking a dumb question, and I’ve been entirely successful so far thanks to a lot of the forum posts I’ve searched around. Have my garage door controller included securely and working great, my door lock actually works (Yale Real Living). OpenHab is kicking butt, especially since I created an XML for my Alarm.com thermostat (put in my created xml via a ticket on the database site, same as the building 36 one actually).

Now that being said, I’m stumped. As I said, I have my door lock added, and it works. But, I’m missing a few things when I view the item in Habmin. I have no configuration options nor user codes. The only sections I see are “Description,” “Properties,” “Channels,” and “Attributes.” I know there are supposed to be other sections, I’ve tried enabling view advanced settings and it helps nothing. My Zipato keypad (same product as the wintop rfid keypad, different ID) also does the same thing. No user codes options or configuration area.

Anyone have an idea what the heck I’ve done wrong? Door lock says it’s added securely in attributes… Keypad for some ungodly reason doesn’t support security, but should still work regardless. Looking forward to fixing this last problem in my system!!! Any help is appreciated. And the work put in to helping the community by many here, especially Chris, is astounding. I downloaded the dev binding from here, the 2.1, probably 1-2 weeks ago if that helps at all. Thanks!

how much is the developers’ kit?

Well, it’s north of $1000, but it also has requirements that would mean a small part of the binding could not be open source. This is limited to the very low level communications with the stick so is a very small part of the binding which could be split out so that there was an OS version that worked like the current binding (ie using the current source), and a closed source part that hopefully solved issues that people have (like deleting nodes from the stick, and improving healing). All the command class stuff would remain OS in any case… Most people wouldn’t notice the difference - it’s just this part of the source that would have to be a JAR instead of Java…

(sorry - that was a long answer to a short question :wink: ).

Is it possible that would be something that the OH Foundation can invest into? Not sure what stores of any $ they may have raised or put together at this point. But for something so wide-spread to the ZWave functionality - seems like a worthwhile direction of investment.

$1k seems like a pretty penny of a hit to an individual. I guess the alternative could be some type of a “bug bounty” type situation where once enough people pledge the $ to raise to the $1k mark, then you could initiate the purchase? I mean at scale, the OH community of ZWave users is fairly large. It shouldn’t be hard to find 1k users to donate $1, or in some instances many would likely donate or pledge $10 and we’re down to just 100 users.

Just some food for thought.

Sooo, I wanted to suggest the bug bounty. As a developer though I think it’s a bad idea because it contributes to short sighted bug fixes rather than longer term goals.

Since I’ve just about gotten my OH2 working (just trying to figure out why user codes aren’t showing as well) I want to get Z-Wave over the finish line. I’m happy to contribute to a campaign where we could raise money for a dev kit AND maybe pay for some of @chris’ time (or however he chooses to use the extra $).

Makes sense. Happy to pledge $250.

Anyone else?

I would also contribute to getting @chris the dev kit.

I’d be in as well. @Kai just setup a Bounty Program we could use:


Please note that BountySource is limited to funding developments that end up as a contribution to the open source project itself - it is not necessarily the right mechanism for raising money for closed source developments (although I know that it is not Chris’ decision to keep it closed, but a restriction that Z-Wave imposes, but nonetheless - the result won’t be open source, with all its consequences (sources are not available and must not be shared with anyone, so it is code with a bus factor of 1)).

That makes sense. Thanks for the clarification.