Yes it does require Security implemented. I had pulled in @dbadia 's security changes to get the whole thing working of course.
Does this mean that the security class stuff has been figured out to work with openhab? Locks can now be used?
No - it means that work is ongoing to get it included, but it may still be a little time off.
Follow the progress on the following thread -:
@askant Were you able to submit a PR for this?
If not, I can add them into my security changes if you send me the code.
Dave
@askant & @dbadia, did you guys ever connect on this?
Just got Linear GD00Z-4 controller, I’d like to test it out
Also requested by someone here
No, I haven’t heard anything about it.
Dave
@dbadia Sorry I have been a bit too busy with my for the past couple of months. I will send across the BarrierOperator Implementation I have.
sent to Dave and Vlad.
@askant - thank you.
@dbadia - Dave, will you be able to merge it and compile the binding for me to test the class?
I’ll get to setting up my own devenv at some point, but it will take time probably, my last one died together with my hard drive.
Are you able to make this available so it can also be added to the OH2 binding?
Cheers
Chris
@vgoldman I did a merge into my OH1 security branch and pushed a jar to dropbox
You’ll need to exclude your barrier device then do a secure pairing per the instructions here
@chris Would like to see someone get a good test with this code then I’ll send it over to you for OH2 integration
Ok - but as OH2 is a test binding, it’s no problem to add it now and do the testing there. I’m happy to integrate it if you can point me at the code.
Just sent it over to you Chris
Thanks Dave.
@dbadia @askant any hints to proper items configuration for this?
I did not try inclusion/exclusion yet (previously included successfully with a 3rd party software), I would rather see first if i’m able to send open/close commands to the controller and receive status updates…
Secure inclusion worked (or so it seems), but in generated node xml barrier operator command is not present:
<supportedCommandClasses> <entry> <commandClass>BASIC</commandClass> <basicCommandClass> <version>1</version> <instances>1</instances> <isGetSupported>true</isGetSupported> </basicCommandClass> </entry> <entry> <commandClass>NO_OPERATION</commandClass> <noOperationCommandClass> <version>1</version> <instances>1</instances> </noOperationCommandClass> </entry> <entry> <commandClass>MANUFACTURER_SPECIFIC</commandClass> <manufacturerSpecificCommandClass> <version>1</version> <instances>1</instances> </manufacturerSpecificCommandClass> </entry> <entry> <commandClass>LOCK</commandClass> <lockCommandClass> <version>1</version> <instances>1</instances> </lockCommandClass> </entry> </supportedCommandClasses> <securedCommandClasses/>
So if I use something like this:
Switch GDoor_Lock “Front door lock control” (Power) {zwave=“15:command=BARRIER_OPERATOR”}
I get an error:
22:48:26.713 WARN o.o.b.z.i.c.ZWaveConverterHandler[:414]- NODE 15: No command class found for item = GDoor_Lock. Class = barrier_operator(BARRIER_OPERATOR), endpoint = 0. Ignoring command.
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?