Hacker News Reader

Comment by nicolaslem | Hacker News Reader

MQTT is becoming the defacto interface for home automation. As an example, Home Assistant used to have plugins for zwave and zigbee but they are now replaced by an MQTT broker that sits between Home Assistant and the program driving the wireless dongle.

Since I'm already running Mosquitto to interface with zwave devices, I decided to also use it to monitor my home lab. Servers push sensor statuses into Mosquitto and Home Assistant is used for the UI and alerting. That was a fun week-end project.

View on HN

> Home Assistant used to have plugins for zwave and zigbee but they are now replaced by an MQTT broker that sits between Home Assistant and the program driving the wireless dongle

And now, they've moved on from that to having straight websocket communication between those two programs, eliminating MQTT altogether.

I use MQTT for a lot of stuff but it adds a layer of delay between devices that is particularly noticeable with flipping a light switch in the Home Assistant web ui.

This may be a use case issue. I have a zigbee door contact that communicates to HA through Z2MQTT which turns on the light when the door opens. It turns on so fast that my wife didn't believe the light wasn't already on until I made her open the door from the inside. It is instant for all intents and purposes. So this delay may be relevant to the setup, more than MQTT itself.

Are you sure it's MQTT adding the delay? From my experience that part is pretty much instantaneous, but processing though Home Assistant, and in my case zigbee2mqtt does add some delay.

No I'm not certain but I can certainly say that the whole setup is much more responsive after taking MQTT out of the loop.

That's interesting to hear, I would say that most of the latency comes from HA REST API call rather than MQTT (at least if MQTT is local to the zigbee2mqtt installation) but now I want to do some experiments in my setup, even if unfortunately HA native Zigbee HW support is way more limited than Z2M

Is that the MQTT part causing the problem, though? I have a bunch of Z-Wave devices on my network (using openHAB, which drives the Z-Wave hub dongle directly), and response times range from under a half second to several seconds, depending on phase of the moon. I expected that since Z-Wave is a mesh network, pushing commands out to devices that are farther away from the controller could take longer.

ZHA is still the preferred way for Zigbee with Home Assistant, isn't it?

Many people use https://www.zigbee2mqtt.io/ now too, it seems people are moving in this direction

Saw this too recently - https://www.cnx-software.com/2021/09/27/zb-gw03-esp32-based-..., quite nice

I've been happy with the ZHA implementation and haven't tried z2mqtt. I am much happier with zwavejs than the old implementation, though.

I do run MQTT for a few wifi devices and communication between node red and custom client code on my laptop/desktop.

I started with ZHA but had problems with some devices (e.g. a 4-way switch panel that would only show as a single button.) I've had a much better experience with zigbee2mqtt, and it seems a bit more powerful

ZHA is great and fast, I prefer it instead of zigbee2mgtt. I have 100+ zigbee devices and 80 z-wave.

I observed this as well and was just starting to dabble in MQTT with my ESP projects.

I have yet to find a good resource for outlining autodiscovery. Most of the projects I have come across just hard code some pub paths in the homeassistant namespace.

The official docs[1] had everything I needed to know in order to make discovery work for my own hardware; essentially, you're just pushing a config stanza in JSON to a particular MQTT path. The only thing that's not immediately clear from the docs is that the discovery data should either be pushed in retain mode or resent every few minutes, and even though it's optional, you should include a unique_id so that the device can be tweaked in the web UI.

[1] https://www.home-assistant.io/docs/mqtt/discovery/

After being in the trenches on this type of thing: unique_id is officially optional, but HIGHLY suggested.

Personally, I like to use the MAC since it means code reuse, but whatever it is make sure it’s there and unique.

Thanks, that's incredibly helpful.

I don't know what it is about the hassio docs but I have a hard time groking them and quite often find myself looking elsewhere for clarification.

>MQTT is becoming the defacto interface for home automation.

The problem I have with MQTT is also a feature. The payload format isn’t defined, there is no request response structure, encryption of payload requires custom encapsulation, etc. You are on your own for everything.

This is made better in MQTT v5, but AWS still doesn’t support that.

If I was starting over today, I really like OSCORE and CoAP derivatives for their completeness.

Reply on news.ycombinator.com