Z-Wave JS: Certification requirements for Door Lock CC not fulfilled

[AlCalzone]

The problem

(the mentioned operation types mean constant 0x01 and timed 0x02, V4+ adds additional ones)

I could not find any way to configure the operation type of a lock, so this will need to be added before certification.

---

Also setting the lock mode (Locked, Unlocked, and several timed modes) must be available to the user if supported by the lock:

What version of Home Assistant Core has the issue?

2023.1.7

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Z-Wave JS

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant]

Hey there @home-assistant/z-wave, mind taking a look at this issue as it has been labeled with an integration (zwave_js) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of zwave_js can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Change the title of the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign zwave_js Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

zwave_js documentation
zwave_js source
_{^{(message by IssueLinks)}}

[MartinHjelmare]

Do you have a diagnostic dump from a lock that supports the mentioned missing configuration items?

[AlCalzone]

Here's a dump of my Ultraloq which is v4. It supports some of the features mentioned above, but none of the extra lock modes:
Ultraloq

And here's my Yale lock, which is only v2 (so no additional operation modes), but it has a few of the extra lock modes:
Yale

[MartinHjelmare]

What values are expected to be exposed and controlled in the table above? My Danalock has six configuration command class values that controls eg, Twist Assist, Hold & Release, Block to Block, Auto Lock. These are exposed in the device configuration in Home Assistant.

The Ultralog dump doesn't contain any configuration command class values.

The Yale dump contains four configuration command class values.

[MartinHjelmare]

TODO list

• For locks with more than two door lock modes, we should expose a select entity. Take care to filter the timed modes and only show them if the lock is in timed mode. We should also map all the specific door lock modes to the two general entity states (secure*: locked / unsecure*: unlocked) in the lock entity.

  "commandClass": 98,
  "commandClassName": "Door Lock",
  "property": "currentMode",

• We should also add a select entity for lock operation type, constant or timed, or the other types in v4.

  "commandClass": 98,
  "commandClassName": "Door Lock",
  "property": "operationType",

• We should also add a number entity for the time of the timed mode.

  "commandClass": 98,
  "commandClassName": "Door Lock",
  "property": "lockTimeoutConfiguration",

• The four items at the end of the top table: Auto Lock, Hold & Release, Twist Assist (TA), Block to Block (BTB) seems to be sometimes exposed as configuration command class parameters, and sometimes Door Lock command class values. We need to expose them if they are Door Lock command class values.

  "commandClass": 98,
  "commandClassName": "Door Lock",
  "property": "autoRelockTime",

  "commandClass": 98,
  "commandClassName": "Door Lock",
  "property": "holdAndReleaseTime",

  "commandClass": 98,
  "commandClassName": "Door Lock",
  "property": "twistAssist",

  "commandClass": 98,
  "commandClassName": "Door Lock",
  "property": "blockToBlock",

• The inside, outside handles configuration, I'm not sure how to expose. This is what the dump looks like for one:

  {
      "endpoint": 0,
      "commandClass": 98,
      "commandClassName": "Door Lock",
      "property": "outsideHandlesCanOpenDoorConfiguration",
      "propertyName": "outsideHandlesCanOpenDoorConfiguration",
      "ccVersion": 4,
      "metadata": {
          "type": "any",
          "readable": true,
          "writeable": true,
          "label": "Which outside handles can open the door (configuration)"
      },
      "value": [
          true,
          false,
          false,
          false
      ]
  }

[AlCalzone]

My Danalock has six configuration command class values that controls eg, Twist Assist, Hold & Release, Block to Block, Auto Lock. These are exposed in the device configuration in Home Assistant.

We talked about this, but just to avoid any misunderstanding here, those are not standard and they aren't meant by this issue. You posted the correct ones in the comment above this one. The requirements I posted only apply if they are exposed via the Door Lock CC. We can safely ignore the Configuration CC values.

• The inside, outside handles configuration, I'm not sure how to expose.

If I understand this table correctly, we may not have to expose this to the user

[AlCalzone]

FWIW, more complete information on the value metadata for each value can be found here.

[home-assistant]

ultraloq documentation
ultraloq source

[b-uwe]

ultraloq documentation ultraloq source

I'm sorry for the confusion, I mixed this up with zwave-js/node-zwave-js#5445 (comment)

[raman325]

From a conversation in Discord, these properties can't be separate controllable entities because they have to be set together. Instead the best way to address this is to add a service to handle this, using the invoke_cc_api command to set them together, and to create sensors for the current state.

[marcelveldt]

Kamino closed and cloned this issue to zwave-js/certification-backlog