Z-Wave Multichannel, Advanced S2, and Supervision Lab Exercise#
This lab exercise demonstrates the multichannel command class, ensuring delivery of S2 payloads, and the supervision command class in the following ways:
Controlling multichannel endpoints
Understanding when the S2 TX option 'Verify Delivery' is invoked
Using supervision encapsulation
2 UZB Controller
1 Raspberry Pi 3B (+)
1 SD card
1 IP Router with built in DHCP
1 WSTK Main Development Board
1 Z-Wave Radio Development Board: ZGM130S SiP Module
1 USB Zniffer
Familiarize yourself with the protocol by going to the following page https://www.silabs.com/support/training/z-wave-700-series Videos 1-3 and exercise 6,7 and 10 are relevant.
Preparation for the Lab#
First, program the development board with the power strip sample application and include it (with S2) using the PC controller.
The above image does not show all information about the included device. Select it on the left hand pane and click the “node info” button in network management to learn more:
You can now see that a tree is expanded under the initial device, which has multichannel endpoints. To learn more about the endpoints, select any of them and check the listed command classes:
Each of the endpoints has its own set of properties, allowing the controller to parse each endpoint as separate logical Z-wave devices.
Selecting one of the endpoints on a PC controller and clicking “basic on” or “basic off” results in a frame being sent to the specific endpoint. Capture a frame using the Zniffer and decrypt the payload.
Here you can see that the basic command is encapsulated in the multichannel command class, specifying source and destination endpoints. Because the PC Controller is not a multichannel device, the source endpoint is 0, and the destination endpoint is 1, which results in turning on LED0.
To control both endpoints at the same time in the PC Controller, CTRL+click to select multiple endpoints in the top right pane:
Next, transmit basic on or off commands again. Now, you can see that both LED0 and the RGB diode directly on the radio board are being controlled. In the Zniffer, you should see the following exchange:
You can see that the flag “bit address” is now set. This means that the destination endpoint is now a bitmask with bits 0 and 1 set, thus addressing endpoints 1 and 2.
S2 TX Option Verify Delivery#
The Z-wave controller uses S2 TX option Verify Delivery on all commands, independently of the payload. On the end device, press “reset” on the WSTK board. Because the power strip sample application is always on the node, the SPAN is not stored persistent, and does not survive power cycle. In the PC controller, select the root device of node and send a command, e.g., “Basic set on”:
This results in a frame flow as follows:
The “SOS” flag set in the nonce report tells the PC Controller that the destination, the power strip sample application could not decode the frame, and the following frame has a SPAN header extension allowing the nodes to resynchronize, and the S2 payload to be delivered and decrypted successfully. Try sending one more frame without resetting the device. The message goes right through, without any returned nonce reports.
Go to the command class view of the PC Controller and tick “Supervision get” and “auto increment” buttons. Select the “command class switch binary” and the “command switch binary set. Clock the “show log” file, and click “send”:
You now see in the log that a supervision report was received, as shown in the image below.
While using the Zniffer, verify the outgoing frame is encapsulated with “supervision get” and that the destination returns a “supervision report”:
Selecting the “supervision report”, note the status is 0xFF, which means success. In other words, the command was decrypted, corrected, and executed. Take the following actions and note what is returned in the supervision report:
Try ticking the radio button “non-secure” and click send. This will send the command without encryption.
Try reverting the security level by select the radio button “default” and delete the trailing two bytes from the “send data” box. Making it an invalid “binary set” carrying no set value.
Try altering the command in the send data to e.g., 25 0A, to send a non-existent command.
At this point you should be familiar with the concept of multichannel devices, know how to ensure delivery of S2 encrypted payloads, and understand the concept of supervision command class.