MQTT Client - Beta

I have been having fun trying to make it work.

I'm just itching to finally get my Sense energy monitor working.

1 Like

The following works!

So the code is just for one-way sending of messages. There is no publishing, only subscribing. I have a Sense Energy Monitor that tells me when my devices turn on and off. No device control.

This takes the MQTT message from Home Assistant with the Sense component and send the ON/OFF status of my Sense devices.

The payload message is: OFF or ON.

Sample Home Assistant Automation code to control the MQTT messages to Hubitat

- id: '1562365442134'
  alias: Freezer Publish Off
  - entity_id: binary_sensor.freezer
    from: 'on'
    platform: state
    to: 'off'
  condition: []
  - data:
      payload: 'OFF'
      retain: 'true'
      topic: /home/freezer/state
    service: mqtt.publish
- id: '1562371629250'
  alias: Freezer Publish ON
  - entity_id: binary_sensor.freezer
    from: 'off'
    platform: state
    to: 'on'
  condition: []
  - data:
      payload: 'ON'
      retain: 'true'
      topic: /home/freezer/state
    service: mqtt.publish

Is there a post or thread about this anywhere? I was thinking about writing a Home Assistant component myself (a component seems like the best way--it's what their ST integration uses, but with their new cloud API), but I would much rather use or contribute to another if that is the case. :slight_smile:

1 Like

Make a request. The developer may be looking for additional testers.

Is anyone able to successfully have multiple distinct MQTT devices connected to the same queue? I am seeing lots of disconnects - "Error: Connection lost: Connection lost". Wondering if there is only one MQTT connection behind the scenes and the multiple devices are fighting for the channel.

Looks like they needed unique clientid's, which makes sense. Mosquitto was doing this as four different clients w/ the same client id were connecting and reconnecting:

New connection from XX on port 1883
Client hubitat already connected, closing old connection

Are you saying that multiple connections to MQTT are being made by my MQTT HE app using the same clientID ?? This would of course cause problems but I only use one broker connection for all devices, publish topics and subscriptions so this shouldn't happen.

... Or are you saying you were connecting your own external 'distinct devices' to the MQTT broker using the same clientID's, which also wouldn't work ...and so you've now fixed your devices clientID's to be unique ?

Or maybe this is not do with my MQTT app at all ?


I have an Arduino (WeMosD1mini) sketch for my Garage with a 'smart' relay (on/off - not toggle), and two GarageDoorSensors
GaragePortSensor1 - triggers when the door is fully closed (0/1)
GaragePortSensor2 - triggers when the door is fully open (0/1)
The sensors are picked up by the MQTT Client, and shows up correctly in Hubitat.
How can I program a GarageTile so that it shows correctly even if I use the physical switch or the key-chain remote on the garage-system not connected to Hubitat?
I'd like to pick up the sensor data (closed), and have the tile turn green, and vice-versa - automatically.
I also have a temp-probe on the Arduino. How can I have this show up on a Tile.
In MQTT I can name the sensors whatever I choose, it that is of any help.


Quick question about the publish parameters based on documentation. I am attempting to execute the following command:

interfaces.mqtt.publish(settings?.topicPub, s, true)

But I am getting errors due to the "true." Based on documentation this should be the retained option boolean of true/false but I get this error in my logs:

dev:28712019-09-11 08:51:29.181 am errorgroovy.lang.MissingMethodException: No signature of method: hubitat.helper.interfaces.Mqtt.publish() is applicable for argument types: (java.lang.String, java.lang.String, java.lang.Boolean) values: [wardhome/salt-tank/delay, 1, true]

Is there a bug in the MQTT client beta?

You are missing a parameter, there are 4 parameters for that call:
void publish(String topic, String payload, int qos = 1, boolean retained = false)

1 - topic
2 - payload
3 - qos
4 - retained

The last 2 are defaults, so if you leave them off they default to 1 and false.. but if you want to change the 4th parameter you also have to pass the 3rd parameter

1 Like

Oh wow I completely glossed over that. Much appreciated!!

1 Like

So these are no longer needed ??

import static hubitat.helper.InterfaceUtils.alphaV1mqttConnect
import static hubitat.helper.InterfaceUtils.alphaV1mqttDisconnect
import static hubitat.helper.InterfaceUtils.alphaV1mqttSubscribe
import static hubitat.helper.InterfaceUtils.alphaV1mqttUnsubscribe
import static hubitat.helper.InterfaceUtils.alphaV1parseMqttMessage

and replaced with

import static hubitat.helper

Or no import is needed ?

Correct you don’t need those includes anymore.

1 Like

For the uninitiated in MQTT, can someone layout the use case for having this? I stumbled across a project where someone made his "dumb" tv smart by connecting it to a raspberrypi via hmdi-cec and MQTT. He used it to turn the TV on/off, change the input and do cool things like using Alexa voice commands to switch the tv input to show his front door camera. I was investigating how to accomplish something like that - which brought me here.

I have a hubitat hub, a raspberrypi 4 and an ancient (by todays standards) Panasonic TV which supports hdmi-cec with its veira link feature.

Has anyone done something similar here? What other use cases does this present? I am confused by why folks are using mqtt to connect to other hubs.

MQTT is a great IoT protocol that uses topics. A lot of the DIY smarthome environments have gone down this path verses direct proprietary protocols such as Zwave, Zigbee and even Wifi (perse').

I used this for my Salt Tank project using an arduino WeMo D1 and a Ultrasonic Sensor.

The biggest benefit to MQTT is speed. All devices listening on a topic receive the message at the same time. For lights this eliminates the popcorn affect the other protocols suffer from as all the lights receive the message to do something and they do it at the exact same time.

If you do some simple YouTube searches for "MQTT Smarthome projects" you will see a ton of great IoT solutions to 1st world problems that are significantly cheaper OR don't exist as a solution today.

To get started you will need an MQTT broker installed on a RPi. This is the "hub" of the MQTT messages. Once this is done install a MQTT Explorer to see what is going on in the MQTT hub. Probably not much without a client BUT with the tutorial I sent you above you can goof around and begin to understand the use cases.

Hope this helps!

I can't answer your question on what/how to do it on your TV.

But in general MQTT is valuable for connecting data from dissimilar systems together - without having to use a proprietary API/interface on each system type. It provides a standard messaging protocol so that regardless how an individual system works internally, if they support MQTT messaging, they can share (and receive) data from other systems in a very fast, efficient, secure, and low overhead way.

1 Like

I’m controlling my Panasonic TV with hmdi-cec but it’s convoluted I send commands from Hubitat to a Apache server running on a Raspberry Pi which runs a python script. I will probably be switching to MQTT and using Node-Red. Using these nodes node-red-contrib-viera - Node-RED and node-red-contrib-cec - Node-RED.

Node-RED would be how I would try to do it, if I needed to.

1 Like

While MQTT is great, I must defend Zigbee: it supports group messaging, which usually also eliminates the "popcorn effect." But that's only part of the story. Most (maybe all? I haven't used a lot but all I have do) Zigbee bulbs support scene clusters, and each bulb remembers it setting for a scene, which can also be recalled with one command. This is what what makes Hue scenes so fast (a recent Bridge update might have changed this, but traditionally, accessories like the Tap and Dimmer have just broadcast this command and the bulbs would immediately respond--they knew what to do--without Bridge communication being necessary) and Hubitat scenes sometimes a bit slow (the hub is emulating this, bless its little heart, with individual commands to each bulb for things like color and level). Theoretically, MQTT could do this too (broadcast a command like "activate scene 28"), but I'm not aware of any bulbs or lighting systems that support this.

In other words, Zigbee handles this quite well, and the "popcorn" effect has nothing to do with the protocol. :slight_smile: (It's also not proprietary; it's an IEEE specification. Anyone can make a proprietary profile on top of the standard protocol, but most devices people here use are ZHA 1.2 or Zigbee 3.0 using the standard clusters and whatnot as intended. Z-Wave is a similar story. Wi-Fi is...a mess beyond the fact the protocol itself is standardized, which helps in no way with how people actually use it for devices.)

(Z-Wave might have something similar; I know nothing about Z-Wave bulbs except that color implementation is generally a mess, and I have low hopes for the rest so I'd doubt it.)

1 Like

Yes you are correct. If someone invests in a homogeneous Zigbee 3.0 enabled network it is about the same. BUT that isn’t the case with many people such as myself. Using low cost solutions like Shelly, Tasmota, SonOff devices that are MQTT enabled actually provide a lower cost but more robust solution over the standard Zigbee and other proprietary (which Zigbee is even though it is an open protocol) systems.

1 Like