What is MQTT being used for with HE? (MQTT for Dummies)

In simple terms, what is MQTT being used for with HE? I keep seeing the acronym being thrown around. I’ve googled it and I’m still stuck scratching my head.

My simple (and rather incomplete) understanding is that it’s a communications protocol/broker/middleman that’s used to have their HE communicate with another end device. I just don’t know for what purposes a user might need to set this up.

That article covers the broker services for MQTT but their real item is that many of the IoT devices that run a certain Wifi chip and vendor locked firmware can be re-flashed with Tasmota and thus opening a closed device to more services and support.

Once a device is reflashed you now have standard interfaces that supports MQTT, a WebUI, and HTTP commands that the Hubitat can integrate with. A lot of the hacking of these devices are well documented at the Home Assistant site since they seem to love to tweak devices.

I have been looking at all these Wifi connected "Alexa and Google Home" compliant devices and many are Tasmota supported and if you don't want to send all that control data to Amazon and Google flashing and then using MQTT to integrate makes some good sense.

2 Likes

Thanks for the clearer explanation @ronv42 .
So a MQTT bridge is mainly being used with HE to communicate with hacked IOT devices that are either unsupported (closed APIs by default) and/or devices that were hacked and flashed to prevent unwanted or extraneous communications with the mothership?

Here is another good site with history of MQTT and a good FAQ:

https://www.hivemq.com/mqtt/faq/

MQTT was developed by IBM if I remember, as a lightweight communications protocol to allow for a standard way for devices to communicate. It follows a publish and subscribe model with the broker just passing published messages on to the device that has subscribed to those messages. It takes a bit to get your head around it so I would do some reading.

No, not really. MQTT can be used for that of course, but it can also be used to integrate other non-hacked systems/devices with Hubitat, and Hubitat with those systems.

For instance, I also run Home Assistant in addition to Hubitat. I use MQTT to publish Hubitat devices into Home Assistant, and Home Assistant devices into Hubitat - that way I can use any device in either system.

I also use MQTT in Node-Red to do some logic that I can do easier there.

That way I can use which ever system/tool can do the job best, instead of being forced to use Hubitat for things it simply is not as good at (or Home Assistant for things that are cumbersome/painful to do there but easier in Hubitat).

2 Likes

Do you have any particular examples of unsupported devices (directly to a hub) or automations that require this usage?

Tons. In general Home Assistant has better/more support for cloud integrations.

One specific example I use - Hubitat doesn't support integration with Arlo cameras. Home Assistant does.

But it is more than unsupported devices. Some people prefer to do rules in webcore or a text based script/rule engine. You can do that in Home Assistant/Node-Red, but you can't in Hubitat. But simple rules are easier to make in Hubitat.

Or, I'll have 10 devices in Hubitat that I want to trigger from a cloud integration in Home Assistant. So I do the logic in Hubitat as that is where the majority of the devices are.

Home Assistant can support listening on a UDP port for unsolicited messages (like from weather stations), Hubitat doesn't.

Each tool is better/worse at different things.

2 Likes

And to be clear, I'm not trying to knock Hubitat. It is a great system, and it is my primary home automation hub. The other systems I mentioned have plenty of issues/cons of their own.

The point of all that above is that MQTT is a vendor agnostic, open protocol/system way of sharing data between platforms. No goofy APIs needed, no licensing fees, no worry about "will it work in XYZ system". Once you can get the data from a platform into MQTT, you can use the data and devices wherever YOU want - not just where the vendor decides.

2 Likes

Okay now you’ve really got my interest. Thanks for the clarification. So with HA you have your Arlo cameras Installed and use MQTT to communicate bidirectionally with HE? I take it that the Arlos are still relying on the cloud somewhat for recording?

I tried installing unsupported devices with Homebridge/HomeKit originally set up on my Qnap NAS only to find out that the communication wasn’t bidirectional... I might have to tinker with a HA docker install on my NAS and MQTT at some point when I have more time. Although truthfully the idea of having multiple middleware running separately all the time kinda bugs me. Different points of potential failure and upkeep. I hope at some point HE adds more direct support.

Yes, the integration is through the cloud. And to be clear - I use the Home Assistant Arlo integration for the camera motion alerts. Recording is something MQTT can't do/support - it is for passing text/data/states, not video. So might not be what you were wanting.

What is a good broker? As you know I have Node Red on a Odroid. Best to install in docker. Currently Node Red is not installed via docker (too many permission issues). I might also look into Home Assistant.

You can run a MQTT broker from within node-red.

Personally, I use Mosquitto as a broker.

1 Like

Only broker I use is esclipse mosquitto.

1 Like

I run both.

Mosquitto is great - currently running on an old RPi3 - have my weather station and "owntracks" sending messages to it.

Aedes has a little less functionality (no bridging yet) but works well within NR itself. I sometimes use it for setting some global variables to generate "events" - I know I could also use the Link node but I like the flexibility and it's easy to mess around with.

If you plan on installing the broker on the same device as your NR instance and don't need bridging then consider Aedes - it's easier to install and configure and probably takes up less resources (don't know - just guessing).

edit1: don't mean to imply Mosquitto is difficult to install/setup - it's not, just more cli goodness.

edit2: sorry stream of consciousness here.. also look into the great MQTT Explorer app.. allows you to connect to your broker.. and browse through / edit stuff.

3 Likes

MQTT Explorer is definitely my favorite client app. Although I do have MQTT.fx installed too, and spin it up on occasion.

1 Like

Right, so I installed Aedes, and got the MongoDB working. Connected Aedes to the DB and published a few commands. I successfully made one of my tasmotised lights publish to the broker. I also loaded up MQTT Explorer and looked at few topics. And it all works.

But I'm struggling to figure out what to do with it. Why does everyone rave about it? Honest question?

It's lightening fast as everything is sent in tiny packets and I do mean tiny

2 Likes

It's just a super lightweight way for different systems to talk to and potentially control each other. A totally simple concept with very powerful possibilities. That's it as far as I know.. :grinning:

One possible side use for MQTT in NR is if you need to generate some sort of "event" from an internal action like setting a variable. I've replaced some virtual switches in HE with globals in NR (things like "disable motion" switches). I have a subflow that sets the global and publishes it to MQTT. I can then use MQTT nodes to detect the update and trigger stuff in my sequences.

Note 1: I'm not sure this is the most efficient use of MQTT and it probably adds a minuscule amount of latency but it works.

Note 2: I could also use Link nodes but I find that things can get complicated when having multiple link sources spread across different flows.