This project is based on Home Assistant, my instance uses both Wi-Fi, Zigbee and Z-wave devices.
In this article, I explain how I used Node-RED to control a z-wave outlet from a zigbee button. The article is mostly a good starting point to demystify the “magic” operated by Home Assistant to make hardware talk to each other.
Nevertheless, this article does not explain the configuration of z-wave / zigbee networks and devices.
In this diagram we have the 4 main networks used:
- Wi-Fi : Wireless network between the Wi-Fi router, a smartphone and the Sonoff Wi-Fi / zigbee bridge;
- Zigbee : Wireless network for the Sonoff zigbee button and the Sonoff bridge;
- LAN : Wired network between the Wi-Fi router and the Home Assistant server;
- Z-Wave: Wireless network for the Z-Wave connected socket and the Z-Wave UZB dongle.
Despite the diversity of the networks, we see that the common point is the Home Assistant server. Its job in this scenario is to convert the commands of the Sonoff button in order to change the status of the Z-Wave plug: on/off.
This seems quite complicated to simply change the status of the outlet, it is true that we can do simpler by using only Zigbee or Z-wave hardware … or even a RF433 outlet. However, this is the simplest configuration to illustrate how to connect everything, which is the purpose of this article.
We will see below how Home Assistant, thanks to Node-RED, converts Zigbee commands to Z-Wave.
Beyond the Home Assistant server, you need to create four separate networks: LAN, Wi-Fi, zigbee and z-wave.
My detailed articles are not yet available in French, here is for the zigbee bridge.
Note : It is quite possible to use zigbee / z-wave dongles directly on the Home Assistant server, but I try as much as possible to decouple the hardware from the Home Assistant server (especially since it is a virtual machine hosted in a corner of the garage, the reception is not great).
LAN : The backbone of any network
You most likely already have a LAN network, the most basic form is a computer connected by cable to the modem of your internet provider. Since the ports are counted on the modem, you will most likely need a switch for additional outlets.
Warning: Gigabit (1 Gbps network, i.e. 1000 Mbps) is now widely available. With internet speeds exceeding 100 Mbps, it is essential to take gigabit equipment.
If you plan to upgrade your network, remember to provide enough free ports on the switch (8 ports is a minimum, 16 ports is recommended).
Wi-Fi network: Home Assistant and the Sonoff bridge
Let’s start simple, a classic Wi-Fi network. I advise you to use good hardware if you have a basic modem/router from your internet provider.
In particular, I use two Ubiquiti UAP-AC-LR Wi-Fi access points. The suffix “LR” stands for “Long Range”, this is a guarantee for the quality of your Wi-Fi. These antennas manage to push the signal to the middle of the garden by crossing half of the house (~5m inside the house and 25m outside). They are also excellent for supporting many devices, be it smartphones, PCs or ESP8266 devices. Best of all, they are also POE (Power Over Ethernet) so you can place them anywhere you want with just a network cable (power is supplied through the network cable!).
To use POE, you will need to use the “injector” provided (it adds power to the cable) or a POE compatible switch. A compatible switch is more expensive but greatly simplifies the installation.
Warning: Most POE switches only offer POE on half of the ports. An 8 port POE switch probably only has 4 ports providing the famous POE.
Zigbee network: Sonoff bridge and Sonoff button
Here is a specialized network that you may have never met. Zigbee is a low power network for home automation equipment.
By its nature, the bridge is necessarily Wi-Fi and this implies that you can place it wherever it is needed. Although this example only uses a button, for a larger network it may be necessary to add “relays” (zigbee devices plugged into the 220v like a connected plug).
There are a lot of zigbee devices, from simple buttons to thermometers, shutter controls, motion detectors and so on.
Z-Wave network: Z-Wave bridge and Z-Wave plug
Similar to zigbee, it requires another hardware incompatible with zigbee.
As this part uses a 220V socket, it is also a relay of the Z-Wave network. Several outlets can talk together to cover your entire area. Even if you don’t use them in some places, it’s still a good idea to buy some in batches to place them in areas where the coverage would be less good.
Node-RED is a graphical tool for linking hardware, entities, logic and more by connecting them with virtual wires. These wires allow elements to be wired together, which makes messages flow from one to the other and trigger events without (almost) writing code.
We will use this tool to listen to zigbee messages, interpret them into commands and send them to the concerned Z-Wave devices.
To know how to install it, I refer you to the Home Assistant and Node-RED addon documentations.
When an event occurs, such as the pressing of a button or the change of value of an entity, a message is sent to the place where the event has been detected. This message contains several pieces of information, the most important of which is the “payload” (the body of the message).
It is by intelligently circulating (well, as much as possible) these messages that “we program in Node-RED”.
What is a Flow?
In Node-RED, elements (nodes) are grouped into tabs called Flows. It is possible to turn a whole Flow on or off, which is handy for organizing and easily testing things.
The basic nodes
Sending a message manually
In order to discover the nodes, let’s start simple by manually sending a message to the debug console.
We’ll need an Inject node, which is like a button in the flow, and a Debug node that will send the received message to the debug console.
Let’s look at the flow and configuration for our two nodes:
- “Inject” node: Its role is to send in the flow a message, we assign it the value “Our Paylo4d”;
- “Debug” node: Its role is to read any message and send it to the development console.
- Création du flow
By clicking the button to the left of the Inject node, the message will appear in the development console.
Sending a message based on a zigbee device
Now that we “see” the messages passing, let’s try to send the message when we press the Sonoff SNZB-01 button.
The button, connected to the zigbee bridge, triggers an event thanks to the Zigbee integration and the “ZHA” (Zigbee Home Assistant) mode.
Each button being unique, we need to retrieve the code of this specific button.
To do this, we need to listen to the events, press the button and find the event containing the code of the button.
Once this code is known, we have to integrate it in a filter in the output of the ZHA events.
Listening to zigbee messages
To listen to the zigbee messages, we use a node of type “Events”, the event type is zha_event.
Interpreting zigbee events into commands
Warning : Use the “Debug” node to know the codes used by your devices. The device identifier is included in the message under msg.payload.event.unique_id.
As each button will have a unique identifier, it is necessary to route the message to the right nodes. The easiest way to do this is to use a “Switch” node. Each configuration line creates an exit point on this node.
In my case, the button “1” uses identifier 00:12:4b:00:22:42:58:32:1:0x0006.
It remains to verify that it is a button, the command sent under msg.payload.event.command must be “toggle”.
Calling a Home Assistant service
Now that the button is wired, we need to use its message to change the state of the Z-Wave plug from on to off and vice versa. To do this, we will use the Home Assistant service switch.toggle. This will toggle the socket between ON/OFF. It is therefore not necessary to know the current status of the socket.
The whole being put back together, here is the finished Flow, congratulations!
This simple example demystifies Node-RED and the apparent complexity of heterogeneous systems. My key to understanding all this is to imagine the messages flowing between the nodes.
At first sight, the messages seem basic because the “payload” attribute is the most visible one, so I had to explore the details of the message by using a Debug node to display all the attributes.
Finally, here is my material “in real conditions”.