Can't Get Door Locks to Work

[PeteCal]

I am not sure this is a question for this forum. If it isn't, maybe someone can point me in the right direction.

I have three door locks, all different manufactures. I get the same "Values" for all of them. See the image. Note, I also have a zwave thermostat and it works great with zwavejs2mqtt.

I have been using these locks for years with OpenHAB. In fact, if I swap the SD card (Raspberry Pi) back to the OpenHAB SD, they still work. When I swap back to the zwavejs2mqtt SD I get the image.

Details:
I am using an AEOTEC stick.
I included all the devices when using OpenHAB.
If I click the arrow> for the Target lock mode I see a flurry of activity in MQTT Explorer that seems to send all 15 topics on the Values page (only 6 or 9 are in the image, the rest are lower down).

What could be my problem?

[robertsLando]

Did you tried to re-interview your door locks? Anyway we need driver logs to help you here.

[robertsLando]

cc @AlCalzone

[AlCalzone]

I have been using these locks for years with OpenHAB. In fact, if I swap the SD card (Raspberry Pi) back to the OpenHAB SD, they still work. When I swap back to the zwavejs2mqtt SD I get the image.

Have you configured security keys in zwavejs2mqtt to be the same as in OpenHAB?

[kpine]

--device=/dev/ttyACM0:/dev/zwave

With this configuration the path in the container is /dev/zwave not /dev/ttyACM0. Pay close attention to the minimum required settings in the docs: https://zwave-js.github.io/zwavejs2mqtt/#/getting-started/quick-start?id=minimum-settings

[PeteCal]

I had a second thought. Uninstall docker and start over by installing docker and then the docker run...... as above. Almost the same result except in zwave the port was "/dev/zwave " not /dev/tty/ACM0. I changed it and saved it but still the same error message as above except the DRIVER version is now 10.0.4

[kpine]

You still need to enter the port path and save it. It's just a pre-filled text box, not set.

[PeteCal]

Yes, I did make it /dev/ttyACM0 and save it.

[kpine]

Except the setting is not /dev/ttyACM0, it's /dev/zwave.

--device=/dev/ttyACM0:/dev/zwave -> host path is /dev/ttyACM0, container path is /dev/zwave. zwavejs2mqtt runs in the container.

[PeteCal]

kpine:
That very note has been fighting me all day. It says
"Replace /dev/serial/by-id/insert_stick_reference_here (only the first half of the X:Y mapping!) with the serial device for your Z-Wave stick".
The highlighted text is:
"/dev/serial/by-id/insert_stick_reference_here" so that was what I tired to replace. Thus I left, ":/dev/zwave " in place.
I have no idea what " (only the first half of the X:Y mapping!) " means and neither does google.
So please tell me what that line should look like. I tried many variations that were rejected but the one I used was accepted.

[AlCalzone]

It's definitely not an issue with the host system. Z-Wave communication clearly works, but the lock isn't responding to secure commands. It's not the S2 keys either, the lock is either included with S0 or doesn't support S2 - impossible to distinguish after inclusion.

Right at the start, there's one exchange that makes me think your S0 key is wrong:

2022-09-13T05:28:06.857Z DRIVER « [Node 028] [REQ] [ApplicationCommand]
                                  └─[SecurityCCNonceGet]
...
2022-09-13T05:28:07.273Z DRIVER » [Node 028] [REQ] [SendData]
                                  │ transmit options: 0x05
                                  │ callback id:      22
                                  └─[SecurityCCNonceReport]
                                      nonce: 0xcd024f7fd4e658f4
...
2022-09-13T05:28:07.479Z DRIVER « [Node 028] [REQ] [ApplicationCommand]
                                  └─[SecurityCCCommandEncapsulation] [INVALID]
                                      error: Invalid auth code, won't accept security encapsulated command.

In plain english: Lock requests a nonce (temporary value for encryption), Z-Wave JS responds, Lock uses nonce to encrypt command, sends it. Z-Wave JS is unable to decrypt. The only thing that could be wrong at this point is the S0 key, which also explains why the lock won't respond to any secure commands - it cannot decrypt them either.

[AlCalzone]

If you want to go "nuclear", exclude the locks, then factory reset them to get rid of any stored keys, then re-include them, so they get the key you've actually configured.

[PeteCal]

Al, you nailed it. Slam dunk. I had screwed up the security code. One character out of 32. I put in a "D" where I should have put "0". I was getting it from a blury screen capture from the program that used the stick before. But when I created the minimal system I put the key in correctly so that worked. So, finally after getting all the real important stuff straightened out, it was this little thing.

I was an excruciating journey since July 2 when I started with Z2M. I know I did a lot of things wrong but as I look back I think one of the things that cost me a lot of time and tons of frustration was the "Note" in the image.

I tried over and over to get my /dev/ttyACMO entered into the line correctly. In the end, I never did succeed. The other website I used had it filled in correctly so that is why the install exceeded when I couldn't make that happen based on the Note. Maybe it would help to provide a correct example. The same applies to the Run as a service instructions.

Also, I couldn't get the NodeJS or PKG version to work because I always ended with some Exec error. I tried to search that out but it is caused by many many things. I was going nowhere.

All in all it looks like Z2M will be my solution.

Thanks Al, and the rest for getting me through this.

Pete

[kpine]

Regarding the note, are you saying you don't understand how find the USB path? If so, all you need to do is list the files in the directory:

$ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Jul  5 18:09 usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_bae21b797a3eeb11a8c12ebcf28b3f46-if00-port0 -> ../../ttyUSB0

Therefore my controller USB path is /dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_bae21b797a3eeb11a8c12ebcf28b3f46-if00-port0. It's not feasible to provide a "correct" example path that you can just copy and paste, because with the introduction of 700-series controllers and later, the path includes a serial number which is unique.

[PeteCal]

No, it is mush simlper then that. Where in the string:
--device=/dev/serial/by-id/insert_stick_reference_here:/dev/zwave
do I put /dev/ttyACMO.
Just after the "=" and remove or keep the rest of the string?
Just after the "by-id/" and remove or keep the rest of the string?
In place of "insert_stick_reference_here"?
Do I keep the ":"?
I tried every thing I could think of.

Similarly, in docker-compose.yml
"- '/dev/serial/by-id/insert_stick_reference_here:/dev/zwave'" presents a similar problem.
The site I used just said, " - '/dev/ttyACM0:/dev/ttyACM0' " and it worked. Maybe you folks are a few levels above me in this.

[PeteCal]

Success!! After many hours over three days I finally cracked the problem. I continued trying to install using the instructions in the Readme but it kept acting like it couldn't get to the AEOTEC stick. I developed the theory that there could be old code on the SD Card from other programs that used the stick. So I decided to try with a minimum system. I installed the minimum RPi OS and installed only Mosquitto and z2m which required Docker also. With that I returned to using the Readme but kept getting the same problem. I did some searching and found a site that had a different method of installing z2m. I tried that and, after more then a typical number of dead ends and retries, it worked!

I can now reach all three door locks and the thermostat is fine. The locks report the state of the bolt correctly. Now I have to decipher all the other commands that show up.

Now my alternatives are (1) go back to my development SD and see if I can get z2m to work using the method on the new site or (2) use the minimum SD and transfer 20 or 30 my development files to the minimum system. I think I will stat with #1.

Thanks folks, for all the help and sticking with me.

Pete