Getting up and running with zigbee2mqtt and a CC2652RB stick

The background here is that I have a large number of Xiaomi Aqara/Mijia sensors that I used on Hubitat with @markus’ drivers. Because it appears unlikely he can continue maintaining his drivers and Keith Gaumont (@veeceeoh) has pretty much abandoned his, I had moved my Xiaomi sensors to two Mijia Smart Home Gateways (model DGNWG02LM). This older model doesn’t have HomeKit access and also doesn’t support zigbee 3.0 devices. However, it does expose a local LAN connection, and there are direct integrations of this gateway to Node-RED (which I use for automation), and also Home Assistant. In addition, @fison67 has written a Docker-based integration to bring devices paired to this gateway into Hubitat/SmartThings.

This approach worked, but I felt I just had a proliferation of zigbee coordinators in my small townhome (2 Hubitats, 2 Mijia gateways, 1 Almond 3). And it also didn’t support newer zigbee 3.0 Aqara sensors. So about 2-3 weeks ago, I decided to setup zigbee2mqtt, and if it worked, transition to it.

I have now moved all my Aqara devices and a few Hubitat-connected devices to zigbee2mqtt, and this (lengthy) post is a description of that move.

Hardware:
I am running zigbee2mqtt on bare-metal Linux. In my case, a headless Odroid-N2 running Armbian Buster. This same hardware runs every else I have that is network or IoT related, including Node-RED.

Zigbee2MQTT supports a variety of adapters that range in price from $5 and up. I chose slaesh’s CC2652RB stick. Inclusive of shipping, it was about US $40, and came pre-flashed with zigbee 3.0 coordinator firmware. It is claimed to directly support 100+ zigbee end-devices, and off course, even more with zigbee repeaters/routers. This stick has a replaceable external antenna (more about that later). The specific stick I got is the “type 1” stick shown below:

It is recommended to keep the stick far away from the computer running zigbee2mqtt, so I have it connected via a 6-foot USB extension cable.

Software:
Zigbee2MQTT has built-in support for Home Assistant, which I don’t use. I installed zigbee2mqtt using the instructions for bare-metal Linux. The directions were really simple to follow. The only difference is the location of the serial device (zigbee adapter). It is /dev/ttyUSB0 with Buster vs /dev/ttyACM0 with Raspbian.

There are also multiple sets of zigbee2mqtt nodes for Node-RED, which off course require an MQTT server. I am already using Mosquitto for other purposes including geolocation with OwnTracks; Mosquitto runs on the same Odroid N2 as zigbee2mqtt (and Node-RED). The most elaborate I found was node-red-contrib-zigbee2mqtt-devices. I ended up using a substantially simpler set of nodes called node-red-contrib-zigbee2mqtt, which as it turned out - work really well for my needs.

There are also a few Node-RED dashboards built for zigbee2mqtt that are convenient (see screenshots below). I use one called Zigbee2MQTT Admin. Zigbee2MQTT also has a built-in web-based frontend, but I have entirely used just the dashboard linked here.

The node-red-contrib-zigbee2mqtt palette provide the following 4 nodes:

The bridge node controls zigbee2mqtt - it permits pairing, removing a device, giving devices friendly names, and also provides a map of zigbee network.

The in node provides state changes from devices (eg. contact open/close, motion active/inactive, color change etc. etc.).

The out node controls device state using msgs. Multiple changes are possible using JSON formatted payloads.

Finally, the get node obtains device status on demand.

It is recommended to set pairing to be false (i.e. off) in the zigbee2mqtt configuration file (/opt/zigbee2mqtt/data/configuration.yaml), and then turn it on/off as needed using MQTT messages, the device node, the built-in web frontend, or the very convenient Zigbee2MQTT Admin dashboard shown here:

This dashboard has several panels. Pairing can be turned on/off from the Bridge configuration panel. Devices can be named/removed using the Device management panel. Details about individual devices can be seen in the Device details panel by clicking on the device in the Device list panel.

It took me just a few hours to move all my Aqara/Mijia devices to zigbee2mqtt. I started out by moving 6 Tradfri repeaters, 4 Tradfri outlets, and 2 Innr plugs - all of which are zigbee 3.0 devices and can function as repeaters/routers for the Mijia/Aqara devices that I have.

I configured zigbee2mqtt so that each device node shows the % battery life reported, along with the last time the device communicated with the CC2652RB coordinator (the USB zigbee stick). The device nodes look like this:

It has been about 3 days now - there haven’t been any devices that have dropped off. The network topology can be displayed by the dashboard (using the Bridge configuration panel) using a few different methods. Here’s what it looks like using the “fdm” graphical output:

The coordinator is in red, the routers/repeaters are in blue, and the end-devices are in pale yellow.

Maps can be zoomed into display details of each device (see below). Maps drawn with the “Circo” display are somewhat more useful and can indicate the router used by each device.

Here’s a zoom in of the Circo map just focused on the coordinator and routers:

The LQI (link quality) for each link is indicated along the line connecting the two devices.

Finally, because link quality and the last time a device is seen by the coordinator are included in messages generated by the “get” node, I use sequences like the one shown below to notified when link quality drops below 30 or when a device hasn’t been seen for more than 4 hours.

Link quality is sent as msg.payload.linkquality and the last time a device is seen is sent as msg.payload.last_seen as epoch milliseconds.

I calculate the difference in time using the epoch sent by the cronplus node and then divide the output by 60000 to obtain the time in minutes.

So far, in 4 days, nothing has fallen off. It has been very simple to map zigbee2mqtt devices into Hubitat devices that I use in my Node-RED automations. I have removed both Mijia bridges, the Almond 3, and will soon coalesce all the remaining zigbee devices I have on Hubitat onto a single Hubitat. I can’t put these devices, like Iris v2 outlets on zigbee2mqtt because they can’t function as routers/repeaters for Xiaomi devices.

All-in-all, this move was quick and there wasn’t much pain associated with it!

12 Likes

Great write-up! The only thing I didn’t see was measured response time. Do you have numbers for motion lighting?

2 Likes

I’ll get some. But there’s no noticeable change. It was fast, and still is fast!

2 Likes

Here are some numbers:

sensor (z2m) -> automation(NR) -> zigbee plug (z2m)
Consistently under 80 ms

sensor (z2m) -> automation(NR) -> zigbee plug (hubitat on same switch as the odroid n2 running z2m and NR)
Consistently between 110-130 ms

sensor (z2m) -> automation(NR) -> Caseta switch (Caseta Pro bridge same switch as the odroid n2 running z2m and NR)
Consistently between between 110-120 ms

2 Likes

Much faster than my 400-500ms!

2 Likes

I have been pretty impressed with this setup. I just discovered that Touchlink devices are supported by zigbee2mqtt. So I finally can use my Lutron Connected Bulb remote for something again!

2 Likes

I’m thinking my automations will be much faster with CC but since that’s aways off I’ll consider going the path you’ve laid out here.

2 Likes

Nice write up. Did you buy it pre soldered? And what is the difference?

Also, why 2db, not 3db?

1 Like

I actually asked for the 3dB antenna. He shipped the 2 dB version. It came ready to use. And, I forgot to add this, but I also ran it for a few days hooked up to a 14 dBi directional 2.4GHz antenna that I mounted to the apex of my attic pointing downward. That also worked. Here’s what it looks like:

I quit using it because once I got a mesh working, I didn’t need it.

1 Like

Great write up. This is something I’d definitely do as well if I needed to move away from HE sooner. Thanks for publishing this for all to consume.

2 Likes

Thanks @aaiyar
Great write up.
I too have a few aqara contact sensors which of late have been dropping off the network far too often.

This is something I will have to look into a lot more
Cheers

2 Likes

For zigbee2mqqt do you need drivers, like HE?
Also, what’s the deal with soldering? I cant figure out why one would want or not want it soldered?

Nope. The list of supported devices is huge, and it is possible to add support for new devices using the output from debug logs.

That’s only if you purchase a CC2531 stick that hasn’t been flashed with the appropriate firmware already, and don’t want to purchase a CC debugger to flash it (which would add ~$10 to the cost of the CC2531).

I purchased a CC2652 stick that was pre-flashed with the appropriate firmware. It did cost ~$40 (shipping included), but is more capable than a CC2531.

2 Likes

I guess the only downside is that there’s no google integration, as there is with Hubitat. Well, there might be for $5 a month.

Great write up @aaiyar. Quick question - is there some way to expose these devices to Homekit (via Homebridge or something)?

Yes!

Using the set of nodes linked below:

1 Like

@rakgupta

Rakesh - weren’t you a Wink user? Did you have any Lutron Connected Bulb Remotes?

Because zigbee2mqtt supports inbound zigbee group messaging, the Lutron CBRs are a supported device and work well. I set mine up last night.

I was a Wink user but have the Lutron plug-in dimmers with Pico remotes. I don’t think the Pico remotes work without the Pro bridge (at least with HE), right? Currently, they are sitting in a drawer :pensive:

1 Like

Not with Home Assistant either (although the dimmers themselves will work with Home Assistant even with the non-Pro bridge). Picos do make excellent button controllers - I would suggest keeping an eye out for eBay listings for the Pro bridge. I got one ~2 years ago for ~$75, and sold my non-Pro bridge for ~$40.

1 Like

@aaiyar THIS is a wonderful write up. So innovative.

2 Likes