node-zwave-js: Aeotec Z-Stick 700 with FW 7.17.2.0 - "Duplicate command" errors after backup restoration

Yeah the incorrect power display is already fixed in v10. Was a matter of correctly interpreting it as a signed value.

Weird, I didn’t get any notification that you answered. I’ll let Aeotec know that you were able to reproduce my findings.

I’m also having the low SNR issues with an Aeotec z-stick 7. I’m upgrading from a Nortek HUSBZB-1, which as far as I know had no SNR issues since it worked great for the few years I used it. With the Aeotec I’m unable to get through a full interview on my front door lock. Power levels in zwavejs2mqtt are reported in the -85-91 dBm range. No surprise it’s not working well. Even with direct LOS with < 15 ft, the SNR is poor. I’ve got a Zooz 700 series arriving today to see if it rectifies the low SNR.

txPower and measured0dBm have somewhat strange values. I’d expect them to be 0.0 (tx power) and +3.3 (measured).

Mine reports the same as @mundschenk-at, 9.9 and 0, respectively.

Yeah I did. What strikes me as a bit odd is that the second test has a worse SNR margin, but the latency and route changes are better than the first test. The difference in SNR margin is caused by a change in ACK RSSI which is ~10 dBm higher for the first tests. I’m not sure what causes this - maybe the calibration changed somehow?

That said, I did my own measurements with 4 different controllers yesterday (Z-Stick 7, UZB 3 and 7, and a Razberry 7 Pro). The Z-Stick 7 performed significantly worse than the others (20-35% less range, 15-30 dBm worse SNR margin) and had troubles including a node in some locations where the others had no issues.

The current state is included in the NVM backup. Make a fresh one, then convert it to json and copy all entries for lwr and nlwr.

AFAIK this depends on the background RSSI. The higher that is, the higher the RSSI should be. The lifeline health check is modeled after what Silabs’ PC Controller does and they recommend an RSSI margin (<RSSI> - <background RSSI>) of 17 dBm or more.

If you’re interested in the background RSSI at the controller (it can’t be measured at nodes), you can execute a driver function and watch the logs:

await driver.controller.getBackgroundRSSI()

That’s almost correct. For the example you showed it is, but if there are multiple repeaters, you’re going to have multiple measurements in the “on repeaters” line. E.g. if the route is (1 -> 70 -> 71 -> 68), then you’ll see (for example)

repeater node IDs:      70, 71
ACK RSSI:               -68 dBm
ACK RSSI on repeaters:  -91 dBm, -88 dBm

where -88 is the RSSI of the ACK that 71 received from 68 and -91 is the RSSI of the ACK that 70 received from 71 and -68 is the RSSI of the ACK that the controller received from 70

It looks like you attached a logfile, but its filename doesn’t look like it a driver log.

It is.