[feat] Support for Ultraloq zwave locks

mbbush commented 2 years ago

Is your feature request related to a problem? Please describe. When I connect my ultraloq u-bolt pro zwave lock to zwavejs, it shows up as an unknown device from an unknown manufacturer. The interview process doesn't result in a working device, probably because this is the first zwave device this manufacturer has made and it doesn't seem to completely follow the spec.

https://products.z-wavealliance.org/regions/2/categories/6/products?company=810

Describe the solution you'd like A working driver. I'd be happy to write some/all of it, although I won't have time to work on it until January at the earliest.

Describe alternatives you've considered

Additional context

Manufacturer specific report and device specific report received from the u-bolt pro zwave: 72 05 04 52 00 04 00 01 72 07 01 28 0C 43 14 FF FE 53 4C E6

I documented a few of the quirks of this device here https://community.hubitat.com/t/ultraloq-u-bolt-zwave-700-lock/72810/26

mbbush commented 2 years ago

The NIF advertises support for the following classes/versions: Association v2 Association Group Info v3 Basic v2 Battery v1 Device Reset Locally v1 Door Lock v4 (but it doesn't respond to the Door Lock Capabilities Get which was added in v4, so maybe it only actually supports v3?) Firmware Update Meta Data V5 Indicator v3 Manufacturer Specific v2 Multi Channel Association V3 Powerlevel v1 Security 0 v1 Security 2 v1 Supervision v1 Transport Service v2 User Code v1 Version v3 Zwave Plus Info v2

mbbush commented 2 years ago

I'm using my lock in "standalone mode", because I don't trust the manufacturer's cloud. Despite the instructions that say you must first activate it in the app to connect to a zwave hub, I was able to pair it using smartstart in standalone mode.

I've found some oddities in the implementation of the user code class.

Here's what I've found: The lock responds to USER CODE GET, and USERS NUMBER GET with appropriate REPORT commands. The lock responds to USER CODE SET commands by updating its state (see below for details). The lock ignores all other _GET commands in the USER_CODE class. I didn't try the other SET commands.

It returns 0x31 in the USERS_NUMBER_REPORT

Codes and fingerprints added locally on the lock are assigned to sequential user identifiers starting with 1. They can be read using the USER_CODE_GET command. For codes, this returns a USER_CODE_REPORT message containing the ascii-encoded numeric code in the payload, with status 00 (available), which is definitely NOT ok according to the spec. For fingerprints, it also returns a USER CODE REPORT with status 00, and a 15-bypte payload which starts with 8 ascii-encoded 0-10 digits, followed by 7 zeros. This payload is identical for every fingerprint.

User code get for code 00 returns a user code report with content 00 FE.

User code get for empty slots returns a user code report with status 0 and a code of 00 00 00 00

I'll edit this to add more when I get a chance.

AlCalzone commented 2 years ago

In general we don't have device specific drivers. Z-Wave JS tries to stay as close to the specifications as possible. There are some quirks we work around but not to the extent other drivers do.

You mentioned that the device isn't working properly. Please make a driver log, loglevel debug or silly and attach it here as a file.

While making that log, re-interview the device and let it finish, then operate the device in a way that outlines what you mean by "Not working".

zwave-js-assistant[bot] commented 2 years ago

This issue has not seen any recent activity and was marked as "stale 💤". Closing for housekeeping purposes... 🧹

Feel free to reopen if the issue persists.

mbbush commented 2 years ago

I'm back from vacation, and starting to look at this again. I watched your bit in the State of the Open Home Video and liked what you said about your philosophy of sticking to the zwave spec as a means of trying to encourage manufacturers to "do it the right way". I don't know if you or I will be able to get any positive engagement from ultraloq, but I'm willing to give it a try.

Some of my previous posts in this thread contained incorrect information about supported zwave command class versions, which I've edited to correct. Next I'll start working on creating a silly driver log.

I'm still just getting started with zwavejs. Just so I understand a little more about how zwavejs works, is the idea that you simultaneously attempt to have a complete library of device files, and also software that can "figure out" what is supposed to happen via an interview when there is no such device file? I'd like to be able to contribute constructively to this community project, and honestly I rank that as a higher priority than getting my own lock working quickly. So maybe the best path forward here is figure out if there are any changes that are worth making to improve the "automatic" support for this device, and then second I can work on writing a device file?

BTW: I'm not sure if having a log level named silly is a normal javascript thing or something you made up (the far more boring/sober name I'm accustomed to from the enterprise java world is TRACE), but I like it. It reminds me of android's log.wtf method, although obviously at the opposite end of the spectrum.

mbbush commented 2 years ago

Ok, I think I know why this isn't working at all for me.

I started by pairing the device to a zooz 700 series usb stick controller, using the silicon labs SimplicityStudio software. I then unplugged the usb stick and moved it to the computer running zwaveJS. I copied the zwave security keys from SimplicityStudio into zwaveJS, but it seems to be running into problems related to security.

When I look at my zwavejs control panel, I see the node id, but it shows that it is not included securely.

When I do things on the physical lock that cause it to send (secure) zwave messages, I get logs like this:

zwavejs2mqtt    | 12:14:26.301 SERIAL « 0x011e00a8000102159f032500a1363c6689a2c61d4b5e7ddccd81284a5000adbc  (32 bytes)
zwavejs2mqtt    | 12:14:26.310 DRIVER   Dropping message with invalid payload
zwavejs2mqtt    | 12:14:26.312 DRIVER « [Node 002] [REQ] [BridgeApplicationCommand]
zwavejs2mqtt    |                       │ RSSI: -83 dBm
zwavejs2mqtt    |                       └─[Security2CCMessageEncapsulation] [INVALID]
zwavejs2mqtt    |                           error: No security class granted
zwavejs2mqtt    | 12:14:26.313 SERIAL » [ACK]

AlCalzone commented 2 years ago

Just so I understand a little more about how zwavejs works, is the idea that you simultaneously attempt to have a complete library of device files, and also software that can "figure out" what is supposed to happen via an interview when there is no such device file?

Z-Wave works by standardizing behavior in the form of Command Classes (CCs), which also offer means to discover what specifics of that CC a device supports. Z-Wave JS tries to do this (and rely on it) as much as possible, as opposed to OpenZWave which defines a lot in the config files. We only define what we cannot query (or where the queried information is often subpar), i.e. Association groups and Config params. For some devices we work around common issues by enabling compat flags.

I'm not sure if having a log level named silly is a normal javascript thing

These loglevels are aligned with how npm calls them: https://github.com/winstonjs/winston#logging-levels, which is also the default for the logging library we use. It's quite fitting though, debug allows for debugging and silly is meant for silly amounts of logging output.

No security class granted

That is likely because the security interview wasn't done yet. I'd need to see a more complete log of the interview to tell what's happening there. Normally the driver figures out which keys the node knows.

mbbush commented 2 years ago

I found this in the earlier logs.

2022-01-03T20:08:23.447Z CNTRLR   [Node 002] Beginning interview - last completed stage: None
2022-01-03T20:08:23.447Z CNTRLR   [Node 002] new node, doing a full interview...
2022-01-03T20:08:23.448Z CNTRLR » [Node 002] querying protocol info...
2022-01-03T20:08:23.453Z SERIAL » 0x0104004102b8                                                       (6 bytes)
2022-01-03T20:08:23.453Z DRIVER » [REQ] [GetNodeProtocolInfo]
                                    payload: 0x02
2022-01-03T20:08:23.458Z SERIAL « [ACK]                                                                   (0x06)
2022-01-03T20:08:23.459Z SERIAL « 0x010a014153dc01044001007e                                          (12 bytes)
2022-01-03T20:08:23.460Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:08:23.460Z DRIVER « [RES] [GetNodeProtocolInfo]
                                    payload: 0x53dc0104400100
2022-01-03T20:08:23.464Z CNTRLR « [Node 002] received response for protocol info:
                                  basic device class:    Routing Slave
                                  generic device class:  Entry Control
                                  specific device class: Door Lock
                                  node type:             Routing End Node
                                  is always listening:   false
                                  is frequent listening: 1000ms
                                  can route messages:    true
                                  supports security:     false
                                  supports beaming:      true
                                  maximum data rate:     100000 kbps
                                  protocol version:      3
2022-01-03T20:08:23.465Z CNTRLR   [Node 002] Interview stage completed: ProtocolInfo
2022-01-03T20:08:23.465Z CNTRLR » [Node 002] pinging the node...
2022-01-03T20:08:23.470Z SERIAL » 0x010d00a9010201002500000000027e                                    (15 bytes)
2022-01-03T20:08:23.470Z DRIVER » [Node 002] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ route:            0, 0, 0, 0
                                  │ callback id:      2
                                  └─[NoOperationCC]
2022-01-03T20:08:23.476Z SERIAL « [ACK]                                                                   (0x06)
2022-01-03T20:08:23.477Z SERIAL « 0x010401a90152                                                       (6 bytes)
2022-01-03T20:08:23.477Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:08:23.478Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2022-01-03T20:08:25.739Z SERIAL « 0x011d00a9020000de00ae7f7f7f7f01010100000000420200007f7f7f7f7f07    (31 bytes)
2022-01-03T20:08:25.741Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:08:25.743Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            2
                                    transmit status:        OK, took 2220 ms
                                    routing attempts:       2
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    ACK RSSI:               -82 dBm
                                    ACK channel no.:        1
                                    TX channel no.:         1
                                    beam:                   1000 ms
2022-01-03T20:08:25.751Z CNTRLR   [Node 002] The node is now alive.
2022-01-03T20:08:25.751Z CNTRLR   [Node 002] Beginning interview - last completed stage: ProtocolInfo
2022-01-03T20:08:25.752Z CNTRLR » [Node 002] querying node info...
2022-01-03T20:08:25.757Z CNTRLR « [Node 002] ping successful
2022-01-03T20:08:25.757Z CNTRLR » [Node 002] querying node info...
2022-01-03T20:08:25.761Z SERIAL » 0x010400600299                                                       (6 bytes)
2022-01-03T20:08:25.761Z DRIVER » [Node 002] [REQ] [RequestNodeInfo]
                                    payload: 0x02
2022-01-03T20:08:25.766Z SERIAL « [ACK]                                                                   (0x06)
2022-01-03T20:08:25.767Z SERIAL « 0x01040160019b                                                       (6 bytes)
2022-01-03T20:08:25.768Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:08:25.768Z DRIVER « [RES] [RequestNodeInfo]
                                    payload: 0x01
2022-01-03T20:09:30.781Z CNTRLR   [Node 002] Interview attempt 2/5 failed, retrying in 10000 ms...
2022-01-03T20:09:30.784Z SERIAL » 0x010400600299                                                       (6 bytes)
2022-01-03T20:09:30.784Z DRIVER » [Node 002] [REQ] [RequestNodeInfo]
                                    payload: 0x02
2022-01-03T20:09:30.789Z SERIAL « [ACK]                                                                   (0x06)
2022-01-03T20:09:30.790Z SERIAL « 0x01040160019b                                                       (6 bytes)
2022-01-03T20:09:30.791Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:09:30.791Z DRIVER « [RES] [RequestNodeInfo]
                                    payload: 0x01
2022-01-03T20:09:32.119Z SERIAL « 0x010e00498402080440015e55989f6c13                                  (16 bytes)
2022-01-03T20:09:32.122Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:09:32.124Z DRIVER « [Node 002] [REQ] [ApplicationUpdateRequest]
                                    payload: 0x02080440015e55989f6c
2022-01-03T20:09:32.130Z CNTRLR « [Node 002] node info received
                                  supported CCs:
                                  · Z-Wave Plus Info
                                  · Transport Service
                                  · Security
                                  · Security 2
                                  · Supervision
                                  controlled CCs:
2022-01-03T20:09:32.132Z CNTRLR   [Node 002] Interview stage completed: NodeInfo
2022-01-03T20:09:32.135Z CNTRLR   [Node 002] Interviewing Z-Wave Plus Info...
2022-01-03T20:09:32.135Z CNTRLR » [Node 002] querying Z-Wave+ information...
2022-01-03T20:09:32.150Z SERIAL » 0x010e00a90102025e0125000000000320                                  (16 bytes)
2022-01-03T20:09:32.150Z DRIVER » [Node 002] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ route:            0, 0, 0, 0
                                  │ callback id:      3
                                  └─[ZWavePlusCCGet]
2022-01-03T20:09:32.156Z SERIAL « [ACK]                                                                   (0x06)
2022-01-03T20:09:32.157Z SERIAL « 0x010401a90152                                                       (6 bytes)
2022-01-03T20:09:32.157Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:09:32.158Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2022-01-03T20:09:33.467Z SERIAL « 0x011d00a90300008000af7f7f7f7f01010300000000420100007f7f7f7f7f58    (31 bytes)
2022-01-03T20:09:33.469Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:09:33.470Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            3
                                    transmit status:        OK, took 1280 ms
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    ACK RSSI:               -81 dBm
                                    ACK channel no.:        1
                                    TX channel no.:         1
                                    beam:                   1000 ms
2022-01-03T20:09:33.593Z SERIAL « 0x011200a8000102095e020207000300030000aeb8                          (20 bytes)
2022-01-03T20:09:33.598Z CNTRLR   [Node 002] [+] [Z-Wave Plus Info] zwavePlusVersion: 2  [Endpoint 0] [internal]
2022-01-03T20:09:33.599Z CNTRLR   [Node 002] [+] [Z-Wave Plus Info] nodeType: 0          [Endpoint 0] [internal]
2022-01-03T20:09:33.599Z CNTRLR   [Node 002] [+] [Z-Wave Plus Info] roleType: 7          [Endpoint 0] [internal]
2022-01-03T20:09:33.600Z CNTRLR   [Node 002] [+] [Z-Wave Plus Info] installerIcon: 768   [Endpoint 0] [internal]
2022-01-03T20:09:33.601Z CNTRLR   [Node 002] [+] [Z-Wave Plus Info] userIcon: 768        [Endpoint 0] [internal]
2022-01-03T20:09:33.601Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:09:33.603Z DRIVER « [Node 002] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -82 dBm
                                  └─[ZWavePlusCCReport]
                                      version:      2
                                      node type:    Node
                                      role type:    SleepingListeningSlave
                                      icon (mgmt.): 0x0300
                                      icon (user):  0x0300
2022-01-03T20:09:33.607Z CNTRLR « [Node 002] received response for Z-Wave+ information:
                                  Z-Wave+ version: 2
                                  role type:       SleepingListeningSlave
                                  node type:       Node
                                  installer icon:  0x0300
                                  user icon:       0x0300
2022-01-03T20:09:33.608Z CNTRLR   [Node 002] [+] [Z-Wave Plus Info] interviewComplete: t [Endpoint 0] [internal]
                                  rue
2022-01-03T20:09:33.610Z CNTRLR   [Node 002] Interviewing Basic...
2022-01-03T20:09:33.610Z CNTRLR » [Node 002] querying Basic CC state...
2022-01-03T20:09:33.626Z SERIAL » 0x010e00a901020220022500000000045a                                  (16 bytes)
2022-01-03T20:09:33.626Z DRIVER » [Node 002] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ route:            0, 0, 0, 0
                                  │ callback id:      4
                                  └─[BasicCCGet]
2022-01-03T20:09:33.632Z SERIAL « [ACK]                                                                   (0x06)
2022-01-03T20:09:33.633Z SERIAL « 0x010401a90152                                                       (6 bytes)
2022-01-03T20:09:33.633Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:09:33.634Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2022-01-03T20:09:33.678Z SERIAL « 0x011d00a90400000400b07f7f7f7f01010300000000020100007f7f7f7f7f84    (31 bytes)
2022-01-03T20:09:33.678Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:09:33.679Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            4
                                    transmit status:        OK, took 40 ms
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    ACK RSSI:               -80 dBm
                                    ACK channel no.:        1
                                    TX channel no.:         1
2022-01-03T20:09:40.786Z CNTRLR   [Node 002] Beginning interview - last completed stage: NodeInfo
2022-01-03T20:09:40.792Z CNTRLR   [Node 002] Interviewing Basic...
2022-01-03T20:09:40.792Z CNTRLR » [Node 002] querying Basic CC state...
2022-01-03T20:09:43.690Z CNTRLR   [Node 002] Timed out while waiting for a response from the node (ZW0201)
2022-01-03T20:09:43.691Z CNTRLR   [Node 002] No response to Basic Get command, assuming the node does not suppor
                                  t Basic CC...
2022-01-03T20:09:43.692Z CNTRLR   [Node 002] [+] [Basic] interviewComplete: true         [Endpoint 0] [internal]
2022-01-03T20:09:43.695Z SERIAL » 0x010e00a901020220022500000000055b                                  (16 bytes)
2022-01-03T20:09:43.696Z DRIVER » [Node 002] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ route:            0, 0, 0, 0
                                  │ callback id:      5
                                  └─[BasicCCGet]
2022-01-03T20:09:43.697Z CNTRLR   [Node 002] Interviewing Lock...
2022-01-03T20:09:43.698Z CNTRLR » [Node 002] requesting current lock state...
2022-01-03T20:09:43.702Z SERIAL « [ACK]                                                                   (0x06)
2022-01-03T20:09:43.703Z SERIAL « 0x010401a90152                                                       (6 bytes)
2022-01-03T20:09:43.703Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:09:43.703Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2022-01-03T20:09:53.992Z SERIAL « 0x011d00a9050103f4007f7f7f7f7f00010600000000420900007f7f7f7f7ff4    (31 bytes)
2022-01-03T20:09:53.993Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:09:53.995Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            5
                                    transmit status:        NoAck, took 10120 ms
                                    routing attempts:       9
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    TX channel no.:         1
                                    beam:                   1000 ms
2022-01-03T20:09:54.000Z CNTRLR   [Node 002] did not respond after 1/3 attempts. Scheduling next try in 500 ms.
2022-01-03T20:09:54.515Z SERIAL » 0x010e00a901020220022500000000055b                                  (16 bytes)
2022-01-03T20:09:54.517Z DRIVER » [Node 002] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ route:            0, 0, 0, 0
                                  │ callback id:      5
                                  └─[BasicCCGet]
2022-01-03T20:09:54.523Z SERIAL « [ACK]                                                                   (0x06)
2022-01-03T20:09:54.526Z SERIAL « 0x010401a90152                                                       (6 bytes)
2022-01-03T20:09:54.527Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:09:54.527Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2022-01-03T20:10:04.810Z SERIAL « 0x011d00a9050103f3007f7f7f7f7f00010600000000420900007f7f7f7f7ff3    (31 bytes)
2022-01-03T20:10:04.812Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:10:04.813Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            5
                                    transmit status:        NoAck, took 10110 ms
                                    routing attempts:       9
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    TX channel no.:         1
                                    beam:                   1000 ms
2022-01-03T20:10:04.819Z CNTRLR   [Node 002] did not respond after 2/3 attempts. Scheduling next try in 500 ms.
2022-01-03T20:10:05.327Z SERIAL » 0x010e00a901020220022500000000055b                                  (16 bytes)
2022-01-03T20:10:05.328Z DRIVER » [Node 002] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ route:            0, 0, 0, 0
                                  │ callback id:      5
                                  └─[BasicCCGet]
2022-01-03T20:10:05.335Z SERIAL « [ACK]                                                                   (0x06)
2022-01-03T20:10:05.336Z SERIAL « 0x010401a90152                                                       (6 bytes)
2022-01-03T20:10:05.336Z SERIAL » [ACK]                                                                   (0x06)
2022-01-03T20:10:05.337Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true

It looks like the problem is that the device is (incorrectly) advertising that it doesn't support security. Here's what I see in the node information in the SI labs PC Controller software:

AlCalzone commented 2 years ago

supports security: false

is misleading, disregard that.

Support for secure CCs is advertised:

2022-01-03T20:09:32.130Z CNTRLR « [Node 002] node info received
                                  supported CCs:
                                  · Z-Wave Plus Info
                                  · Transport Service
                                  · Security
                                  · Security 2
                                  · Supervision
                                  controlled CCs:

but the interview isn't done securely. Either the keys didn't get applied, or the wrong security info is already cached. If it is the latter, its probably easiest to remove and re-include the device.

mbbush commented 2 years ago

I'd rather not have to exclude and re-include the lock, as I don't want it to reset the fingerprints I've already set up (re-enrolling mine is no big deal, but my other family members are less enthusiastic). Is there another way to tell what security info is cached, or reset it?

The only two nodes on the network are the controller and the door lock.

AlCalzone commented 2 years ago

or reset it?

If you're using zwavejs2mqtt, shut it down. In the store directory, you'll find a <homeid>.json file you can open with a text editor. Find the section that looks like this for node 2: grafik delete the lines, and save.

Start z2m again and re-interview the device.

mbbush commented 2 years ago

Removing the "securityClasses" element from the <homeid>.json file did the trick. It still shows as unknown manufacturer and unknown product, but it shows actual codes now, not 0x0000. This is expected, as there's no device file.

I can successfully manage the User Code command class, at least subject to the limitations of the lock itself. It treats user status 1 (enabled) and 2 (disabled) as both enabled, but I can disable a code by setting it to status 0 (available). And it shows the fingerprint slots as populated with a specific code, with status available.

So I guess all that's needed is to write a basic device file that has the product name and id? I think I'll also write to the manufacturer encouraging them to bring their zwave implementation up a notch, although I don't have high hopes on that.

mbbush commented 2 years ago

The only other thing that seems less than ideal is that zwavejs seems to think that this device supports both the "Door Lock" (0x62) and "Lock" (0x76) command classes. I'm not sure why it thinks that the deprecated "Lock" class is supported. It isn't advertised as supported, and the ground truth is that the device ignores both get and set commands of this class. Unfortunately, "Lock" also shows up first in the z2m ui, above "Door Lock", which initially led me to believe that I couldn't control the lock.

AlCalzone commented 2 years ago

That might be required by the device class. Unfortunately, there is no versioning for these kinds of things on the Z-Wave specs, so we might have to disable the Lock CC through a compat flag.

Can you post another log of a re-interview, so I can double check?

mbbush commented 2 years ago

Sure. I'm redacting secrets from it and then will post. The only explanation I can think of is that zwavejs adds it based on the device class, (which is "deviceClass": {"basic": 4,"generic": 64,"specific": 1}) but I don't see anything in the zwave docs that indicates that the Lock command class must be supported for either GENERIC_TYPE_ENTRY_CONTROL or SPECIFIC_TYPE_DOOR_LOCK. Perhaps I'm looking in the wrong place.

FWIW, the Lock command class carries this boxed warning in the SDS13781 zwave documentation:

THIS COMMAND CLASS HAS BEEN DEPRECATED

A device MAY implement this command class, but it is RECOMMENDED that new implementations use the Door Lock Command Class. If implementing this command class, it is RECOMMENDED that the Door Lock Command Class is also implemented.

mbbush commented 2 years ago

log.redacted.txt

kpine commented 2 years ago

Lock CC was required for Door Lock device types in Z-Wave (Classic). Z-Wave Plus does not re-define the Door Lock DT, so it's a carry-over from the Classic definition.

However, Z-Wave Plus V2 removes the requirement for Lock CC. From the logs this lock is also Plus V2.

AlCalzone commented 2 years ago

However, Z-Wave Plus V2 removes the requirement for Lock CC. From the logs this lock is also Plus V2.

Good to know, I'll have to make the device class requirements conditional it seems

zwave-js-assistant[bot] commented 2 years ago

This issue has not seen any recent activity and was marked as "stale 💤". Closing for housekeeping purposes... 🧹

Feel free to reopen if the issue persists.

Roundaround commented 2 years ago

What's the latest status on this? No device config yet but it (mostly) works via interview?

AlCalzone commented 2 years ago

What's the latest status on this? No device config yet but it (mostly) works via interview?

There is a device config, but just for the labels - config parameters don't seem to exist. The lock should work normally, but you have to ignore the Lock CC.

mbbush commented 2 years ago

I can confirm that there are no config parameters implemented on the device.

AlCalzone commented 2 years ago

I just found this video about the non-"Pro" version of this lock: https://youtu.be/TDHFHj9tOCg Might be something to keep in mind when thinking of buying this 😬

guniv commented 2 years ago

I hate to bump an old-ish issue but this is the only substantial discussion on the z-wave implementation of this lock. Is there any chance this lock will get better supported by zwavejs? I would really appreciate the ability to see when user codes are used and even set them. In Home Assistant the lock also adds a door sensor entity that does not update and is permanently set to open for me. I'm honestly a novice at this so I'm not quite sure how much of this could be Ultraloq's fault, and I do see the comment above that they may not be following the standard very well.

AlCalzone commented 2 years ago

In Home Assistant the lock also adds a door sensor entity that does not update and is permanently set to open for me.

This is probably the Lock CC value I mentioned here https://github.com/zwave-js/node-zwave-js/issues/3935#issuecomment-1021937543.

I would really appreciate the ability to see when user codes are used and even set them.

According to https://github.com/zwave-js/node-zwave-js/issues/3935#issuecomment-997304784 I would assume that you're able to set user codes - you probably won't get any feedback that they are configured though because the lock responds with a status Available (i.e. not set). Not sure what the lock sends when you use a user code, but I'd guess its the same as for most other locks, where a notification event is sent: https://www.home-assistant.io/integrations/zwave_js/#node-events-notification

guniv commented 2 years ago

This is probably the Lock CC value I mentioned here #3935 (comment).

Is there any way for me to fix this, then? At this point I assume it is an issue with the lock and Ultraloq would have to fix.

EDIT: Actually, thinking about it again... the Lock CC would seem to me to be more likely the reason that two lock entities are added to Home Assistant. One of them never worked correctly and eventually just became completely unavailable, so I disabled it in Home Assistant. The other one works fine.

According to #3935 (comment) I would assume that you're able to set user codes - you probably won't get any feedback that they are configured though because the lock responds with a status Available (i.e. not set). Not sure what the lock sends when you use a user code, but I'd guess its the same as for most other locks, where a notification event is sent: https://www.home-assistant.io/integrations/zwave_js/#node-events-notification

So I tested and was surprised to see that sending a door code to the lock did indeed work. I still, however, can find no way to see when a user code is used. Listening to zwave_js_notification or zwave_js_value_notification doesn't produce anything at all when I lock or unlock. Even listening to ALL events in Home Assistant (by putting * in the "listen to events" field) has nothing come up beyond the status of the lock entity changing from locked to unlocked and so on, as far as I can tell. I wanted to make sure there wasn't some other event it was pointed at for some reason.

Thanks for your response!

AlCalzone commented 2 years ago

EDIT: Actually, thinking about it again... the Lock CC would seem to me to be more likely the reason that two lock entities are added to Home Assistant. One of them never worked correctly and eventually just became completely unavailable, so I disabled it in Home Assistant. The other one works fine.

Thats what I mean. Ignore this entity and only use the one corresponding to the Door Lock CC.

I still, however, can find no way to see when a user code is used

You're going to need to look at driver logs then to see if there is actually anything being sent by the lock.

guniv commented 2 years ago

Thats what I mean. Ignore this entity and only use the one corresponding to the Door Lock CC.

So to be clear, there is both a 2nd lock entity and a door sensor entity. The door sensor entity is always set to "Open." Here is a screenshot of all of the entities created by the device, for clarity.

You're going to need to look at driver logs then to see if there is actually anything being sent by the lock.

I watched the logs as I put in three codes: one I added via Z-Wave JS, one I created in their own app, and the last was using the fingerprint sensor. I THINK this log encompasses that including me locking the door between unlocks.

2022-04-05T14:45:25.575Z SERIAL « 0x011b0004000c159f03af00b822a2edcb0917cd51fda50110fa538dab90        (29 bytes)
2022-04-05T14:45:25.577Z CNTRLR   [Node 012] [~] [Door Lock] currentMode: 255 => 0                  [Endpoint 0]
2022-04-05T14:45:25.578Z CNTRLR   [Node 012] [~] [Door Lock] targetMode: 255 => 0                   [Endpoint 0]
2022-04-05T14:45:25.580Z CNTRLR   [Node 012] [~] [Door Lock] duration: {"value":0,"unit":"seconds"} [Endpoint 0]
                                   => {"value":0,"unit":"seconds"}
2022-04-05T14:45:25.581Z CNTRLR   [Node 012] [~] [Door Lock] outsideHandlesCanOpenDoor: false,false [Endpoint 0]
                                  ,false,false => true,false,false,false
2022-04-05T14:45:25.582Z CNTRLR   [Node 012] [~] [Door Lock] insideHandlesCanOpenDoor: false,false, [Endpoint 0]
                                  false,false => false,false,false,false
2022-04-05T14:45:25.583Z CNTRLR   [Node 012] [~] [Door Lock] latchStatus: "open" => "open"          [Endpoint 0]
2022-04-05T14:45:25.584Z CNTRLR   [Node 012] [~] [Door Lock] boltStatus: "locked" => "unlocked"     [Endpoint 0]
2022-04-05T14:45:25.585Z CNTRLR   [Node 012] [~] [Door Lock] doorStatus: "open" => "open"           [Endpoint 0]
2022-04-05T14:45:25.586Z SERIAL » [ACK]                                                                   (0x06)
2022-04-05T14:45:25.588Z DRIVER « [Node 012] [REQ] [ApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 175
                                    └─[DoorLockCCOperationReport]
                                        current mode:           Unsecured
                                        active outside handles: true, false, false, false
                                        active inside handles:  false, false, false, false
                                        latch status:           open
                                        bolt status:            unlocked
                                        door status:            open
                                        target mode:            Unsecured
                                        remaining duration:     0s
2022-04-05T14:45:27.822Z SERIAL « 0x01150004000c0f9f03b0007f405aefa51acfe8008a134a                    (23 bytes)
2022-04-05T14:45:27.825Z CNTRLR   [Node 012] [~] [Battery] level: 100 => 100                        [Endpoint 0]
2022-04-05T14:45:27.826Z CNTRLR   [Node 012] [~] [Battery] isLow: false => false                    [Endpoint 0]
2022-04-05T14:45:27.827Z SERIAL » [ACK]                                                                   (0x06)
2022-04-05T14:45:27.829Z DRIVER « [Node 012] [REQ] [ApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 176
                                    └─[BatteryCCReport]
                                        level:  100
                                        is low: false
2022-04-05T14:45:51.037Z SERIAL « 0x011b0004000c159f03b100e7b12ee302c68984aae7713611a59eb29286        (29 bytes)
2022-04-05T14:45:51.039Z CNTRLR   [Node 012] [~] [Door Lock] currentMode: 0 => 255                  [Endpoint 0]
2022-04-05T14:45:51.040Z CNTRLR   [Node 012] [~] [Door Lock] targetMode: 0 => 255                   [Endpoint 0]
2022-04-05T14:45:51.042Z CNTRLR   [Node 012] [~] [Door Lock] duration: {"value":0,"unit":"seconds"} [Endpoint 0]
                                   => {"value":0,"unit":"seconds"}
2022-04-05T14:45:51.045Z CNTRLR   [Node 012] [~] [Door Lock] outsideHandlesCanOpenDoor: true,false, [Endpoint 0]
                                  false,false => false,false,false,false
2022-04-05T14:45:51.047Z CNTRLR   [Node 012] [~] [Door Lock] insideHandlesCanOpenDoor: false,false, [Endpoint 0]
                                  false,false => false,false,false,false
2022-04-05T14:45:51.049Z CNTRLR   [Node 012] [~] [Door Lock] latchStatus: "open" => "open"          [Endpoint 0]
2022-04-05T14:45:51.050Z CNTRLR   [Node 012] [~] [Door Lock] boltStatus: "unlocked" => "locked"     [Endpoint 0]
2022-04-05T14:45:51.052Z CNTRLR   [Node 012] [~] [Door Lock] doorStatus: "open" => "open"           [Endpoint 0]
2022-04-05T14:45:51.054Z SERIAL » [ACK]                                                                   (0x06)
2022-04-05T14:45:51.056Z DRIVER « [Node 012] [REQ] [ApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 177
                                    └─[DoorLockCCOperationReport]
                                        current mode:           Secured
                                        active outside handles: false, false, false, false
                                        active inside handles:  false, false, false, false
                                        latch status:           open
                                        bolt status:            locked
                                        door status:            open
                                        target mode:            Secured
                                        remaining duration:     0s
2022-04-05T14:46:01.298Z SERIAL « 0x011b0004000c159f03b200c1f2122d30252aa2ad3520b653e601bbcb8c        (29 bytes)
2022-04-05T14:46:01.300Z CNTRLR   [Node 012] [~] [Door Lock] currentMode: 255 => 0                  [Endpoint 0]
2022-04-05T14:46:01.302Z CNTRLR   [Node 012] [~] [Door Lock] targetMode: 255 => 0                   [Endpoint 0]
2022-04-05T14:46:01.303Z CNTRLR   [Node 012] [~] [Door Lock] duration: {"value":0,"unit":"seconds"} [Endpoint 0]
                                   => {"value":0,"unit":"seconds"}
2022-04-05T14:46:01.304Z CNTRLR   [Node 012] [~] [Door Lock] outsideHandlesCanOpenDoor: false,false [Endpoint 0]
                                  ,false,false => true,false,false,false
2022-04-05T14:46:01.306Z CNTRLR   [Node 012] [~] [Door Lock] insideHandlesCanOpenDoor: false,false, [Endpoint 0]
                                  false,false => false,false,false,false
2022-04-05T14:46:01.307Z CNTRLR   [Node 012] [~] [Door Lock] latchStatus: "open" => "open"          [Endpoint 0]
2022-04-05T14:46:01.311Z CNTRLR   [Node 012] [~] [Door Lock] boltStatus: "locked" => "unlocked"     [Endpoint 0]
2022-04-05T14:46:01.312Z CNTRLR   [Node 012] [~] [Door Lock] doorStatus: "open" => "open"           [Endpoint 0]
2022-04-05T14:46:01.314Z SERIAL » [ACK]                                                                   (0x06)
2022-04-05T14:46:01.315Z DRIVER « [Node 012] [REQ] [ApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 178
                                    └─[DoorLockCCOperationReport]
                                        current mode:           Unsecured
                                        active outside handles: true, false, false, false
                                        active inside handles:  false, false, false, false
                                        latch status:           open
                                        bolt status:            unlocked
                                        door status:            open
                                        target mode:            Unsecured
                                        remaining duration:     0s
2022-04-05T14:46:22.400Z SERIAL « 0x01090004000603200100d6                                            (11 bytes)
2022-04-05T14:46:22.401Z SERIAL » [ACK]                                                                   (0x06)
2022-04-05T14:46:22.402Z DRIVER « [Node 006] [REQ] [ApplicationCommand]
                                  └─[BasicCCSet]
                                      target value: 0
2022-04-05T14:46:22.404Z CNTRLR   [Node 006] treating BasicCC::Set as a report
2022-04-05T14:46:22.405Z CNTRLR   [Node 006] [~] [Basic] currentValue: 255 => 0                     [Endpoint 0]
2022-04-05T14:46:22.702Z SERIAL « 0x010f00040006097105000000ff07000077                                (17 bytes)
2022-04-05T14:46:22.703Z CNTRLR   [Node 006] [~] [Notification] notificationMode: "push" [Endpoint 0] [internal]
                                   => "push"
2022-04-05T14:46:22.704Z SERIAL » [ACK]                                                                   (0x06)
2022-04-05T14:46:22.705Z DRIVER « [Node 006] [REQ] [ApplicationCommand]
                                  └─[NotificationCCReport]
                                      notification type:   7
                                      notification status: 255
                                      notification state:  idle
2022-04-05T14:46:22.707Z CNTRLR   [Node 006] [~] [Notification] Home Security[Motion sensor status] [Endpoint 0]
                                  : 8 => 0
2022-04-05T14:46:23.775Z SERIAL « 0x011b0004000c159f03b300910b034b4189781d7572ddd0e4a1e3042928        (29 bytes)
2022-04-05T14:46:23.777Z CNTRLR   [Node 012] [~] [Door Lock] currentMode: 0 => 255                  [Endpoint 0]
2022-04-05T14:46:23.779Z CNTRLR   [Node 012] [~] [Door Lock] targetMode: 0 => 255                   [Endpoint 0]
2022-04-05T14:46:23.780Z CNTRLR   [Node 012] [~] [Door Lock] duration: {"value":0,"unit":"seconds"} [Endpoint 0]
                                   => {"value":0,"unit":"seconds"}
2022-04-05T14:46:23.781Z CNTRLR   [Node 012] [~] [Door Lock] outsideHandlesCanOpenDoor: true,false, [Endpoint 0]
                                  false,false => false,false,false,false
2022-04-05T14:46:23.782Z CNTRLR   [Node 012] [~] [Door Lock] insideHandlesCanOpenDoor: false,false, [Endpoint 0]
                                  false,false => false,false,false,false
2022-04-05T14:46:23.783Z CNTRLR   [Node 012] [~] [Door Lock] latchStatus: "open" => "open"          [Endpoint 0]
2022-04-05T14:46:23.784Z CNTRLR   [Node 012] [~] [Door Lock] boltStatus: "unlocked" => "locked"     [Endpoint 0]
2022-04-05T14:46:23.785Z CNTRLR   [Node 012] [~] [Door Lock] doorStatus: "open" => "open"           [Endpoint 0]
2022-04-05T14:46:23.786Z SERIAL » [ACK]                                                                   (0x06)
2022-04-05T14:46:23.788Z DRIVER « [Node 012] [REQ] [ApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 179
                                    └─[DoorLockCCOperationReport]
                                        current mode:           Secured
                                        active outside handles: false, false, false, false
                                        active inside handles:  false, false, false, false
                                        latch status:           open
                                        bolt status:            locked
                                        door status:            open
                                        target mode:            Secured
                                        remaining duration:     0s
2022-04-05T14:46:36.304Z SERIAL « 0x011b0004000c159f03b4006d3e5a7e28f470fa758ea93e8750f41dfa58        (29 bytes)
2022-04-05T14:46:36.306Z CNTRLR   [Node 012] [~] [Door Lock] currentMode: 255 => 0                  [Endpoint 0]
2022-04-05T14:46:36.307Z CNTRLR   [Node 012] [~] [Door Lock] targetMode: 255 => 0                   [Endpoint 0]
2022-04-05T14:46:36.308Z CNTRLR   [Node 012] [~] [Door Lock] duration: {"value":0,"unit":"seconds"} [Endpoint 0]
                                   => {"value":0,"unit":"seconds"}
2022-04-05T14:46:36.309Z CNTRLR   [Node 012] [~] [Door Lock] outsideHandlesCanOpenDoor: false,false [Endpoint 0]
                                  ,false,false => true,false,false,false
2022-04-05T14:46:36.310Z CNTRLR   [Node 012] [~] [Door Lock] insideHandlesCanOpenDoor: false,false, [Endpoint 0]
                                  false,false => false,false,false,false
2022-04-05T14:46:36.311Z CNTRLR   [Node 012] [~] [Door Lock] latchStatus: "open" => "open"          [Endpoint 0]
2022-04-05T14:46:36.311Z CNTRLR   [Node 012] [~] [Door Lock] boltStatus: "locked" => "unlocked"     [Endpoint 0]
2022-04-05T14:46:36.312Z CNTRLR   [Node 012] [~] [Door Lock] doorStatus: "open" => "open"           [Endpoint 0]
2022-04-05T14:46:36.313Z SERIAL » [ACK]                                                                   (0x06)
2022-04-05T14:46:36.314Z DRIVER « [Node 012] [REQ] [ApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 180
                                    └─[DoorLockCCOperationReport]
                                        current mode:           Unsecured
                                        active outside handles: true, false, false, false
                                        active inside handles:  false, false, false, false
                                        latch status:           open
                                        bolt status:            unlocked
                                        door status:            open
                                        target mode:            Unsecured
                                        remaining duration:     0s
2022-04-05T14:46:51.202Z SERIAL « 0x011b0004000c159f03b500031a73becdbd958fcfd32593cac4e3fc4297        (29 bytes)
2022-04-05T14:46:51.204Z CNTRLR   [Node 012] [~] [Door Lock] currentMode: 0 => 255                  [Endpoint 0]
2022-04-05T14:46:51.205Z CNTRLR   [Node 012] [~] [Door Lock] targetMode: 0 => 255                   [Endpoint 0]
2022-04-05T14:46:51.206Z CNTRLR   [Node 012] [~] [Door Lock] duration: {"value":0,"unit":"seconds"} [Endpoint 0]
                                   => {"value":0,"unit":"seconds"}
2022-04-05T14:46:51.207Z CNTRLR   [Node 012] [~] [Door Lock] outsideHandlesCanOpenDoor: true,false, [Endpoint 0]
                                  false,false => false,false,false,false
2022-04-05T14:46:51.208Z CNTRLR   [Node 012] [~] [Door Lock] insideHandlesCanOpenDoor: false,false, [Endpoint 0]
                                  false,false => false,false,false,false
2022-04-05T14:46:51.209Z CNTRLR   [Node 012] [~] [Door Lock] latchStatus: "open" => "open"          [Endpoint 0]
2022-04-05T14:46:51.209Z CNTRLR   [Node 012] [~] [Door Lock] boltStatus: "unlocked" => "locked"     [Endpoint 0]
2022-04-05T14:46:51.210Z CNTRLR   [Node 012] [~] [Door Lock] doorStatus: "open" => "open"           [Endpoint 0]
2022-04-05T14:46:51.211Z SERIAL » [ACK]                                                                   (0x06)
2022-04-05T14:46:51.213Z DRIVER « [Node 012] [REQ] [ApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 181
                                    └─[DoorLockCCOperationReport]
                                        current mode:           Secured
                                        active outside handles: false, false, false, false
                                        active inside handles:  false, false, false, false
                                        latch status:           open
                                        bolt status:            locked
                                        door status:            open
                                        target mode:            Secured
                                        remaining duration:     0s
2022-04-05T14:46:57.222Z SERIAL « 0x011b0004000c159f03b6002811a0fac3e056165a2f32d0d236cfffc858        (29 bytes)
2022-04-05T14:46:57.224Z CNTRLR   [Node 012] [~] [Door Lock] currentMode: 255 => 0                  [Endpoint 0]
2022-04-05T14:46:57.225Z CNTRLR   [Node 012] [~] [Door Lock] targetMode: 255 => 0                   [Endpoint 0]
2022-04-05T14:46:57.226Z CNTRLR   [Node 012] [~] [Door Lock] duration: {"value":0,"unit":"seconds"} [Endpoint 0]
                                   => {"value":0,"unit":"seconds"}
2022-04-05T14:46:57.227Z CNTRLR   [Node 012] [~] [Door Lock] outsideHandlesCanOpenDoor: false,false [Endpoint 0]
                                  ,false,false => true,false,false,false
2022-04-05T14:46:57.228Z CNTRLR   [Node 012] [~] [Door Lock] insideHandlesCanOpenDoor: false,false, [Endpoint 0]
                                  false,false => false,false,false,false
2022-04-05T14:46:57.229Z CNTRLR   [Node 012] [~] [Door Lock] latchStatus: "open" => "open"          [Endpoint 0]
2022-04-05T14:46:57.230Z CNTRLR   [Node 012] [~] [Door Lock] boltStatus: "locked" => "unlocked"     [Endpoint 0]
2022-04-05T14:46:57.232Z CNTRLR   [Node 012] [~] [Door Lock] doorStatus: "open" => "open"           [Endpoint 0]
2022-04-05T14:46:57.233Z SERIAL » [ACK]                                                                   (0x06)
2022-04-05T14:46:57.236Z DRIVER « [Node 012] [REQ] [ApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 182
                                    └─[DoorLockCCOperationReport]
                                        current mode:           Unsecured
                                        active outside handles: true, false, false, false
                                        active inside handles:  false, false, false, false
                                        latch status:           open
                                        bolt status:            unlocked
                                        door status:            open
                                        target mode:            Unsecured
                                        remaining duration:     0s
2022-04-05T14:47:17.233Z SERIAL « 0x011b0004000c159f03b70085752980f6ef76d79b317a55f66a1b53cfad        (29 bytes)
2022-04-05T14:47:17.235Z CNTRLR   [Node 012] [~] [Door Lock] currentMode: 0 => 255                  [Endpoint 0]
2022-04-05T14:47:17.236Z CNTRLR   [Node 012] [~] [Door Lock] targetMode: 0 => 255                   [Endpoint 0]
2022-04-05T14:47:17.237Z CNTRLR   [Node 012] [~] [Door Lock] duration: {"value":0,"unit":"seconds"} [Endpoint 0]
                                   => {"value":0,"unit":"seconds"}
2022-04-05T14:47:17.238Z CNTRLR   [Node 012] [~] [Door Lock] outsideHandlesCanOpenDoor: true,false, [Endpoint 0]
                                  false,false => false,false,false,false
2022-04-05T14:47:17.239Z CNTRLR   [Node 012] [~] [Door Lock] insideHandlesCanOpenDoor: false,false, [Endpoint 0]
                                  false,false => false,false,false,false
2022-04-05T14:47:17.240Z CNTRLR   [Node 012] [~] [Door Lock] latchStatus: "open" => "open"          [Endpoint 0]
2022-04-05T14:47:17.241Z CNTRLR   [Node 012] [~] [Door Lock] boltStatus: "unlocked" => "locked"     [Endpoint 0]
2022-04-05T14:47:17.241Z CNTRLR   [Node 012] [~] [Door Lock] doorStatus: "open" => "open"           [Endpoint 0]
2022-04-05T14:47:17.242Z SERIAL » [ACK]                                                                   (0x06)
2022-04-05T14:47:17.243Z DRIVER « [Node 012] [REQ] [ApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 183
                                    └─[DoorLockCCOperationReport]
                                        current mode:           Secured
                                        active outside handles: false, false, false, false
                                        active inside handles:  false, false, false, false
                                        latch status:           open
                                        bolt status:            locked
                                        door status:            open
                                        target mode:            Secured
                                        remaining duration:     0s

I'm far from an expert at interpreting these logs but I see nothing at all about codes or anything that could even correspond to codes. I do see that the "doorStatus" always goes from open to open, which may be related to the door sensor.

Again, really appreciate your help.

mbbush commented 2 years ago

This lock doesn't support the Door Lock Logging command class, which I think is what would be required to be able to see which code is used when.

I've been able to view and set user codes just fine, although there's the odd thing about the status I mentioned above. I've only done it by manually sending raw zwave commands; I haven't tried using any more user-friendly UI.

I opened a support request with the manufacturer about some of these issues, and they seem open to feedback and suggestions for improvements to make in a firmware update.

If there's something specifically that you'd like it to do, but it doesn't, maybe send the request to the ultraloq support team?

AlCalzone commented 2 years ago

which I think is what would be required to be able to see which code is used when.

Plenty of locks use the Notification CC to report user codes, either as the unstandardized V1 Alarm values, e.g. Yale YRD220 (link, scroll down to the mapping table), or as standardized V2+ notifications.

The standardized notifications define several variants to include the user codes: https://github.com/zwave-js/node-zwave-js/blob/8256503cc18efc5e104bddda9eae6d94be64fe64/packages/config/config/notifications.json#L548-L561 https://github.com/zwave-js/node-zwave-js/blob/8256503cc18efc5e104bddda9eae6d94be64fe64/packages/config/config/notifications.json#L606-L621

IMO this would be the easiest way to implement this. Door Lock Logging is overkill for this use case, since it's meant for an audit log that captures multiple historical lock/unlock attempts.

guniv commented 2 years ago

I opened a support request with the manufacturer about some of these issues, and they seem open to feedback and suggestions for improvements to make in a firmware update.

If there's something specifically that you'd like it to do, but it doesn't, maybe send the request to the ultraloq support team?

Is there a specific place you sent this in or just a support ticket on their website? I'd like to make sure it goes to the right place and hopefully doesn't just get ignored by customer service. If you have recommendations on how to word as well I would appreciate it because otherwise my ticket is just going to be "please let z-wave users see which door code/method was used to unlock the door"

Hopefully they plan on improving their Z-wave implementation so they can bring it to other products, and getting them feedback on an early product like this will help.

mbbush commented 2 years ago

oh cool, I didn't realize the notifications command class could do that. That's much simpler.

Unfortunately, (at least with the current firmware) this lock only sends the Door Lock Operation Report command when it is operated, which doesn't include any details about how/why it was operated (manually, code, fingerprint, which code, etc). There's nothing zwavejs or any other library can do about this; the data simply isn't there.

I just submitted a regular support ticket.

I'd probably also mention the Notification zwave command class as a way to accomplish this, and express your eagerness to have firmware updates available to improve the functionality of the product.

AlCalzone commented 2 years ago

I just noticed, the lock does report that it doesn't support the door status, the driver just doesn't behave differently based on that. So we can at least fix that part...

guniv commented 2 years ago

Just a heads up @mbbush after I sent in a support ticket I was very specifically asked to post feature requests on their forum here.

FirbyKirby commented 2 years ago

Piling on to this issue. I too have the same lock, and am using it with zwave-js via Home Assistant (seems essentially identical to guniv's setup.) My experience is identical as well in terms of the unusable door open sensor, and duplicate lock entities (which is expected.)

@guniv , if you created a feature request post in their forum, can you post a link to your request? I'd like to reply specifically to it to add my weight to your request. Would recommend others to do the same so we can apply specific pressure to get what is needed for better support from the manufacturer in this toolchain, rather then a disconnected set of feature requests from single users.

guniv commented 2 years ago

if you created a feature request post in their forum, can you post a link to your request? I'd like to reply specifically to it to add my weight to your request. Would recommend others to do the same so we can apply specific pressure to get what is needed for better support from the manufacturer in this toolchain, rather then a disconnected set of feature requests from single users.

I haven't made one. If @mbbush has time and is willing to he might be the best person to write the post, since he seems to have a good understanding of Z-Wave and I do not. I can try and write something tomorrow, otherwise. I would definitely like to reply to the post as well and I'll probably reach out to people here and that I've seen on Reddit to ask them to also voice their support.

FirbyKirby commented 2 years ago

I haven't made one. If @mbbush has time and is willing to he might be the best person to write the post, since he seems to have a good understanding of Z-Wave and I do not.

Makes sense. I'm in the same boat. I'll standby and wait to see how it's decided to raise this issue with U-tec.

I would definitely like to reply to the post as well and I'll probably reach out to people here and that I've seen on Reddit to ask them to also voice their support.

Roping in the Reddit thread is a good idea as well. That's actually how I routed here.

guniv commented 2 years ago

@FirbyKirby @mbbush @Roundaround I have made a post on their feature request forum. I think it would help greatly to get as many people as possible to reply to the post to say they also would like to see these features.

kpine commented 2 years ago

Additionally, Z-Wave currently reports two different locks to the controller (one Lock and one Door Lock),

Z-Wave JS is what is causing the two different locks, not the device.

guniv commented 2 years ago

Z-Wave JS is what is causing the two different locks, not the device.

Good to know, I thought based on reading this thread that it was unnecessarily reporting two types of devices. I will update my post on their forum.

kpine commented 2 years ago

For context, see my earlier comment. Z-Wave JS doesn't differentiate between Z-Wave Plus and Z-Wave Plus V2 device requirements, so it mistakenly creates a "phantom" Lock CC.

FWIW, it doesn't really matter anymore if you're an HA user. HA addressed this in the 2022.4 release and doesn't create a lock entity for the Lock CC if the Door Lock CC is also present. Only the latter is used, even for non Plus V2 devices.

FirbyKirby commented 2 years ago

I have made a post on their feature request forum.

Thanks! I just added my response. Here's hoping we can catch the eye of a U-tec engineer cruising the forum.

guniv commented 2 years ago

Thanks! I just added my response. Here's hoping we can catch the eye of a U-tec engineer cruising the forum.

Thanks! I DM'ed a whole bunch of people on Reddit and asked them to chime in as well so we'll see how that goes, but two replies is already more than most posts get.

@mbbush if you see this later, you said you are a Hubitat user. I would recommend you do the same and message people on the Hubitat forums who use this lock and ask if they'll chime in too.

zwave-js / node-zwave-js

[feat] Support for Ultraloq zwave locks #3935