Home automation comes with plenty of potential to make our lives easier. But in order to succeed in its task, it often requires you to fill your house with bridges that can connect your smart devices to your Wi-Fi network. Unless you buy a smart device that communicates directly over Wi-Fi (like a or ), odds are that many of your favourite smart devices use either Bluetooth, Zigbee or Z-Wave to communicate. These protocols solve some of the issues of Wi-Fi when it comes to smart devices — like latency, centralised topology and relatively high power requirements — but they do require some physical hardware in between to do the smart protocol <-> Wi-Fi translation and make the devices actually controllable from a Wi-Fi-connected client. TP-Link Belkin smart plug The bad thing is that you’ll probably need a different bridge or hub for each class of devices you want to use. Philips Hue lights come with their own bridge, same for Lutron, same for HomeKit, same for Belkin, same for Switchbot, and the list goes on. What’s ironic is that most of these devices actually speak the same protocol (either Zigbee or Z-Wave) but, in most of the cases, they can only control their own devices. Try to imagine an alternative reality where all the ethernet cards can send and receive TCP/IP packets, but you’ll need an adapter just for HTTP traffic, one for FTP, one for SMTP, and so on: that’s more or less the reality today when it comes to smart bridges and hubs. In order to solve the problem, many companies are throwing on the market even hubs and bridges (from Samsung SmartThings, to the plethora of Amazon Echo, Google and Apple devices etc.), often compatible only with a subset of the devices out there and incompatible with one another, often incompatible by design with devices produced by competitors: that only brings even more fragmentation to the current smart home hell. more Moreover, many hubs can usually talk only to their smartphone app, adding an app hell to the bridge hell. One of the most sought goals nowadays when it comes to home automation is (or it should be) to find consistent ways to communicate with as many devices as possible using the same tool, the same box and the same interface. I’ve recently worked on achieving this goal in platypush. Other platforms have tackled the issue too (from HASS.io to Openhab) but, in my opinion, they all still require a certain degree of user configuration (like specifying what each device is and what it’s supposed to do) that in my opinion shouldn’t be required. In this article, we’ll go through what Zigbee and Z-Wave actually are, what you need to set up a universal bridge for them using just a Raspberry Pi and a USB dongle, and how to permanently move your existing smart bridges to the storage room. Zigbee vs. Z-Wave Zigbee and Z-Wave have arguably risen to become the dominant communication protocols in the smart home and IoT industries. They share some common features, such as: 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 networks that can include devices that would otherwise be out of range. mesh When it comes to the differences: : Z-Wave networks are limited to 232 devices, while Zigbee supports up to 65k devices. Number of devices : Z-Wave supports up to four hops between a device and the network controller, while Zigbee has theoretically no such limitations. Maximum hops : 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). Operating 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 range : 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. Signal reliability : 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. Ownership and protocol That should cover most of the knowledge you need when it comes to the theory of Zigbee and Z-Wave. You’ll find many Zigbee and Z-Wave compatible smart devices around. Some examples of Zigbee devices are the Philips Hue and Ikea smart bulbs, Honeywell thermostats, Belkin smart plugs and bulbs, Bosch sensors and Osram products. Z-Wave includes around 65,000 compatible devices out there, including many garage doors, presence and temperature sensors, thermostats, dimmers, remote controls, smoke detectors and so on. Hardware and software We’ll use a RaspberryPi in the following examples as a DIY bridge (any model and any distribution should work fine), and as a home automation platform that also runs the Zigbee and Z-Wave integrations. platypush Making your own Zigbee bridge On the hardware side you’ll need: One or more Zigbee compatible devices, like Philips Hue, Ikea or Osram lights or Belkin switches. A Zigbee-to-USB adapter/sniffer. The is one of the most popular options out there.A Zigbee , that you’ll need in order to flash the firmware on the dongle. CC2531 debugger+adapter cable A RaspberryPi or similar device (any model and distribution should work fine), or any computer that you want to use as a bridge. On the software side: platypush uses as a backend to interact with the Zigbee dongle. Install the zigbee2mqtt firmware on the dongle by following the instructions (for Windows, macOS and Linux) on . You can check a list of the compatible devices .Install, start and enable an MQTT instance on the local machine, if you don’t have a server already running in your network. If you’re running Debian/Ubuntu/Raspbian and want to use Mosquitto, for example: zigbee2mqtt their website here [sudo] apt-get install mosquitto [sudo] systemctl start mosquitto .service [sudo] systemctl enable mosquitto .service Install zigbee2mqtt: [sudo] apt- install nodejs git g++ gcc
git clone http //github. /Koenkk/zigbee2mqtt zigbee2mqtt
npm install data/configuration
# Change mqtt.server serial.port respectively
# your MQTT server USB dongle device.

npm start get make s: com cd vi and to match and You can also make a systemd service out of it: =zigbee2mqtt =network.target =/usr/bin/npm start =/path/to/zigbee2mqtt =inherit =inherit =always =multi-user.target [Unit] Description After [Service] ExecStart WorkingDirectory StandardOutput StandardError Restart [Install] WantedBy Note that the zigbee2mqtt configuration file also includes a permit_join option. Set this to true while you’re pairing your Zigbee devices for the first time, and set it to false afterwards to prevent other devices from accidentally or malignantly join the network — you can always temporarily allow joins later. Once started and in permit_join mode, you can start pairing Zigbee devices to your new network. That is usually done by doing a factory reset of the device. The procedure varies with the device: Philips Hue bulbs, for example, can be reset either from the app (if they are paired to a bridge) or by pressing the ON/OFF buttons of a Hue dimmer simultaneously for 10 seconds while keeping the dimmer within 10 cm from the lightbulb. Other Zigbee devices may include a reset button instead.Once a Zigbee device joins the network, the zigbee2mqtt logs should show a trace like the following: Successfully interviewed '0x 8d dc126a', device has successfully been paired 0015 0001 Install Redis and platypush with the Zigbee, HTTP and MQTT extensions: [sudo] apt-get redis- [sudo] systemctl redis.service
[sudo] systemctl redis.service
pip install server start enable install 'platypush[zigbee,http,mqtt]' Edit your file to enable the Zigbee and HTTP services: ~/.config/platypush/config.yaml backend.http: port: 8008 zigbee.mqtt: host: localhost backend.zigbee.mqtt: enabled: true Start platypush (either by running platypush or starting the platypush.service systemd service).Open in a browser. The web panel should include the Zigbee icon in the navigation bar, you’ll be able to control your network from there. http://host-or-ip:8008/ You can send requests through the over HTTP, Python code or through whichever platypush backend you have configured: supported API curl -XPOST -H 'Content- : application/json' -d '
{ : , : , : { : , : , : }
}' http: # HTTP request Type "type" "request" "action" "zigbee.mqtt.device_set" "args" "device" "White Bulb" "property" "state" "value" "ON" //localhost:8008/execute platypush.context get_plugin

get_plugin( ).device_set(device= , property= , value= ) # Python usage from import 'zigbee.mqtt' 'White Bulb' 'state' 'ON' Or hook any custom logic to the : supported events event.hook.OnLightBulbOn: :
        type: platypush.message.event.zigbee.mqtt.ZigbeeMqttDevicePropertySetEvent
        device: White Bulb
    then:
        - ${properties.get( ) == }:
            - action: tts.say
              args:
                  text: if if 'state' 'ON' "The light went on" Congratulations, you’re now ready to use your Zigbee devices and build automation without bridges! Making your own Z-Wave bridge Making a DIY Z-Wave bridge is even simpler than making a Zigbee bridge, as you won’t need a debugger to flash a custom firmware nor an MQTT service in between. You’ll need a Z-Wave USB adapter dongle. I use , but any compatible dongle should work. Take note of where the adapter is mapped on your system — e.g. /dev/ttyUSB0. this one Install Redis and platypush with the Z-Wave and HTTP extensions: [sudo] apt-get redis- [sudo] systemctl redis.service
[sudo] systemctl redis.service
pip install server start enable install 'platypush[zwave,http]' Configure your integrations in : ~/.config/platypush/config.yaml backend.http: port: 8008 zwave: device: /dev/ttyUSB0 backend.zwave: enabled: true Start platypush (by running platypush or through systemd service) and point your browser to . You’ll see a new tab for the Z-Wave integration.Some screenshots from the Z-Wave web panel. http://host-or-ip:8008/ Each Z-Wave compatible device has its own way of pairing to a network. All you need to do is to press on the + button to put the network in pairing mode and then pair your devices within one minute through the procedure referred in the user manual. Since Z-Wave has a stricter protocol and all the compliant devices publish their values using the same format, the Z-Wave interface is much more granular and detailed compared to Zigbee. You can, of course, send commands to the new network through the and subscribe custom hooks on : available API Z-Wave events curl -XPOST -H 'Content- : application/json' -d '
{ : , : , : { : , : }
}' http: # HTTP request Type "type" "request" "action" "zwave.get_value" "args" "value_label" "Temperature" "node_name" "Kitchen Sensor" //localhost:8008/execute platypush.context get_plugin
get_plugin( ).get_value(value_label= , node_name= ) # Python usage from import 'zwave' 'Temperature' '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 event.hook.OnZWaveValueEvent: :
        type: platypush.message.event.zwave.ZwaveValueChangedEvent
    then:
        - ${node[ ] == value[ ] == value[ ] }:
            - action: tts.say
              args:
                  text: Motion has been detected # Trigger a custom action when motion is detected if if 'name' 'Motion Sensor' and 'label' 'Sensor' and 'data' is True You should now have all the ingredients to build your custom IoT networks and ditch those bridges for good! Previously published at https://medium.com/the-monolith/transform-a-raspberrypi-into-a-universal-zigbee-and-z-wave-bridge-b686cdd1849e

Waves

Amazon

Apple

Garage

Google

Samsung

Target

Trace

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - IoT.

2020 - Hacker Noon Contributor of the Year in IoT

2022 - HackerNoon Contributor of the Year - Distributed Systems

2022 - HackerNoon Contributor of the Year - Git

2022 - HackerNoon Contributor of the Year - Proof Of Stake

Book a call

Nominated for 2022 - HackerNoon Contributor of the Year - Proof Of Stake

Nominated for 2022 - HackerNoon Contributor of the Year - Git

Nominated for 2022 - HackerNoon Contributor of the Year - Distributed Systems

Too Long; Didn't Read

 Add passwordless user experiences to your app

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

HackerNoon Mobile

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

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

@BlackLight

RELATED STORIES