On and Off

To turn on the energy switch, Listing 1 sends a byte sequence of 0x00 0x13 as the payload, followed by the node number for the target device to the PC's USB port interface. The protocol then needs 0x03, 0x20, 0x01 followed by the switch's dimmer setpoint (0=off, 255=on) and by a byte with a value of 0x05.

As you can see in the output in Figure 5 from switching on and off, the CPAN module creates a packet from the payload by prepending a header with a value of 0x01, followed by the number of following bytes, rounded off by a checksum (0x3e or 0xc1; Figure 5). The Z-Wave protocol computes the checksum by XORing all the bytes in the packet, but without the first header byte.

Figure 5: The script in Listing 1 controls a Z-Wave consumer (on/off) and also prints out the bytes transmitted.

The checksum is then negated and appended to the packet so that the receiver can check the message for bit flips in the wireless transmission. The checksum is one of the protocol's weak spots; given only 255 different values and the simple logic, it is unable to detect more than the most simple error conditions.

The script in Listing 1 initializes Log4perl with a log level of $DEBUG, which explains why the bytes are printed out. If you don't do this, the whole process is non-verbose.

Handshake for Reliability

One positive aspect of the Z-Wave protocol is the handshake method where the receiver always returns an ACK packet to the transmitter to tell it that the message arrived and the corresponding action was triggered. If the controller is switching on a water pump, the application will almost certainly want to know whether the action succeeded and the valve is now open or whether something has gone wrong, so it can take corrective action if necessary.

Z-Wave can do much more than just switch consumers on and off, however. The energy switch can be configured to transmit packets regularly that show how much power is currently crossing the wire. The control software can thus trigger actions, keep track of them, check the power consumption and how much it costs, and – if needed – alert you if the switch was manually unplugged and stopped sending reports.

Lock and Key

Additionally, some Z-Wave sensors and actuators can even do without a mains power source – for example, you can purchase wireless door locks. To avoid the battery discharging too quickly, the Z-Wave protocol needs to make sure that the lock repeatedly wakes up, checks whether a signal is present, and goes back to sleep immediately if there is nothing on the airwaves. If it does discover a signal, however, the electronics start to investigate. If the signal comes from a controller that it trusts, the actuator responds to the transmitted commands. Z-Wave also extends a controller's range with a routing protocol that gives other Z-Wave components the ability to forward the signal until it is in range of the target actuator, which can then respond.

For further reading, you might like to pick up Z-Wave Basics: Remote Control in Smart Homes. This must have been written by a German author – no one else would print the details of their PhD on the spine – and some Amazon reviewers have complained about various grammatical errors and strange language. It's true and should have been corrected, but it's worth a read anyway. The Kindle version has been updated compared with the paperback edition and contains some revised chapters [8].

The book describes the historic development of the protocol and discusses the advantages and disadvantages of competing approaches. Specialists will enjoy the precise descriptions of the technical details of the protocol, although the book does not discuss the individual byte sequences. You will either need to contact the Z-Wave distributor, Sigma Designs, and purchase the SDK for these, or try the free OpenZWave [9] project.