[FEATURE REQUEST] MQTT broker hosted on Hubitat hubs

I know this has been requested many times before, but here it comes the same request again now in 2024 - Hubitat, please consider the possibility to add a MQTT broker on the HE hubs.

Currently I am working on a driver for a very interesting device, which uses MQTT protocol for communication. I hate to advertise HomeAssistant, but I will have to do it in order to make the device work with Hubitat.

An MQTT broker will provide a fully local (as per Hubitat spirit) connection to a wide range of devices.

Hubitat has already acknowledged the importance of the MQTT protocol by adding a native support for MQTT clients.

Let’s make the second step, eliminating the need for just another box in our Hubitat smart home.

14 Likes

I'd think there's room for an "Ultra" level of hardware with expanded capabilities.

MQTT is a very light and highly optimized protocol, it does not require much resources even for the server side.

And the C-8 hardware resources are not less than a low-end Raspberry Pi running HA on a SD card.

I don't think you're making your case for a Built-In MQTT Broker vs the existing Community MQTT.

It's the same old story I suspect... not enough consumption to dedicate resources.

Alternately, why not create the MQTT Broker you want as a Community project and THEN see if Hubitat will "import it" after it's working well?

Caveat: I don't use MQTT, probably wouldn't if it was available. There's just nothing interesting to me in that space. Now maybe your mystery project will reverse that and I'm all for THAT, but today, I can't see that the usage is going to usurp Matter. Do I want more/better Matter from Hubitat or MQTT??

1 Like

I want both - a better Matter support and a local MQTT broker! :slight_smile:

The open source MQTT brokers are available in Java, I suppose it will be much easier (and natively) to add a MQTT broker as a system app / interface, rather than porting thousands or lines code to Groovy as an app.

When I have the time I can research and make a list of how many IoT devices are using MQTT.

1 Like

The device in the picture has been available for quite a long time :

I started playing with it just yesterday; next few days, I will make a dedicated thread for it.

2 Likes

I knew that was coming as I typed it... :slight_smile:

1 Like

Please list the top 30 most popular smart home brands that use MQTT protocol

ChatGPT said:

ChatGPT

Here are 30 popular smart home brands that use the MQTT protocol for device communication and integration:

  1. Samsung SmartThings
  • Uses MQTT for automating and connecting smart home devices.
  1. Home Assistant
  • Extensively uses MQTT for home automation and control of smart devices.
  1. Tuya Smart
  • Employs MQTT for cloud communication between smart home devices.
  1. Shelly
  • Shelly smart relays and switches use MQTT for local and cloud control.
  1. Sonoff
  • Sonoff devices, especially with Tasmota firmware, use MQTT for local and cloud communication.
  1. IKEA TRÅDFRI
  • Can integrate with MQTT for enhanced control via third-party platforms like Home Assistant.
  1. Philips Hue
  • Integrates with MQTT via platforms like Home Assistant to control smart lighting.
  1. LIFX
  • LIFX smart lighting can be integrated with MQTT through home automation platforms.
  1. FIBARO
  • FIBARO smart home systems support MQTT through integration with automation platforms.
  1. Xiaomi Mi Home (Aqara)
  • Xiaomi’s Aqara devices communicate through MQTT with platforms like Home Assistant.
  1. Ecobee
  • Ecobee smart thermostats integrate with MQTT for smart home control.
  1. Nest (Google Home)
  • Nest devices can be integrated with MQTT through intermediaries like Home Assistant.
  1. Ring
  • Ring security devices connect to MQTT via home automation platforms.
  1. Logitech Harmony
  • Logitech Harmony can work with MQTT through platforms like Home Assistant.
  1. BroadLink
  • BroadLink devices support MQTT for control and automation via platforms like Home Assistant.
  1. Kasa Smart (TP-Link)
  • Kasa smart plugs and devices link to MQTT for home automation via Home Assistant.
  1. Wyze
  • Wyze smart devices integrate with MQTT through third-party platforms.
  1. Nanoleaf
  • Nanoleaf lighting products can communicate using MQTT through platforms like Home Assistant.
  1. BlitzWolf
  • BlitzWolf smart home devices use MQTT with the right firmware, such as Tasmota.
  1. Yeelight
  • Yeelight smart lights integrate with MQTT via platforms like Home Assistant.
  1. Bosch Smart Home
  • Bosch’s smart home devices can be integrated with MQTT for automation.
  1. Insteon
  • Insteon devices can communicate via MQTT through platforms like Home Assistant.
  1. Eufy
  • Eufy smart home devices, such as security cameras and lighting, can integrate with MQTT.
  1. Wink
  • Wink smart home hub devices can support MQTT integration through third-party automation platforms.
  1. OpenHAB
  • OpenHAB is a smart home platform that uses MQTT to communicate with various smart devices.
  1. Tasmota
  • Tasmota is firmware for ESP8266/ESP32 devices that supports MQTT for smart home control.
  1. Z-Wave (via MQTT Gateway)
  • Z-Wave devices can be integrated with MQTT via MQTT gateways and home automation platforms.
  1. Zigbee2MQTT
  • Zigbee2MQTT allows Zigbee devices to be controlled via MQTT for smart home automation.
  1. Securifi Almond
  • Securifi Almond smart hubs and routers use MQTT for integrating with automation systems.
  1. Netatmo
  • Netatmo’s smart home devices, such as cameras and weather stations, can be integrated into MQTT-based platforms.

These smart home brands utilize MQTT directly or indirectly through platforms like Home Assistant or OpenHAB, allowing efficient, lightweight communication between devices.

Please list the top 10 most popular smart home brands that use MQTT protocol including Community apps

  1. Home Assistant - An open-source home automation platform with robust support for MQTT, allowing integration with a wide range of devices and services.
  2. OpenHAB - Another open-source home automation system that features extensive MQTT support for connecting various smart home devices.
  3. Domoticz - A home automation system that integrates well with MQTT, allowing for versatile control and monitoring of smart home devices.
  4. Shelly - A brand known for its smart home devices such as switches, plugs, and sensors, all of which support MQTT natively.
  5. Tasmota - An open-source firmware for ESP8266/ESP32 devices that offers comprehensive MQTT support for DIY smart home projects.
  6. ESPHome - Firmware for ESP8266/ESP32 devices that can be integrated with MQTT, providing a flexible solution for custom smart home devices.
  7. Zigbee2MQTT - A popular community project that allows Zigbee devices to communicate with an MQTT broker, enabling interoperability between Zigbee devices and other MQTT-compatible systems.
  8. Hubitat - A smart home hub that supports MQTT, providing a way to integrate and control various smart home devices through this protocol.
  9. Homebridge - A lightweight Node.js server that can be extended with MQTT plugins, allowing Apple HomeKit users to integrate with MQTT-enabled devices.
  10. OpenMQTTGateway - A versatile project that acts as a bridge between various smart home protocols and MQTT, making it easier to integrate devices from different ecosystems.

These brands and platforms offer strong support for MQTT, either directly or through community-driven solutions, enabling a wide range of smart home integrations and automations.

2 Likes

what app/ driver am i looking for?

I would use an MQTT broker if it were built in.

But it isn't the end of the world as there are a zillion ways to host a broker outside of hubitat if needed.

And I already have enough MQTT client capability in the hub in custom apps/drivers that I can get what I need there in the end.

1 Like

Here is my Message Board (two cascaded 32x8 pixel led marix) driven by Pixelblaze and 100% locally controlled by HE.



It is capable to display scrolling text but I cannot attach a video.

2 Likes

Most of this is way over my head, but I would buy a Hubitat that would let me run things like the Emporia Vue integration without any additional hardware between the EV and Hubitat.

ETA: It would apparently also allow an integration with Mitsubishi, which would also be nice.

Basically, if an integration requires another piece of processing hardware, I pass on it. The big draw of the HE for me was that is comes all in one - the hardware, software, zigbee and zwave radio, etc. If there were a way to have it include more that would give more functionality, that would be awesome.

I strongly believe the Hubitat Hub should NOT be used as your MQTT broker. It is not an appropriate platform.

An MQTT broker offers ‘server’ type functionality to a network. It should run on something that is robust and available 24/7 and on a platform that is rarely updated and not restarted frequently. HE does not meet those needs.

HE is essentially an MQTT client ie a peripheral as are other MQTT clients receiving or publishing data from one centralised Broker. Currently when HE is restarted it can synchronise with an external MQTT broker but not with an inbuilt one. This can lead to bad state info both within HE and propagated externally to other devices.

If you haven’t the resources to spin up an MQTT broker you can use a public one.

Additionally an MQTT broker although not typically processor intensive can use significant storage for messages destined for any disconnected clients when they later connect and also those clients using an elevated QOS level, especially level 2 QOS. These standard features are an area that caused many problems with say the Homey inbuilt broker which didn’t implement them.

2 Likes

FWIW, this isn't true. Hue offers no native MQTT support (though with an open, well documented API, something probably exists--but it would be third-party and could not possibly run on the bridge, nor does the Hike Assistant integration for Hue use MQTT as claimed). I suspect the same is true for many of the other answers (hallucinations?) Chat GPT provided, too, but I'm not quite as familiar with most others (I'm not aware of anything for LIFX or Ring, and its answer for Hubitat is misleading at best--to name a few).

This is not to say that the request itself isn't interesting.

I have more than a few Always On computers in my house and it took possibly 10 mins to start a MQTT Broker on one of them. Alongside my HomeBridge, HubConnect Proxy, Node-Red and more home automation tools. Node-Red was the first to get MQTT added for test. Now I can type Hello World over there and have it appear in Node-Red. Impressive, huh? LOL

Still have no idea what I'd use it for though. :slight_smile:

1 Like

I first installed MQTT as part of Teslamate, a project that records data from Tesla cars. The default setup includes an MQTT server which it uses to broadcast all the incoming data. The Hubitat integration for Teslamate gets the data from that MQTT server. I have it running on a Raspberry Pi under Docker.

Despite the rock-solid reliability of the MQTT container, which is only down for a few seconds a few times a year during Teslamate updates, I still generally prefer to use a direct connection between services rather than using MQTT as an intermediary for 1:1 connections. It just seems more reliable to have one less link in the chain between sender and receiver.

That said, there are a few cases where I rely on MQTT as the easiest/best solution to connect services.

First, for 1:many connections, MQTT makes sense. Rather than having something send the same message to two or three different recipients, it can be easier to to publish it to MQTT and have each service that needs it subscribe to get the message. As an example, when my Blue Iris (NVR/video surveillance) server sees someone at the front door, I need to send a notification to both Hubitat (to adjust lights) and Node Red (to play a sound via my Google Home speakers). I publish one message to MQTT and both the hub and Node Red receive it.

Another use case it that it can be simpler to send messages via MQTT than HTTP sometimes. Blue Iris it can accept admin commands like changing modes, sending PTZ commands to a camera, etc via either HTTP or MQTT. The problem with HTTP is that login security settings in Blue Iris can make authenticating that connection more difficult. There is no authentication needed for a command sent via MQTT, so I find it easier to do it that way.

Blue Iris can also publish alerts via MQTT or HTTP. When I need to get the alert into Hubitat I had been using HTTP calls, but I've started using MQTT. I learned my lesson when I upgraded to a new hub, which changed all my Maker API endpoints. With MQTT as the intermediary, as long as Blue Iris publishes to the same topic and Hubitat subscribes to the same topic, it doesn't matter if my hub IP or Maker API token changes, which can't be said for a direct HTTP call from Blue Iris to Maker API.

I also use MQTT to connect two Node Red instances. There are nodes that I needed for connecting my Eufy doorbell that I could only get to work on Windows, so I'm running a second Node Red instance under Windows. The problem is that I wanted to get the image that was received by the Windows Node Red node to the Raspberry Pi to save the file there. The easiest solution was to publish the image to MQTT from Windows and subscribe to the topic from the Raspberry Pi.

So I find MQTT a very useful tool in the home automation toolbox.

2 Likes

I guess I disagree there. I patch and reboot my rpi's and debian/Ubuntu VMs for security updates more often than I do Hubitat.., As such my Hubitat hubs likely (statistically) have higher uptime than an rpi or *nix VM.

That's true, but can obviously be tuned to be 'good enough' in most scenarios. But that is valid given enough clients/retained messages.

Absolutely stunned your Linux hosts take this level of maintenance. Are you updating HE with all the incremental updates each incremental release too? I’m guessing not.

I would never use HE as a broker. It’s architecturally wrong for everyone but the smallest novice home user and a fundamental mistake for later device expansion.

My system is fully MQTT based with well over 1K topics. I haven’t rebooted my MQTT broker in maybe 6 months and that was for user maintenance. The broker is fully local and isolated from the Internet so I don’t worry too much about security. HE is one of the clients, in fact I use several HE and other controllers. Very happy with how it’s working out.

2 Likes

Undoubtedly, the best approach is to run an MQTT broker on a dedicated, always-on server on the home LAN.

However, I think that this DIY solution is not affordable for the average smart home user. Excluding us (the computer geeks), how many non-tech users will be willing to set up just another hardware box and type magic spells like "mosquitto_sub --cafile /etc/mosquitto/ca_certificates/ca.crt -h 192.168.1.11 -t "test" -p 8883 -d -u "JohnSmith" -P "XYZcorp@1" ?

I have searched this forum to find out what home automation gadgets were mentioned to need a MQTT broker, these are a small number of the search results :

There are many more devices mentioned in the Hubitat forum that mention the need for an MQTT broker.

Of course, some of these devices support other communication methods (such as HTTP), so MQTT is not the only possible way to integrate them in Hubitat. However, in most cases, the recommended solution in the HE forum threads is "Install Home Assistant."

For Home Assistant-only users, running the MQTT broker on a Home Assistant box will result in equally good (or equally bad) performance as if was possible to run a MQTT broker on Hubitat box for Hubitat-only users (if this possibility was available).

3 Likes