access to all features offered by a device, not only to those implemented in core integration
ha restarts (frequent due to ha and custom componebts updates) don’t disconnect devices. Restarts of mqtt are practically not needed.
Very low amount of issues. None breaking.
(comparing to many reported by the integration users)
Don’t now any operational. Stability and reliability is second to none.
There might be a need however for manual configuration if device or 3rd party integration doesn’t provide mqtt discovery data. in that case you can provide them manually, use some existing scripts or configure mqtt entities manually in yaml. I found the latter to be the most suitable for me. It gives more flexibility and less dependency. And after initial learning phase it’s a matter of copy paste.
Since zigbee2mqtt provides meta-data for discovery, it’s not the case for it.
tbh to me it’s enough that those separation into specialized components is just a better design pattern. No need to list and compare pros and cons
@maxym - Great, thanks for that. I think I’m beginning to see a little further.
Benefit: Improved system reliability
Are you saying that moving the data acquisition logic from HA integrations to a MQTT integration provides a benefit of a more reliability system?
Access to all device features
Very interesting, you say:
access to all features offered by a device, not only to those implemented in core integration
I suspect I do not understand the context … If a device does not support MQTT then would it provide any additional features (it may provide less (none) as it cannot be used)? Or is the assumption that we are comparing a system using non-MQTT devices with one that only uses MQTT devices?
In my case I use zigbee and wifi devices. What beneificial features am I missing out on? Also, would I get more useful device features if I accessed them via a zigbee-MQTT server? What does MQTT provide that others do not? Note: All of my zigbee and wifi devices get discovered by HA quite well.
I’m not sure how these deliver a benefit though:
independence on HA release cycle.
lower sensitivity on firmware changes
ha restarts …
For example, what does a user see when leaving MQTT running while restarting HA as opposed to not using MQTT and restarting HA? Can you give a use case?
A little more configuration and planning overhead, if the device doesn’t support HA auto discovery. Besides that, none.
MQTT is such an elegant way to manage data flow between IoT devices. My entire home automation system is based on an MQTT backend. It took a while to put everything on it, but I’m finally there now. Everything speaks the same language, over the same protocol. It’s easy to debug and change. Everything is loosely coupled and devices can be switched out and replaced without changing any other part of the system (including HA).
The most important part, HA is not the central piece of my home automation system anymore. It’s decentralized. HA becomes just another device that connects to the MQTT backbone and interacts with the data traffic there. No more problems with breaking changes. No more messing around with dozens of integrations. No more problems with component version mismatches - you can mix and match at will (like zwavejs won’t break anymore when you update HA or vice versa). I could swap out an entire ecosystem of devices and HA would not even notice. It makes things so much more reliable and stable.
Absolutely. It’s also the perfect way to connect multiple HA instances together (with MQTT bridging). I’m currently designing a device that connects the telemetry of my sailboat to my home automation backend, running over NB-IoT and an Iridium satellite link, bridging over a VPS. Everything running on MQTT. I will be able to turn on my bathroom fan while being in the middle of the Atlantic. Technology is awesome
In short, yes.
HayImAlex described the reasons pretty well
I meant features of devices you want to connect to the HA that are not supported by core HA integration.
For example:
Brightness and color of Shelly devices like RGBW2, Dimmer, and bulbs can be controlled even when the light is turned off. While you can achieve that whatever Shelly API you are using (mqtt, http, coap), HA integration doesn’t support that. Having it in MQTT you can control it via native automation or an external one (NodeRed)
Obviously new devices or new features added by the manufacturer must wait for implementation into core integration. With MQTT is not needed. Once those data are in MQTT you can create any entity over that on your own immediately. not being dependent on HA developers.
In the case of Z2M, it seems it has a greater pace of implementing new devices compared to ZHA. And if there is no support yet, there is a way to add it yourself, not wait for the official release.
independence on HA release cycle.
There are two issues with the release cycle:
Each release may break something which worked. And it happens. With MQTT the probability is obviously way lower
You don’t need to wait until the next release for the implementation of new devices, new features, fixes, or in the worse case fixes to what has been broken in the previous release. And there is no guarantee it will be fixed in the incoming version. Depending on devices, how popular they are, how devs are personally after them and their free time/will it might take months.
lower sensitivity on firmware changes
I described it already above. If firmware changes and it somehow impacts the api, you can adapt immediately. If it brings new features, you can start to use them immediately.
If fw brings significant changes to API, core integration has to be rewritten. then GoTo point about dependency on the release cycle.
ha restarts
For example, what does a user see when leaving MQTT running while restarting HA as opposed to not using MQTT and restarting HA? Can you give a use case?
For example, using MQTT and NodeRed, you can still automate things, or collect data even if HA is restarting.
Also restart of HA causes a drop of all managed by HA connections. It’s not a good pattern to disconnect all clients. Especially if it’s not done for sake of upgrading their functionality.
And HA generally requires lot more restarts than MQTT or Zigbee2MQTT
This comment and reply are likely going to make me move to a zigbee2mqtt setup.
I’m currently running a pi with HA in a container. A couple weeks ago, I set up a ProxMox home server with TrueNAS running on it, and I think I’m going to add MQTT/Mosquitto containers to that server. The eventual plan will be to lose the pi entirely.
Nice to know that I can tinker with a HA container on the Proxmox machine without having to decommission my working pi setup.
