Zigbee2mqtt Hub

[Tarja Hempton]

Theres no denying that IKEA and Xiaomi make some enticing devices, but for whatever reasons may exist, the fact remains that they're unsupported on our platform of choice and incredibly difficult to reliably integrate with Hubitat directly, even with custom drivers. Others and myself have tried and burned many hours in the process.

Until fairly recently I had no idea what MQTT was, or why I'd want to use it. That changed with my Hildebrand Glow driver for UK smart metering, which relies on it entirely. Once I understood that MQTT is essentially just a very quick and lightweight network messaging system and that support is already built-in to Hubitat, what Zigbee2MQTT might mean became painfully clear. It's right there in the name. Take in Zigbee radio messages, send them out via MQTT to your network.

My previous solution was to run an extra Hubitat hub just to keep my Xiaomi buttons happy on their own Zigbee mesh. Sadly, though these pernickity devices liked the C5 and C7, they didn't like my new C8 and harmony in the household was diminishing rapidly.

Now that I knew what Zigbee2MQTT was for I searched for the community app which was sure to be out there, and was surprised that what is quite a simple integration didn't already exist. Necessity being the mother of invention, here's my take on a Zigbee2MQTT Routing Driver.

Search for the keyword "general" on Hubitat Package Manager and you should see "General Drivers from BirdsLikeWires". Requires HPM v1.8.7 or later. Or install manually using the links below.

You will need to install the matching IKEA or Xiaomi device drivers, which are used by the child devices to interpret the MQTT messages and convert them into Hubitat events. Some of these are combination drivers, supporting a direct Zigbee connection (if that's working for you) and MQTT messaging in one.

The Zigbee2MQTT driver connects to the MQTT broker, to which your Zigbee2MQTT installation is publishing messages. It watches out for device models it recognises and automatically generates or updates a child device in Hubitat with the correct driver and passes on the MQTT message. You can use that child device just as you would any normal device.

There are great instructions on the Zigbee2MQTT website. Essentially, you need some sort of computer you can leave on all of the time and a Zigbee dongle. Any Raspberry Pi, even the oldest, would be more than capable.

One important thing! Under Settings > MQTT you must tick the "Include device information" option near the bottom of the page. Otherwise... well, there's not enough device information for things to work.

I've now been running this since March 2023 and it has been almost perfect (completely flawless since April). I even moved the installation from a Mac mini to a Raspberry Pi and it continued to work without a hitch.

No.. except that I created a username and password for MQTT in my HA, but probably the Mosquitto broker is not configured properly.. I have not used it for more than an year and I have forgot everything

@birdslikewires is it possible to provide some instructions to non groovy programmers (like myself) as to how to add other devices? I haven't looked at the library bundle but can more attributes be added?

Operate each action that the device can make and note the "Payload" messages being received. For each action, copy the payload message into a text editor, one line for each and when you have them all, paste them in a message here (using ``` tags at the start and end of the messages to keep the info readable).

Devices which can themselves be controlled are not something I'm working on right now, but it's possible in the future. And there's no way I can write drivers for every device Zigbee2MQTT can support - in that case you'll need...

Create a driver in the usual manner with the correct attributes, commands and methods to support it. You'll then need a processMQTT method which maps the incoming actions to Hubitat events. That's really about it.

You first need to install the library under "Libraries code" on the navigation bar, then install the driver in the usual "Drivers code" page. The instructions for that need to be clearer in the first post.

We have on one hand a piece of hardware (HE) with a zigbee radio and some software (HE OS?) to manage it. On the other hand, another piece of hardware (say, a Pi), a zigbee radio in the form of a dongle and some software (zigbee2mqtt). I fail to understand what are the material differences between the two up to this point (of course HE goes much further up the stack).

I'm interested because I own several Aqara devices and would like to be able to get some of those cheap IKEA devices, but I am way less interested in having to manage yet another Tamagotchi in my house... (one of HE's main selling points for me, as it hits the sweet spot 99% of the time)

Here I have a very easy answer: zigbee2MQTT is an open-source community project with at least several hundred of active contributors, that reverse-engineer non-standard (and not documented anywhere!) Zigbee devices from Ikea, Aqara, Tuya, and many other brands. This is probably 100 times more than the developers who make drivers for Hubitat. It is practically not possible to catch up with the new device manufacturers that pop up every month from China.

Of couse you need to replace the variable $hostport with the host port you want to publish the container port to and replace $containerport with the container port the application is listing on inside the container (please use the exact ports as refered in the images description here).

I am not entirely realy sure what you mean. But is still try to give it a shot: If you bind a host folder into a container folder, no redirect takes place, the host folder is simply mount additionaly into the specified container folder. The process inside the container of course must use the container folder!

I looked in to the logs, thanks for the tip, and I see that there are a few issues.

Especially regarding the redirects. You can see the docker run command I published in my earlier message, which should redirect the moquitto folder and the sub folders below. they should be pointing to the /docker/mosquitto/ (log, data, config) in the config folder I created the mosquitto.conf file, but I think the container is looking at another path.

You can see the docker run command I published in my earlier message, which should redirect the moquitto folder and the sub folders below. they should be pointing to the /docker/mosquitto/ (log, data, config) in the config folder I created the mosquitto.conf file, but I think the container is looking at another path.

If you have host folder /a and bind it into container folder /b (using -v /a:/b), whatever you put on the host in /a, will be seen in the container /b and the other way arround. The left hand side before the colon is always the host side, the right hand side after the colon is always the container side. Please always use the container side as written in the image description, as the applicaion usualy is prepared to work with those pre-defined folder - unless you know exectly why you are doing it differently and how to configure the application inside the container to work with the modified location.

You have to use the container paths, not the host paths, as the continer is an isolated environment and knows nothing about the ressources of your host. Is it realy valid that you declare two listeners in the conf file?

You might be right about that, I think the only container with a frontend is the zigbee2mqtt container. I adjusted the port mapping as suggested. so all seems to be ok. Although still no frontend. I need to dive into the container configuation. thanks for the support!

Unstable Zigbee behavior in Homey. Unfortunately my Homey Pro 2019 has issues in keeping a stable Zigbee network connected. I even have to reflash my Homey every once in a while to get the Zigbee chip working again . With Zigbee2MQTT I have the possibility to flash the latest firmware to my Tuya smartplugs, which significantly improves network behavior. Secondly, using Zigbee2MQTT on a RPi with a Zigbee dongle, just works a lot better for me!

Why is my device not (fully) supported?

The current version supports basic devices like window/door contacts, power plugs, thermostats, basic lights and basic sensors.

Do know that I mainly built this app for my own use, but I added generic device mapping so that others can enjoy it too. At this time I do not intend to put an extreme amount of effort in adding support for more devices. If you are a programmer you are more than welcome to do a pull request on Github. But to really add a device to the Homey app, I need to have my hands on it and tinker around with it. So, if you are willing to donate the device, I am willing to put in the extra effort to integrate it. When you want to donate a device, send me the funds to buy one (including shipping to NL).

But I am also trying to make the interface as generic as possible. That means I am introducing a way to automagically map device properties from Zigbee2MQTT to Homey capabilities. So other door/window sensors and smart plugs (not Tuya) have a probability to also work out of the box.

Adding more types of devices/capabilities to the app should be relatively easy, but the mapping method surely has its limitations.

See 4 posts up. I can only test with my own Tuya devices at the moment. But you should at least get the link quality for any device paired with zigbee2mqtt.

You do have your devices already paired in zigbee2mqtt right?

You need to add the bridge first, and then you can add the zigbee devices that are connected to the bridge. During pairing it should find all the devices, but only few capabilities are supported at the moment.

3a8082e126