OH3 Zwave: monitor link quality?

Hello everybody,

I’m running a zwave network with about 20 nodes. Until now everything was running great, but the newest addition, a Kwikset zwave lock, fails to react to commands more often than not.
It’s included correctly (including security) and does work in general, but sometimes decides not to react. Obviously exactly when I want to open the door…

Is there a way to monitor the zwave link quality of a node? I don’t really believe that this is an issue as it’s right next to a powered switch, and about 3 feet away from another, both of which work fine and act as repeaters. Additionally openhab shows that the lock has 7 direct neighbors, all of them mains-powered, including the controller itself.


Hi Michael,

There is no RSSI or any other indicator directly available as a Channel (atleast to my best of knowledge). What I would do is work with the channels you have and store them into a database and plot them (for instance with Grafana). Perhaps it will show you more inside of when this occurs.

Some devices have a check built in. Fibaro switches for example.

There is also an enhanced call that does report back the stats of each call but this was introduced relatively recently and I am sure after the binding was written.

Currently the best way is to get this for devices without a test is a zniffer. This allows you to see the route taken, the channel used and the RSSI of each hop as the zniffer receives the command. If you want the approximate RSSI between each node you would have to move the zniffer to near each node on the route.

It is worth doing as some devices that function perfectly well in other ways can have issues with the RF power. I have found a couple that clearly had faults in the TX circuit.

Thanks, guys. As Zigbee provides a “link quality”, which is perfect for making sure reception is good, I was hoping that zwave would have something like this, too. Doesn’t seem to be the case.

I have to admit that this is the 2nd lock of the same type I have (sent the first one back because of said issues), but the new one behaves exactly the same.

I’ll monitor it a little with Grafana, but am not sure this will tell me anything new. I currently have two items:

  • The main door switch item, linked to the zwave channel and
  • a virtual item representing the door status. This gets changed when either the main switch item changes or when the raw_alarm channel changes (it’s a JSON string I extract the status from)

Still, it has a lot of hiccups, such as neither channel updating when the lock is manually turned, or not reacting to channel changes by openhab, or reacting 10-20 seconds after the change is implemented.

The fault is definitively not with Openhab or the binding. I looked into getting a different zwave lock, but those have become really few on the market. Manufacturers rather like you to get a Wifi-based one that only works with their cloud, something I’d really want to avoid. An alternative would have been the August zwave lock, where you can cut off cloud access after setup and only run it via zwave, but that is just a tad too large to fit the door…

It does sound like marginal communication but that could be caused by a number of things.

No good route to controller.
One or more bad nodes.
Too much traffic form other nodes.

A zniffer does not cost a lot and might tell you enough to solve your issues. Locks that tend to be included secure and also use FLiRS need a good link and not too much competition from other nodes as both security and FLiRS use a lot of network bandwidth.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.