How to Transform a RaspberryPi Into a Universal Zigbee and Z-Wave Bridge

Zigbee vs. Z-Wave

• They are better suited for low-powered devices. Wi-Fi is a relatively power-hungry protocol, needs to deal with packet losses, relies on a centralised topology, and isn’t ideal for communication with devices that can be asleep for a long time because of its high overhead on reconnection. Zigbee and Z-Wave have instead been designed to work well with low-powered devices, be low-latency and optimized for sending less bytes on the network. Some Z-Wave or Zigbee devices can theoretically run on the same battery for a couple of years; a similar Wi-Fi device won’t usually last more than a couple of days.While Wi-Fi networks are usually configured using a star-based topology (one access point/router in the middle and all the devices connect to it), Zigbee and Z-Wave have been designed to support more flexible topologies.
• Each device can be both a client and a repeater on the network, each can directly connect to other devices and expand the network with no need to introduce further routers or access points. This allows the creation of scalable mesh networks that can include devices that would otherwise be out of range.

• Number of devices: Z-Wave networks are limited to 232 devices, while Zigbee supports up to 65k devices.
• Maximum hops: Z-Wave supports up to four hops between a device and the network controller, while Zigbee has theoretically no such limitations.
• Operating range: Most Zigwave devices operate around the 2.4 GHz spectrum — although some specific devices also use 784 MHz in China, 868 MHz in Europe and 915 MHz in the US and Australia. Z-Wave devices instead operate around the 850–900 MHz range (at 868.42 MHz in Europe, at 908.42 MHz in North America and other frequencies in other countries depending on their regulations).
• Signal range: A thumb rule when it comes to electromagnetic waves is that, at fixed transmission power, the higher the frequency the lower the range. It means that Z-Wave devices, which operate at lower frequencies, have usually a longer range compared to Zigbee. An unobstructed Z-Wave signal can travel up to 100 meters outdoor, although a common guideline is 30 meters indoor for unobstructed signals and 15 meters if there are walls in between. The indoor range for Zigbee is instead usually limited around 12 meters. However, Zigbee networks theoretically support an unlimited number of hops between the nodes and the controller, so the range can be easily extended by adding more nodes to the network.
• Signal reliability: Z-Wave has a longer range than Zigbee. It means that, at a fixed distance, its signal is usually more reliable. Moreover, Zigbee operates in the relatively “quieter” 800–900 MHz spectrum, therefore it doesn’t have to share the crowded 2.4 GHz spectrum with Wi-Fi and Bluetooth devices. That overall leads to more reliable communication.
• Ownership and protocol: Z-Wave is a proprietary technology developed and maintained by Sigma Designs. Sigma (acquired by Silicon Labs in 2018) owns the protocol, licenses the compatible devices and runs the Z-Wave Alliance, and grants certifications to the devices that comply with the standard. Its selling point is, in my opinion, the strong enforcement of a shared protocol both on hardware and software side. Each sensor, configuration value or switch is defined by a variable type, a range, a read-only vs. read-write policy and a structured representation that applies to all the compliant devices. That makes it very easy to develop consistent interfaces that can comprehensively represent and control any device as long as it speaks Z-Wave, even if the implementation doesn’t know exactly which device it is. Zigbee, on the other hand, is an open standard maintained by the Zigbee Alliance. It also has a certification process in place, but that comes in two parts — one part certifies the hardware, the other certifies the software. It is possible to produce Zigbee certified hardware even if the software isn’t certified nor compatible with other clients. While this makes the protocol much more open than Z-Wave, it also makes the task of writing an all-purpose interfacing software much harder, as different devices may name their properties following different conventions.

Hardware and software

Making your own Zigbee bridge

• One or more Zigbee compatible devices, like Philips Hue, Ikea or Osram lights or Belkin switches.
• A Zigbee-to-USB adapter/sniffer. The CC2531 is one of the most popular options out there.A Zigbee debugger+adapter cable, that you’ll need in order to flash the firmware on the dongle.
• A RaspberryPi or similar device (any model and distribution should work fine), or any computer that you want to use as a bridge.

[sudo] apt-get install mosquitto
[sudo] systemctl start mosquitto.service
[sudo] systemctl enable mosquitto.service

[sudo] apt-get install nodejs git make g++ gcc
git clone https://github.com/Koenkk/zigbee2mqtt
cd zigbee2mqtt
npm install
vi data/configuration
# Change mqtt.server and serial.port to respectively
# match your MQTT server and USB dongle device.

npm start

[Unit]
Description=zigbee2mqtt
After=network.target

[Service]
ExecStart=/usr/bin/npm start
WorkingDirectory=/path/to/zigbee2mqtt
StandardOutput=inherit
StandardError=inherit
Restart=always

[Install]
WantedBy=multi-user.target

Successfully interviewed '0x00158d0001dc126a', device has successfully been paired

[sudo] apt-get install redis-server
[sudo] systemctl start redis.service
[sudo] systemctl enable redis.service
pip install 'platypush[zigbee,http,mqtt]'

~/.config/platypush/config.yaml

backend.http:
    port: 8008
zigbee.mqtt:
    host: localhost
backend.zigbee.mqtt:
    enabled: true

# HTTP request
curl -XPOST -H 'Content-Type: application/json' -d '
{
  "type":"request",
  "action":"zigbee.mqtt.device_set",
  "args": {
    "device":"White Bulb",
    "property":"state",
    "value":"ON"}
}' http://localhost:8008/execute

# Python usage
from platypush.context import get_plugin

get_plugin('zigbee.mqtt').device_set(device='White Bulb', property='state', value='ON')

event.hook.OnLightBulbOn:
    if:
        type: platypush.message.event.zigbee.mqtt.ZigbeeMqttDevicePropertySetEvent
        device: White Bulb
    then:
        - if ${properties.get('state') == 'ON'}:
            - action: tts.say
              args:
                  text: "The light went on"

Making your own Z-Wave bridge

[sudo] apt-get install redis-server
[sudo] systemctl start redis.service
[sudo] systemctl enable redis.service
pip install 'platypush[zwave,http]'

~/.config/platypush/config.yaml

backend.http:
    port: 8008
zwave:
    device: /dev/ttyUSB0
backend.zwave:
    enabled: true

# HTTP request
curl -XPOST -H 'Content-Type: application/json' -d '
{
  "type":"request",
  "action":"zwave.get_value",
  "args": {
    "value_label":"Temperature",
    "node_name":"Kitchen Sensor"
  }
}' http://localhost:8008/execute

# Python usage
from platypush.context import get_plugin
get_plugin('zwave').get_value(value_label='Temperature', node_name='Kitchen Sensor')

# Example output
{
    "type": "response"
    "target": "http",
    "response": {
        "errors": [],
        "output": {
            "command_class": 49,
            "data": 26.799999237060547,
            "data_items": "Read only",
            "genre": "User",
            "index": 1,
            "is_read_only": true,
            "is_write_only": false,
            "label": "Temperature",
            "node_id": 3,
            "type": "Decimal",
            "units": "C",
            "value_id": 72057594093256722
        }
    },
}

# Trigger a custom action when motion is detected
event.hook.OnZWaveValueEvent:
    if:
        type: platypush.message.event.zwave.ZwaveValueChangedEvent
    then:
        - if ${node['name'] == 'Motion Sensor' and value['label'] == 'Sensor' and value['data'] is True}:
            - action: tts.say
              args:
                  text: Motion has been detected