Zwave door locks

[georgeinva2004]

I'm not sure where to go with this. I've tried two different ZWave door locks: Yale and Kwikset. Both pair, but I can't seem to get them to respond to the lock/unlock commands. The CMDResult Success property is set to true, but I'm not getting an obvious error back from the device. I'm wondering if it's my lack of understanding of how security works with ZWave. I've paired both locks by enabling inclusion mode and by doing a manual inclusion on each device (e.g. pressing the inclusion button or pressing the key sequences on the keypad to add to the network). I didn't use a QR code nor did I manually provide the PIN (only the Kwikset had that option). Both devices seem to pair correctly and I'm able to get the supported Command Classes and ValueIDs. Am I doing something wrong from a security perspective? Any ideas would be appreciated.

[marcus-j-davies]

Hi @georgeinva2004, door locks will not operate on < S2 I Believe - its a set standard, so ..

• Are they paired as S2 - they should be (It's a Spec compliant thing I think)
• Can you send me what it is you are sending?
• Are the door locks FLiRS certified - for door locks they usually are

Zwave JS supports door locks - so it may be some configuration/Value set that is standing in the way

[marcus-j-davies]

@AlCalzone - is that right. Security devices (especially locks) don't play nice if < S2?
I seem to remember I had a Security PIN pad that paired on S0, but didn't play nice, until paired as S2

[georgeinva2004]

Thanks for the response. Focusing on the Yale lock for now.

ZWaveNode.GetHighestSecurityClass() returns an "Unsecured". So, I assume it's not S2. There's no PIN or QR Code provided with the lock, so I just did a standard pairing hoping that between the AEOTEC 700 controller, ZWave-JS, and the lock, S2 handshakes just "work" (again, showing my ignorance on how S2 is supposed to work).

Without getting into a ton of details on my application, I look for the command class "Door Lock", and get the associated valueIDs for the properties I'm interested in. For the Yale, they are the targetMode and currentMode properties. Each of those is defined as a "number" in the metadata with States ranging from 0 to 255. The "0" state is defined as "unsecured" and the "255" state is defined as "secured".

My code sends a 0 or 255 depending on the desired state using the ZWaveNode.SetValue method to the ValueID associated with the targetMode property. I receive a "true" in the CMDResult.Success property and a "State" of 254 (which means unknown according to the metadata).

The debugger shows the following log entry after I send the command.

{"type":"result","success":true,"messageId":"654a0137-f40f-414b-92cc-682573186489","result":{"result":{"status":254}}}

I don't see anything on the packaging about FLiRS certification.

Is there something I need to configure in the driver/controller to enable S2 security. Please forgive me if there is an obvious answer.

Thanks,

-John

[marcus-j-davies]

@georgeinva2004

(again, showing my ignorance on how S2 is supposed to work).

The S2 enroll methods includes various levels of S2 - in general:

• Authenticated - Requires a PIN
• AccessControl - Requires a PIN (I think)
• Unauthenticated - Does Not

As for a QR Code - This is not always needed, it's not a requirement for S2, its just a way to speed up things if supported by the device.

Try this,
Ensure you have all the callbacks registered when you start inclusion.
i.e in the options.

• grantSecurityClasses
• validateDSKAndEnterPIN

During enrol, ensure you use the Default or S2 Strategy - you should in theory get a prompt from - grantSecurityClasses

you send back the array of S2 methods you wish to use (favour these 3) - there are others (what is supported will be included in the callback)

• Authenticated - Requires a PIN
• AccessControl - Requires a PIN (I think)
• Unauthenticated - Does Not (if supported, and you don't have a A PIN then use this)

For methods that require a PIN the validateDSKAndEnterPIN will get triggered shortly after (it is here you need the PIN from the material or the BOX/Manuals

[marcus-j-davies]

Side Note:

The PIN can be referred to as a "DSK" - maybe some underlined 5 digit PIN code (sometime with a larger number)

[georgeinva2004]

This is a great description. Thank-you.

Here's what I have. I'm getting a "false" returned from BeginInclusion(options). I'm assuming that there's a problem. When I change strategy to "Insecure" I get a "true" returned from BeginInclusion(options).

//options.forceSecurity = true;
options.forceSecurity = false;  // Tried both true and false for forceSecurity.  Both yield a false response in BeginInclusion()
//options.strategy = Enums.InclusionStrategy.Insecure;
options.strategy = Enums.InclusionStrategy.Default;
InclusionUserCallbacks callbacks = new InclusionUserCallbacks();
options.userCallbacks = callbacks;
options.userCallbacks.validateDSKAndEnterPIN = HandleDSKandPIN;
options.userCallbacks.grantSecurityClasses = HandleGrantSecurity;
options.userCallbacks.abort = HandleAbort;

bool success= await _controller.BeginInclusion(options);

[georgeinva2004]

Good advice. Thank-you. How will devices already paired be handled when I switch to better security?

[marcus-j-davies]

Security is decided during pair time - just because you add a set of keys, wouldn't suddenly invalidate old devices that does not have security. as long as you use.

• Default
• forceSecurity:false

For new parings (and your keys are set, and callbacks registered) you golden.

[marcus-j-davies]

if a device supports S0 BUT is not critical to secure, ZWave JS will not secure them (unless forceSecurity:true)
if a device supports S2, will use S2 based on

• Default
• forceSecurity:false

EDIT
This only applies during Pair Time

[georgeinva2004]

Success!!!! Thanks for all your help! After going to a Christmas party last night, a good night sleep, and a clear head, got it working this morning thanks to your guidance!
I appreciate all the help.

[marcus-j-davies]

Excellent! Good to hear.

The zwave spec says security devices should not attempt to communicate if not secured - whether or not manufacturers follow that guidance is another storey, but it seems your locks play by the rules.

Using the Default strategy and false on force security - you will usually get successful parings, and ones that adhere to spec

[georgeinva2004]

Mostly. It does allow visibility to a small number of command classes. However, once we got security working, many more showed up along with over 500 valueIDs. Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Marcus Davies ***@***.***> Sent: Saturday, December 16, 2023 10:58:09 AM To: zwave-js/ZWaveJS.NET ***@***.***> Cc: John George ***@***.***>; Mention ***@***.***> Subject: Re: [zwave-js/ZWaveJS.NET] Zwave door locks (Discussion #56) Excellent! Good to hear. The zwave spec says security devices should not attempt to communicate if not secured - whether or not manufacturers follow that guidance is another storey, but it seems your locks play by the rules. — Reply to this email directly, view it on GitHub<#56 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABJAZ4NCSXTD6CXCIJ5WUD3YJXAJDAVCNFSM6AAAAABAW3PSXOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQNZRGU4DG>. You are receiving this because you were mentioned.Message ID: ***@***.***>