Looks like converter and command class are not registered.
I am interested. Could you please send the classes.
@dbadia, @chris, looks like some of the security changes were lost in one of the merges.
ZWaveActiveBinding does not have read of networkKey anymore in Dave’s “security m-merge” branch (which I guess is used to compile z-wave security distro shared for testing).
Hence my failure to init the garage controller (and other people’s recent failure to work with door locks in the other topic).
Could you please merge a branch that would contain both missing changes to read the network key and the barrier operator changes?
Currently there is no ‘official’ repo that has the security classes included and I’ve not merged anything… As I’m not sure what branch you’re talking about, so I’ll leave Dave to answer this one 
.
Hi vgoldman -
I built the dropbox jar to make it easier for people to test out my changes. It was built from this branch:
https://github.com/dbadia/openhab/tree/security-mmerge
That branch contains the Barrier command class and converter. I even downloaded my jar and decompiled CommandClass to ensure that the barrier mapping is present (it is).
Can you post your log from inclusion to a dropbox or pastebin account? I’d like to see the full inclusion process. Perhaps the device isn’t advertising that it supports the barrier command.
I’ve been running the mmerge branch code at home for a few weeks now without issue (although I don’t have anything that supports barrier, still waiting for monoprice to get their garage door detector back in stock!)
Dave
Dave, the problem is currently not with the command class, but with some of the security changes missing.
If you look in your branch at the class below, it does not have section which reads network key from configuration.
It was probably lost in one of the merges.
https://github.com/dbadia/openhab/blob/security-mmerge/bundles/binding/org.openhab.binding.zwave/src/main/java/org/openhab/binding/zwave/internal/ZWaveActiveBinding.java
I have tried to merge Chris’s zwave-security branch with yours to add missing change, and tried inclusion again but still no luck.
I tried the same with Homeseer and it works fine (successful security pair + BARRIER_OPERATOR class available).
However my merged zwave binding still can not work with it even after 3d party inclusion - it still shows security pair as incomplete and BARRIER_OPERATOR class is not available.
<entry> <commandClass>SECURITY</commandClass> <securityCommandClassWithInit> <version>1</version> <instances>1</instances> <disableEncapNonceGet>false</disableEncapNonceGet> <securePairingComplete>false</securePairingComplete> </securityCommandClassWithInit> </entry>
Either my merge is missing some more changes or something else is wrong.
Can you please compare your branch to ether Chris’s zwave-security branch or my merge at GitHub - vgoldman/openhab at zwave-sec
Besides the class with network key I mentioned above, something else is probably missing.
I really wouldn’t use any of my security stuff - the only branch I had was from a long time ago when I merged Daves original changes into 1.5 or 1.6 (from memory).
got it. i’ll try to roll back to one of Dave’s commits done before the network key disappeared
@dbadia, could you please share a working version of the binding with all security changes (see my post above on what is missing)?
@vgoldman try out the new dropbox jar.
I found a couple of classes I had locally that weren’t in the dropbox jar or git.
If something doesn’t work, post your log file with debug enabled
@dbadia - tried it, still no luck.
After pairing I still can’t see BARRIER_OPERATOR in the list of supported classes. Not sure if secure pairing is successful or not. securePairingComplete is still showing as false in node xml, so I guess something is still wrong.
See link below for zwave log and node xml. I also attached log from homeseer previous pairing which clearly shows that BARRIER_OPERATOR is supported by the device once it’s successfully paired.
https://drive.google.com/folderview?id=0BzRpE98JQHVgQ0V2aVJ4U2NxTEU&usp=sharing
Yeah I looked at the log. The secure pair process stops about halfway through. It’s most likely a merge problem when I merged the security-beta-test changes into the security-mmerge branch. The security portions of those 2 branches should be the same but they obviously aren’t.
Next step is to merge the barrier change commit eb5a203303 into security-beta-test and try that out. Chances are that will solve the problem.
It’s a really busy time of year for me. Give it a shot if you don’t feel like waiting for me to find the time, it should be very easy to do…
Dave
Hey guys
I bought one of these GoControl Linear GD00Z Garage Door Openers. As always, I turn out buying stuff that doesn’t work with OpenHAB yet… I should learn to check before I click that button!
Usually, it’s just a matter of database add, so I can file a request and add the XML, and a couple of days later I’m able to download a working ZWave binding jar.
But apparently this one is a bit more complex. Is there any chance that there is a file somewhere that I can download to get this opener to work, or should go buy some other device?
Regards
/P
I tried this approach: https://github.com/openhab/openhab/wiki/ZWave-Security-Testing . It didn’t work though - I couldn’t get it to complete the inclusion. So I will either just wait, or go buy some other device (this time doing some research first).
But - som funny side effects:
I have an Aeon Labs DSB45-ZWUS water sensor, and I have a Fibaro FGMS-001 type 801 multisensor.
When using the ordinary 1.9.0 snapshot jar from August 11:
- Fibaro FGMS-001 801 took two hours to include - but after that it worked fine. See
- https://github.com/openhab/openhab/issues/4274#issuecomment-239396131
- Aeon Labs DSB45-ZWUS showed the same symptoms - but this time I waited for eight hours without any change. It never got fully included.
When using the security testing jar:
- Fibaro FGMS-001 caused loads of errors in the log, complaining about not existing in the device database. But - it continued to work fine. It sent sensor reports when it was supposed to, and temperature / luminence / battery reports came in normally. The device name was still visible in Habmin, but I could no longer configure parameters or association groups.
- Aeon Labs DSB45 got included in seconds, and worked perfectly fine. I took the opportunity to tweak the configuration parameters and association groups to my liking.
When going back to the ordinary 1.9.0 snapshot jar:
- Fibaro FGMS-001 got back to the fully working state.
- Aeon Labs DSB45 complained in the log about securedCommandClasses and wakeupCommandClass not being supported. In Habmin, the entry was all UNKNOWN again (as described in https://github.com/openhab/openhab/issues/4274#issuecomment-239396131 ). But - it continued to work fine. Both the sensor and the battery reports came in normally.
Don’t know if this might be already known and normal for you, but if it’s not I can always craft some logs for you.
Regards
/P
PS. As rather expected, the Gocoontrol GD00Z complained about securityCommandClassWithInit at startup.
I am also interested as to the state/stability of supporting this device within OH1 or OH2. Thanks.
It has been included in OH2 for a long time - feedback is welcome of course…
Hey, maybe that is my solution! Running OH1 for my regular stuff, and OH2 for that lock and possibly some other stuff. I guess they could talk MQTT to each other the same way that my two instances of OH1 does now.
Has anyone gotten this to work with the Linear GD00Z Garage Opener ? I have the device paired with OpenHab2 using security, but I only see the BARRIER_POSITION channel.
I don’t see the BARRIER_OPERATOR channel. Does anyone have any idea on how to add code for the BARRIER_OPERATOR channel under OpenHAB2 ?
This probably means that the device is not securely included. If the device did not complete secure inclusion, then it won’t even tell you that it supports these classes.
If I remember correctly, people are using this with OH2 if you use the development binding, but I’m not 100% sure without checking.