Monitor the network traffic of Z-wave/ZigBee

Hi there,
Does anyone know how to monitor the network traffic of ZigBee or Z-wave protocol? I’ve already enable the function of log viewer, but I need more detailed information. Some parameters, like RSSI, payload, length.etc. See figure below.

Thanks in advance!

image

Both Zwave and Zigbee are mesh networks. You can monitor what the controller/coordinator sees by putting the bindings into debug or trace level logging (see Taming openHAB 2 Logging), which you already indicate you have done.

But realize that a value like RSSI isn’t going to be all that useful to you because it will reflect the RSSI between the device that sent the message to the controller which may not and probably is not the device that sent the original message. That is kind of the point of a mesh network. Even if a device can’t see the controller/coordinator it can reliably send/receive messages by routing the message through the other devices on the network.

What you see in the logs is what is available in OH. You might be able to see more with some third party tool like OZT or Zensys tools (and whatever the equivalent would be for Zigbee. I also think there are makers of sniffing devices you can use that might tell you something about the network. I don’t know.

In general, RF sniffing is not easy for ZWave as there are no readily available sniffers. You need a special stick that has software to provide this information. This comes with the SDK, which used to cost around $2k when I bought it when Sigma were still running things (I’m not sure of the price now - it might change with Silabs taking over).

For ZigBee, this isn’t as hard - there are CC2531 dongles available at low cost that can sniff the network and you can use Wireshark to view the results. Silabs also have a product called Simplicity Studio which uses their hardware (a little more expensive than the cheap Chinese CC2531 from TI).

Have you looked at this device? I have no experience with it.

Edit: Updated link

Hi chris,
Thanks for providing so detailed information.
For z-wave, actually, I searched sillabs website, the hardware and software they provided is quite expensive. but it seems pretty cool.
I’m wondering, does z-wave protocol support two coordinators? I mean, are openhab and sillab’s sniffing controller able to work together?
Thanks!

Hi Mark,
Thanks for providing this cool tools. I’ll dig more about it, see if it works good for me

Hi Rich,
Really appreciated your advice!

ZWave can operate with multiple controllers, but I think this isn’t relevant. Sniffers normally work outside of the network - they simply “sniff” (ie receive) what they hear on the RF link, and then display it. This means they aren’t constrained by network or protocol limitations.

Z-Wave sniffer: https://www.suphammer.net/suphacap

And yet another one:

Cheaper and with a Wireshark dissector …

Looks interesting. I wonder if you can use this to capture and analyze the frequency spectrum in order to detect things (e.g. baby monitors) that might be causing interference with the zwave network.

Good question. I don’t know (yet), but I have ordered them both to play with during the holidays :slight_smile:

Excellent! Looking forward to your report! :wink:

I saw that it saw Ubuntu 17.04 was required. I wonder if it really is that specific. I’d like it to run on 16.04 or 18.04. What version will you be using?

I’m on Server 16.04 LTS

1 Like

I have my SupaCap up and running, and noticed at once one talkative node that was sending Basic Class 0x20/32 updates to a non existing node. This was not visible in the z-wave DEBUG logs. (probably because it was sent as an association).
This was a Fibaro RGBW (gen1, non plus) and after changing association 5 to controller, param 43 to 100, and setting param 44 & 45 to higher values all transmission to non existing node stopped.

The SupaCap is very easy to use, but it differentiate between ‘normal’ and ‘high speed’ channels.
So if expected traffic is not seen on one channel one has to switch to the other.
All include/exclude traffic is also on a separate channel.

Now, I’m going to set up the SW radio stick. Stay tuned :slight_smile:

The binding will only show traffic that is sent to the coordinator. In theory, there is the possibility to set the dongle into a so called promiscuous mode, but most dongles do not support this feature.

Exactly, that is why I’m testing out these sniffers. One major point is to let the controller do it’s regular business while monitoring.

Capturing something, but I think something is lacking in the Wireshark dissector?


Also lacking in the Time column…

This looks interesting, wireshark interface is so nice. Source, destination and time would be nice to have around though. Did you ask the dev(s) about reason it not being supported?

Not yet, but will do.
Source and destination are there, in Info & header dissection.
Don’t know why it marks some frames as too SHORT/LONG.
Another interesting feature of this SDR (Software Defined Radio) is the ability to set up a spectrum analyser in the frequency band around 868.42MHz to see if there are other transmitters interfering.