MQTT: why would I use it?

Configuration
1

I see people mention MQTT a lot. It’s really unclear to me why I would want to use it.

Some generic questions to get started:

  • What are the conditions under which you decide to use it?
  • What benefits does it provide?
  • From an uninformed viewpoint, it seems like a lot of extra mental overhead when developing automations. Is this fair or something you don’t really think about?

NOTE: The component page for MQTT really doesn’t explain anything either. Maybe someone could help expand it?

8 Likes
2

Mqtt is a protocol by which things speak to each other. Like Zwave or zigbee or whatever. You use it when you want homeassistant to speak to a device via that protocol.

2 Likes
3

So, I get that… but home-assistant automations and/or node-red can do this for you. Are there devices that only use MQTT? (It seems like not, because I’ve never seen any such device that only uses it). So, if not, why would you want to use MQTT instead of something else that’s already available?

2 Likes
4

How are homeassistant and nodered speaking to the mqtt devices if they aren’t doing it by mqtt?

And if they’re not talking to the devices, how are they automating them?

5
  1. Libraries to implement an MQTT client are available for most programming languages which makes it easy for clients written in various languages to communicate.
  2. Messages can be retained by the server, either until a client in a session acknowledges receipt, or forever. This can be useful if you for instance have a number of entities, for example ESP32 units, that on wake-up or boot need to read a configuration message from a server. I used this to automatically configure new units as a sort of zero-config setup. I also use MQTT to send status messages from various python scripts that are running on different machines, reporting data back to HA.
2 Likes
6
  1. Messages are queued, so no client will ever “miss” a message even if for instance 100 clients (for instance temperature sensors) are sending data at the same time to a server.
  2. You can have almost any number of subscribers or publisher talking to each other at the same time.
7

So it’s basically only for the cases where you’ve custom built something?

8
  • What are the conditions under which you decide to use it?

When I want to use any of my Tasmota devices, I use MQTT.

  • What benefits does it provide?

Fast and secure messaging over LAN when set up correctly

  • From an uninformed viewpoint, it seems like a lot of extra mental overhead when developing automations. Is this fair or something you don’t really think about?

You don’t have to use it, in fact some people use a REST api instead, just use MQTT if you need to.

NOTE: The component page for MQTT really doesn’t explain anything either. Maybe someone could help expand it?

Wikipedia is probably a better source:

1 Like
9

no… my sonoff switches and sensors only communicate with Home Assistant using MQTT. My automations can send commands via MQTT as well although I use switch turn_on and switch turn_off in mine. Personally, nodered is a non starter for me and I see no use in introducing that kind of complexity when I can just use automations.

Theres lots of non-custom MQTT devices and if you want to control them or talk to them you need to use MQTT.

10

I like MQTT because it is like a data bus that sits independent to homeassistant.

I can get data to and from devices using MQTT whether using homeassistant or not.

I prefer to not “tightly couple” my sensors and devices to homeassistant, This is especially important with “homebake” devices (including where custom firmware is added to devices like TASMOTA). If I ever do change from homeassistant (or want to run multiple controlling systems) the devices do not need re-configuring, they still just talk and listen to MQTT topics.

2 Likes
11

Essentially it is the lingua franca of IOT. Many manufacturers and software producers turn to mqtt because it means they don’t have to invent another protocol. Once their device talks mqtt it can talk to everyone and everything else. Otherwise we end up with

3 Likes
12

These are some great responses. Thank you!

Overall, it sounds like I don’t really need to worry about it unless I start doing more custom/sonoff/tasmota-like wifi devices. I’ve only got a single esphome device, everything else is either z-wave or has a platform from home-assistant (vacuum, roku, plex).

1 Like
13

Correct. :slight_smile:

3 Likes
14

I like MQTT because I haven’t had any stability issues with it in several years now. It always just works.
I try to use MQTT as much as possible because even when home assistant is rebooting most of the “things” still just work.

1 Like
15

Can’t agree more. All my esp devices use mqtt (Tasmota, openmqttgateway, esp2rflink) and my zigbee devices use zigbee2mqtt. All very stable, and all my devices work on my production HA instance and on my test HA instance.

16

If can I add more, managing of network of devices which uses MQTT (or any other centralized message broker) is easier.
You don’t need to work with physical connections (ie IP addresses), but with symbolic ones (ie topics = queue names). Any migrations, re-addressing of devices, moving between networks etc is independent from HA/MQTT configuration.

Second important income is, once you can connect device to MQTT, you don’t need it’s integration in HA.

The praise is that, you need to configure each device for MQTT. But often it can be done in some (semi)automatic way. There are still integrations/scripts which help finding devices in MQTT, but you can do it manually in configuration.yaml also for devices which don’t have HA integration yet.

Also queuing with ability of control over QOS has own advantages over direct connection.

2 Likes
17

@paulstronaut If you’re asking, then you probably don’t want MQTT. MQTT is merely a means to an end. If there is something you want to achieve that requires MQTT and you’re comfortable adding it to your stack, then do so.

Some people feel MQTT is an additional layer they want to avoid so they just don’t use anything that uses MQTT. Some people love MQTT because it allows extra logging, queuing, and information regarding data being passed around.

I use it for a few things but really, I only do because those things require it. Otherwise I would skip it. I see it as middleware that is interesting but I don’t see the extra layer as beneficial for anything I do.

3 Likes
18

Personally I like the features:

  • Publish/subscribe > polling
  • the interface is human-reasonable plain text
  • “Messages” are very lean. Both on bandwidth and on end-device processing power
  • Messages can be set up so that they are guaranteed to be received (granted, doesn’t matter much for HA, but it’s a nice detail from a system design standpoint)

But, for most cases it’s like arguing about thread-count for your kitchen cloths

3 Likes
19

I also struggeled with the overhead, especially setting up an authenticated MQTT environment was tricky, but for me it paid of.
(I made an ansible role, which I’m willing to share if someone is interested)

  • It’s event driven and one can accomplish a real time feeling of data flow
    • That’s in contrast to a polling procedure
  • One data publisher, N consumers scenario
    • e.g. building power consumption measurement, consumed by HA and a stand alone display
  • Independence from HA’s availability and usability
    • External MQTT libraries (e.g. python3) are broadly available and provide a very stable publishing procedure - it’s almost like fire and forget on the publisher side
1 Like
20

An old topic but I have the same question as @paulstronaut. I’m still struggling to understand if the feature rich MQTT protocol would deliver benefits to me.

My understanding so far …

MQTT may provide benefit to a HA user:

  • When HA is not the only client using the devices (or there are multiple clients).
  • Risk reduction - lower cost of migrating to another client (not HA). This assumes that the risk of migrating to another I/O server technology is much lower that another client (which seems fair enough to me).
  • You need to use a device that only uses MQTT. That is, no other HA integration (e.g: Zigbee, ZWave, ESPHome, etc) is possible.

Costs (disadvantages) of using MQTT:

  • If HA natively provides reasonable integration for you devices, MQTT:
    • More overhead in configuring
    • Requires extra expertise (not an issue if “the doing of it” is part of the objective)
    • Introduces a middle layer. e.g: zigbee → MQTT server → MQTT client (HA) -vs- zigbee → MQTT client (HA). Nice protocol but another layer.

Use case:

I wonder if enabling multiple clients enables enables establishing a HA test environment? This is a second “non-production” HA instance to test updates etc. Do I have this right?

Features mentioned that I’m not quite able to map to benefits that I would love more info on:

  • @tjntomas - You mentioned “automatic configure”.
  • Message queuing - I understand the feature, but compared to native HA integration, When would these provide me with a benefit?
  • Tasmota devices - Why are these particularly suited to MQTT?

Importantly - If I went 100% MQTT for my WIFI/zigbee/ZWave/Web(SEMS) system, what disadvantage would I experience?