#MQTT- Explain like I'm dumb?

1 messages · Page 1 of 1 (latest)

grizzled tree
#

Over the years, I've seen a lot of love for Mqtt and have heard about it on the podcast, etc. Each time I've looked into it, I've had a hard time figuring out how it could benefit me.

I understand that it's a lightweight communication protocol. Where I get lost is where the benefit is to running a separate broker if the devices you have are already communicating via a different protocol (like zigbee, zwave, or another proprietary protocol via TCP/IP with a custom component).

Is there something I'm missing and I should really be diving more into what it does and how it operates? Or should I be ignoring it unless I happen to get a device that uses it, like an esp device I make?

Apologies. Despite using home assistant for around a decade, I seem to still be definitively a newbie.

exotic pawn
#

HA has to be able to communicate with devices in some way. That could be directly through an integration, if one is available, or through some external service. The latter has the benefit of being decoupled from HA, so a restart of one doesn't cause a restart of the other, for instance, and it also allows that external service to be used by other automation platforms. MQTT is an industry standard and generic way to facilitate communication between services, so it's often the choice for IoT. These external services could also communicate over something like the REST API or websockets, but both lock in the client and server into a custom relationship rather than the topic/message JSON-based method that MQTT offers.

#

MQTT also allows for asynchronous communication, where one side can post messages that are received by the other side at some later time. Since both only talk directly to the MQTT broker, issues on either side are further decoupled.

#

Some services support both MQTT and websockets, like ZWave-js, and each project generally has its preferred method. It generally doesn't really matter to the end user how they communicate, but using MQTT does add some moving pieces to the initial setup.

meager bay
#

There are also WiFi devices that can be connected to the mqtt broker directly, rather than using a proprietary cloud system and an integration to get it in a more roundabout way
It can also be useful if you have a mix of devices and protocols as it means you only need mqtt on the ha side of things if they all talk to the broker

grizzled tree
#

Ok so to use say zigbee2mqtt as an example... The advantage to that (or similar) would be that if your zigbee device is offline when the message is sent... It Would wait in queue until the device came online?

#

I do use zwave js. I didn't realize it's also an Mqtt broker

worthy yew
#

Z-Wave JS UI can be an MQTT client, it's not a broker.

grizzled tree
#

Ah ok

#

Would you typically program in timeouts with Mqtt then? Because you likely wouldn't want messages to pile up and then batch run on a device if for some reason it was offline for a while and then came back on and there were a lot of messages in queue

exotic pawn
#

It's really whether they're retained or not. There are many, many options that are standardized in the MQTT spec (4 or 5 or whatever)

grizzled tree
#

Ok. Thank you for your help.

I think I will have to continue to do more reading when I can find time. I still have a hard time understanding the benefit of using an Mqtt broker, unless any of my devices "speak" it directly. I can understand decoupling when it can continue to allow devices to communicate if HA goes down. But if the full functionality in my case would require HA to both send and receive messages for any utilization, I'm thinking the only advantage would be the asynchronous messages.

exotic pawn
#

I, for instance, appreciate that HA can retrieve all my Zigbee devices and their current status from the broker when it starts up. You could build that whole bespoke interface with the Zigbee service, but it already exists in MQTT

#

The trend is generally toward tighter integration when there's a will and people to do the work, but you lose the cross platform aspect of it unless everything else implements the same protocol