5 ms·

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

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.

oynqr 5y ago
ZHA is still the preferred way for Zigbee with Home Assistant, isn't it?
- EngCanMan 5y ago
  Many people use https://www.zigbee2mqtt.io/ https://www.zigbee2mqtt.io/ now too, it seems people are moving in this direction
- dusing 5y ago
  ZHA is great and fast, I prefer it instead of zigbee2mgtt. I have 100+ zigbee devices and 80 z-wave.
- nathan_f77 5y ago
  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
- specto 5y ago
  Saw this too recently - https://www.cnx-software.com/2021/09/27/zb-gw03-esp32-based-ethernet-zigbee-gateway-now-working-with-tasmota-firmware/ https://www.cnx-software.com/2021/09/27/zb-gw03-esp32-based-..., quite nice
- jhot 5y ago
  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.
cptskippy 5y ago
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.
- thequux 5y ago
  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/ https://www.home-assistant.io/docs/mqtt/discovery/
  - joshspankit 5y ago
    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.
  - cptskippy 5y ago
    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.
parineum 5y ago
> 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.
- EngCanMan 5y ago
  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.
- zerd 5y ago
  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.
  - parineum 5y ago
    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.
    - darkwater 5y ago
      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
- kelnos 5y ago
  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.
SV_BubbleTime 5y ago
>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.

oynqr 5y ago

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

EngCanMan 5y ago
Many people use https://www.zigbee2mqtt.io/ https://www.zigbee2mqtt.io/ now too, it seems people are moving in this direction
dusing 5y ago
ZHA is great and fast, I prefer it instead of zigbee2mgtt. I have 100+ zigbee devices and 80 z-wave.
nathan_f77 5y ago
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
specto 5y ago
Saw this too recently - https://www.cnx-software.com/2021/09/27/zb-gw03-esp32-based-ethernet-zigbee-gateway-now-working-with-tasmota-firmware/ https://www.cnx-software.com/2021/09/27/zb-gw03-esp32-based-..., quite nice
jhot 5y ago
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.

cptskippy 5y ago

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.

thequux 5y ago
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/ https://www.home-assistant.io/docs/mqtt/discovery/
- joshspankit 5y ago
  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.
- cptskippy 5y ago
  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.

parineum 5y ago

> 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.

EngCanMan 5y ago
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.
zerd 5y ago
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.
- parineum 5y ago
  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.
  - darkwater 5y ago
    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
kelnos 5y ago
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.

SV_BubbleTime 5y ago

>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.