DrZWave

The Z-Wave Power Level Command Class has a number of very handy (but rarely used) commands to test and maintain a robust Z-Wave network. Power Level CC is required to be supported by all Z-Wave Plus devices so any new device on the market supports it. The purpose of this command class is to measure the quality of each link in the Z-Wave mesh network. Naturally, some devices have good links and some have not so good links. Some devices have really good antennas and are placed in good locations, others have terrible RF antennas and are stuck inside a metal box with only one side exposed and down a long concrete hallway. Power Level CC helps you figure out which links are strong and which links are weak. Informing the user that some links are weak and giving them the recommendation to install another node into the mesh to strengthen the links and make the network robust will make for a superior user experience.

Power Level Test Node Set

The POWERLEVEL_TEST_NODE_SET command has the following parameters:

• Test NodeID (1-232)
• Power Level (0-9)
• Test Frame Count (2 bytes, MSB first)

The device that receives this command will send Test Frame Count NOP packets at the Power Level to the Test NodeID. The Test NodeID will ACKnowledge each NOP that it receives. Once the device has sent all the NOPs, it will return the number of NOP ACKs were received. Simply put, this command returns the percentage of packets that can be exchanged between these two devices at the power level chosen.

Sending a few dozen packets at different power levels enables the quality of the RF link between the two nodes to be measured. Do this with all the nodes in the mesh and you can build up a view of the mesh with different colored links between them based on the quality of the RF link.

Learning – you can’t send a Test Node Set to test FLiR nodes

While attempting to use this feature, I found that you can’t send NOPs to FLiRs (Frequently Listening Routing Slave). FLiRs nodes are a special type of node in Z-Wave. They are battery powered devices that can wake up when you call them! Basically they wake up once per second and briefly listen for a special WakeUpBeam. If they hear it, then they wake up and you can talk to them. Since they are asleep most of the time they use very little battery power and have a little latency but otherwise are great for things like door locks, window shades or thermostats.

The problem with Power Level Test Node Set is that the command does not tell the device that is sending the NOPs that the Test NodeID is a FLiR node and has to send a wake up beam to it. Thus, if you send the command, all you get are complete FAILs since the FLiR node has been asleep all this time because the sender didn’t tell it to wakeup.

Sigma stated that sending an AssignReturnRoute command to the repeater to give it a return route to the FLiR node the repeater should then know the destination is a FLiR node. I tried this with a repeater running SDK 6.51.06 but the repeater still did not send a WakeUpBeam so this isn’t a solution yet.

Workaround – Send the Test Node Set to the FLiR node to test the repeater

The solution to this problem is to reverse the testing and send the Test Node Set command to the FLiR node with the repeater node as the Test NodeID. A WakeUpBeam will be sent by the controller (and any repeaters in the mesh network) to send the Test Node Set command to the FLiR node. Once that node receives the command, it’ll blast out the NOPs to the always-on repeater and then send you a report when it’s done.

Well, you can only do this if the FLiR node supports PowerLevel Command Class. Unfortunately, door lock manufacturers  move pretty slow so their firmware may not support PowerLevel CC yet.

I’ve been wanting to use Power Level CC to show some cool mesh network quality drawings but haven’t had the time to do it… yet… Stay tuned…