ZWaveJS2MQTT "Unknown manufacturer 0xXXXX" after re-interview

Configuration Z-Wave
1

I’m migrating my ZWave network to ZWaveJS2MQTT using an Aeotec ZStick 7 as the controller.

When I added my 3rd Inovelli LZW31-SN it got stuck during the initial interview and eventually marked the node as dead. I power-cycled the switch via the airgap and then did a Re-Interview in ZWaveJS. This completed sort of successfully with the final message: INFO ZWAVE: Node 22 ready: Unknown manufacturer 0xXXXX - Unknown product 0xXXXX (0xXXXX)

Log files: zwavejs.log · GitHub

Version info:
zwavejs2mqtt: 6.0.2
zwave-js: 8.8.2

System Health

version core-2021.11.5
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.9.7
os_name Linux
os_version 5.10.17-v8
arch aarch64
timezone America/Los_Angeles
Home Assistant Community Store
GitHub API ok
Github API Calls Remaining 4999
Installed Version 1.18.0
Stage running
Available Repositories 911
Installed Repositories 8
Home Assistant Cloud
logged_in true
subscription_expiration December 14, 2021, 4:00 PM
relayer_connected true
remote_enabled false
remote_connected false
alexa_enabled false
google_enabled true
remote_server us-west-2-0.ui.nabu.casa
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud ok
Home Assistant Supervisor
host_os Home Assistant OS 6.6
update_channel stable
supervisor_version supervisor-2021.10.8
docker_version 20.10.8
disk_total 457.7 GB
disk_used 34.0 GB
healthy true
supported true
board rpi4-64
supervisor_api ok
version_api ok
installed_addons Mosquitto broker (6.0.1), File editor (5.3.3), InfluxDB (4.3.0), Node-RED (10.1.1), Grafana (7.3.1), Home Assistant Google Drive Backup (0.105.2), SSH & Web Terminal (9.1.1), Tautulli (2.3.0), Log Viewer (0.12.1), Samba share (9.5.1), Z-Wave JS to MQTT (0.31.0)
Lovelace
dashboards 7
resources 1
views 15
mode storage
2 Likes
2

I have this happen sporadically where the manufacture and other info is not populated but the device still usually works.

3

My OCD can’t deal with the unknown side of things so I’m currently just excluding/including until the initial discovery process completes successfully.

4

Highly recommend using the SmartStart option and just scan the QR code that came with your LZW30-SN.

This is assuming you’re using the zwavejs2mqtt container/addon to add the nodes.

5

This is with SmartStart. I’ll air-gap the switch, scan the code, power on the switch. About 25% of the time it gets stuck in initial discovery. If I re-interview later it will finish discovery but the model/manufacturer are still left unknown.

6

Sounds like you may have some RF issues going on, is your zstick plugged in via a USB extension cable or directly into the USB port?

If in the port directly, put in a USB extension cable and move the stick away from the machine(s) and/or rack it may be set in.

7

It is on an extension well away from anything else. It could also be due to having another ZWave network running that I haven’t turned off yet. I’m migrating from Hubitat to ZWaveJS2MQTT but I have enough devices that doing a clean turn off the old / turn on the new is hard from a “keeping the family happy” perspective.

That only explains the issue with the initial inclusion though. I’m more curious why re-interviewing doesn’t fix the manufacturer / device discovery step.

8

According to the logs posted, the device doesn’t respond to any of the requests for info during the re-interview. ZJS doesn’t know the manufacturer if it doesn’t get that info. It doesn’t even look like it made it far enough to even request the mfgr info.

2021-12-01T06:29:19.712Z CNTRLR   [Node 022] did not respond after 1/3 attempts. Scheduling next try in 500 ms.
...
2021-12-01T06:29:49.259Z CNTRLR   [Node 022] Timed out while waiting for a response from the node (ZW0201)

It also looks like it was included with S0 security, or the driver thinks that’s the case. Maybe that’s why the communication is failing. Do you have logs from the initial inclusion?

9

I think this is the original inclusion log: zwavejs.log · GitHub

As I continue to move devices I’ll be more careful about tracking when I start inclusion and capturing the zwavejs logs for each step.

10

The log shows it was included with SmartStart, and the S2 security bootstrapping was successful. One interesting thing to note is that multiple security classes were granted, including S0 security. The re-interview seems to be querying the device using S0 messages, when it never did that in the first place. Not sure if that’s the correct behavior or not. If you can reproduce it, you might want to submit a bug report. You could also try doing advanced inclusion, and disabling the S0 security class when it prompts (unless you are using association with S0 devices). That should prevent it from trying to query for S0 capabilities.

11

Can you share the snippet of the log that shows the S0 query? I’ve been consistently having this issue when using Smart Start vs manual inclusion and entry of the DSK.

I’ll start capturing logs of both approaches and file a bug report.

12

S2 security messages show in in the log as Security2CC..., while S0 messages show up as SecurityCC....

Looked into your inclusion log again, and there are few problems. The S2 bootstrapping was successful, but some parts of the interview failed.

2021-12-01T05:51:54.491Z CNTRLR   [Node 022] [+] [Security 2] interviewComplete: true    [Endpoint 0] [internal]
2021-12-01T05:51:54.521Z CNTRLR » [Node 022] Querying securely supported commands (S0)...
2021-12-01T05:51:54.540Z SERIAL » 0x011a00a901160e9f03e400d6c7ab51df333407ea66250000000051e1          (28 bytes)
2021-12-01T05:51:54.541Z DRIVER » [Node 022] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ route:            0, 0, 0, 0
                                  │ callback id:      81
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 228
                                    └─[SecurityCCCommandsSupportedGet]
2021-12-01T05:51:54.550Z SERIAL « [ACK]                                                                   (0x06)
2021-12-01T05:51:54.553Z SERIAL « 0x010401a90152                                                       (6 bytes)
2021-12-01T05:51:54.554Z SERIAL » [ACK]                                                                   (0x06)
2021-12-01T05:51:54.555Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2021-12-01T05:51:54.616Z SERIAL « 0x011d00a95100000601ca7f7f7f7f01010302000000020100007f7f7f7f7faa    (31 bytes)
2021-12-01T05:51:54.617Z SERIAL » [ACK]                                                                   (0x06)
2021-12-01T05:51:54.620Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            81
                                    transmit status:        OK, took 60 ms
                                    repeater node IDs:      2
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    ACK RSSI:               -54 dBm
                                    ACK RSSI on repeaters:  N/A
                                    ACK channel no.:        1
                                    TX channel no.:         1
2021-12-01T05:52:04.630Z CNTRLR   [Node 022] Timed out while waiting for a response from the node (ZW0201)
2021-12-01T05:52:04.631Z CNTRLR   [Node 022] Querying securely supported commands (S0) timed out

That’s the same error as in the re-interview.

There are a lot of these S2 errors. Not sure if these cause a problem.

021-12-01T05:52:05.007Z SERIAL « 0x011d00a8000116149f03ac006b23d2d9cc91371be4d878077de5397f00ca1c    (31 bytes)
2021-12-01T05:52:05.009Z DRIVER   Dropping message with invalid payload
2021-12-01T05:52:05.009Z DRIVER « [Node 022] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -54 dBm
                                  └─[Security2CCMessageEncapsulation] [INVALID]
                                      error: Duplicate command

There are a couple of other failures.

2021-12-01T05:52:44.909Z CNTRLR   [Node 022] Timed out while waiting for a response from the node (ZW0201)
...
2021-12-01T05:53:58.978Z CNTRLR   [Node 022] Timed out while waiting for a response from the node (ZW0201)
2021-12-01T05:53:58.980Z CNTRLR « [Node 022] received no value for parameter #12
...
2021-12-01T05:55:05.901Z CNTRLR   [Node 022] did not respond after 1/3 attempts. Scheduling next try in 500 ms.

So in general it had a rough time doing the interview.

Not sure if there’s a communication problem with this particular switch or not. You can try disabling the S0 security class in the SmartStart provisioning list, and see what happens if S0 is disabled. Or include it with Classic S2 inclusion and disable S0. If that makes any difference, it’s a clue.

13

did anyone ever figure out the answer to this? i’m in the same boat right now, and it’s uber-frustrating because the switches i’m having this issue with were working until today. all of a sudden, now, i can’t get them to work to save my life. they constantly have long delays when trying to activate them via HA, and constant time out messages in the logs. exclude/reinclude has has no effect, and the ones that i do re-interview now say unknown manufacturer / unknown product…

i don’t know what to do. i’ve never been this frustrated in my life…if it had stopped working for a reason, that’d be one thing…but these were all great for over a month, and then just randomly stopped working. it’s maddening.

edit: finally got it to come back and stop timing out by flipping the breaker off and back on. the frustrating thing is that while it’s fixed, i don’t know what caused it to begin with so i have no idea if or when it’ll happen again, or how to prevent it. open to any suggestions.

1 Like