MQTT Client - Alpha


#1

The MQTT client acts similarly to the telnet client in that you use a driver to create a connection to an MQTT broker and manage the connection and messages through that driver.

Methods that are available

void hubitat.helper.InterfaceUtils.alphaV1mqttConnect(DeviceWrapper device, String broker, String clientId, String username, String password)
void hubitat.helper.InterfaceUtils.alphaV1mqttDisconnect(DeviceWrapper device)
void hubitat.helper.InterfaceUtils.alphaV1mqttSubscribe(DeviceWrapper device, String topicFilter, int qos = 1)
void hubitat.helper.InterfaceUtils.alphaV1mqttUnsubscribe(DeviceWrapper device, String topicFilter)
void hubitat.helper.InterfaceUtils.alphaV1mqttPublish(DeviceWrapper device, String topic, String payload, int qos = 1, boolean retained = false)
Map hubitat.helper.InterfaceUtils.alphaV1parseMqttMessage(String stringToParse)

A quick and dirty example that does not do any error handling:

metadata {
    definition (name: "Test Mqtt", namespace: "test", author: "Test") {
        capability "Initialize"

        command "publishMsg", ["String"]
    }

    preferences {
        // put configuration here
    }

}

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
import static hubitat.helper.InterfaceUtils.alphaV1mqttPublish

def installed() {
    log.warn "installed..."
}

// Parse incoming device messages to generate events
def parse(String description) {
    log.debug description
    log.debug alphaV1parseMqttMessage(description)
}

def publishMsg(String s) {
    alphaV1mqttPublish(device, "/test/hubitat", s)
}

def updated() {
    log.info "updated..."
    initialize()
}

def uninstalled() {
    log.info "disconnecting from mqtt"
    alphaV1mqttDisconnect(device)
}

def initialize() {
    try {
        //open connection
        alphaV1mqttConnect(device, "tcp://test.mosquitto.org:1883", "hubitattest", null, null)
        //give it a chance to start
        pauseExecution(1000)
        log.info "connection established"
        alphaV1mqttSubscribe(device, "/test/hubitat")
    } catch(e) {
        log.debug "initialize error: ${e.message}"
    }
}

def mqttClientStatus(String status){
    log.debug "mqttStatus- error: ${status}"
}

At this point it is use at your own risk !


Announcing Rule Machine 3.0: Hub Update 2.0.9 is available
HomeSeer or Hubitat - Why?
#2

I am hoping I have time this week to work on testing this with my current broker I use.


#3

This is working well for me.

I am working on a MQTT app for release (initially alpha testing) that will allow easy integration of adhoc MQTT devices, as well as publishing existing HE devices to MQTT. Supporting onoff and dim devices only ATM but easily expandable.

Additionally it will automatically discover MQTT devices that are using either of the two emerging protocols - homie 3 or HomeAssistant's one. Also works with HA's MQTT statestream.

Shortly I'll be looking for anyone that is using homie 3 (perhaps from Homey) or using Home Assistants MQTT statestream and wants to experiment. I need to work on the UI a bit to make the adhoc devices easy to configure.


Hubitat + openHAB
#4

Awesome news! Thank you for developing this feature, it's going to make it much easier to link all my different IOT devices together with Hubitat. This also let's me drop a large chunk of Node-Red integration I have linking Hubitat events and Maker API with MQTT and Home Assistant.

Are there any performance considerations to take into account?


#5

If you need a beta tester, let me know.

Besides HA with MQTT, I am also running Zigbee2mqtt under Hass.io.


#6

@lsilva171 morre like alpha :wink: but yes would be interested in you trying this with HA. I'll be in touch shortly.


#7

Me too please !


#8

I would definitely be in for testing and working on any issues that might arise. I've been waiting for this for sometime. Thanks Hubitat for opening the door!


#9

I would love to be a part of this alpha/beta too. I have a RPi MQTT broker setup.


#10

So, at this time I’m after people who have MQTT devices supporting discovery. This typically means HomeAssistant with MQTT or the homie protocol e.g. Homey. Exposing HE devices to MQTT is OK too using a simplified homie topic structure.

Currently this is for onoff/dim devices but will expand fairly easily. Ad hoc individual devices will come shortly a few days afterwards,

PM me if you’re interested in early testing and have a suitable setup.


#12

Thankyou for this feature!! This will set hubitat above all other hubs, if it isnt already. Can't wait to use it!


#13

So I'm reading your post and thinking about this more and I'm confused about your use case with discovery...

If you support discovery via the HAss methodology, and you run both HAss and Hubitat, won't you get multiple devices discovered on both platforms? I would think that would be an undesirable behavior.

Or are you simply trying to recreate the discovery method? Could it be selectively disabled?

Just some thoughts.


#14

All of the 'discovery' features (protocols) can be selectively disabled, and having discovered devices I intend the HE users to choose the devices they wish to create in Hubitat.

In the reverse sense I intend to let the HE user choose which devices they expose using either the homie or HA protocol , or both. The homie protocol, at least initially, will only be partially supported as it is in a state of flux still. There may (or may not be) a further filtering of devices provided by the other platform for selecting devices to add into their system based on their discovery mechanism.

However only Homey is a real contributor to publishing its devices in a discoverable format (homie) . Although both openHAB and HA promote their own standard neither of them implement it for their own device exposure !! It's a very one sided endorsement to get devices into their own application.

HA has an MQTT feature called statestream that does expose the status of it's devices but does not provide control. I have worked around making this bidirectional using a small automation script installed on HA which currently supports lights and switches. More device type support can be added fairly easily using my approach. There is also eventstream which I will explore later if it more useful but it doesn't accomodate MQTT with the same granularity so I chose statestream.

You will also be able to add specific 'ad hoc' MQTT devices into HE by providing the topic/state information when you create the Virtual MQTT device. This is what most people will use I think so I have to make it as easy to use as possible, while maintaining some flexibility

So I'm hoping this will prove flexible enough for everyone from the HE standpoint. They can pick and choose devices they wish enabled from and to MQTT. If there's other concerns you have let me know because hopefully I can then accommodate the needs of more users early on.

NB The first alpha added all 'discovered' devices to HE, next will allow choosing to add only specific enabled devices. ad hoc device addition was untidy in this version, and likely the subsequent release will focus on this.

K


#15

I think I understand. My use case, I think, is far easier - I hope. I'm looking to replace the MQTT Bridge solutions that are currently out there and in various states of support. I have added a number of IoT devices to HE via ZigBee and ZWave, but I wish to control them via HA. MQTT seems to be a good common protocol for this but, until recently, was a bit complex to setup. Until a deeper integration between HA and HE (Maker API maybe?) comes around - I'd prefer HE to just publish events on MQTT-enabled devices (user selected) for consumption in HA. In this scenario, discovery is of little value to me. I'm joining the devices to a "device hub" (HE) and leveraging MQTT as common protocol between the "device hub" (HE) and the "control pane" (HA).

Still interested in your application to see if it meets my needs.


#16

Got quite a bit done over last weekend and decided to get a bit more into the next alpha which should be out in a day or so . It should suit your needs Jeff , although bear in mind it's switches/dimmers only at this stage.

Stay tuned.. I'll contact all the people who have PM'd me directly


#17

@chuck.schwer

This is working really well for me - thanks. Only omission seems to be LWT - Last Will and Testament - any chance ?

https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament/

(Will be sending out alpha2 of my MQTT app today to all who have PM'd me)