MQTT Client - Beta


#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.

Documentation is available here: MQTT Interface - Hubitat Documentation

See post 22 for updated information

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)


#18

Thank you
I'll be testing this client with MQTT Tasmota enabled Tuya 1,2,3Gang Switches as well as Sonoff 4ch, Basic, POW2 with Tasmota firmware next week.
I'll probably share a use-case once everything settled.
Still waiting for the US post service to deliver my 2 HE to Ukraine


#19

@chuck.schwer @andrew.rowbottom are there any plans to create MQTT broker within HE?
It is a crucial part of the whole system and performance improvement to be able to have an MQTT broker internally and connect it to Rules Engine with everything else across the system.
It'll remove additional hop from HE Client to external broker.


#20

@podarok When you get your hub and are ready for some MQTT playtime let me know and I'll join you in the MQTT alpha application group. I have about 50 testers now across platforms and it's working really well. Just adding LWT and I need to do some code refactoring before I post it here as an open beta but will do that in due course.

Re. an internal MQTT broker on Hubitat. I'm a little undecided on that. It's certainly not a necessity and I feel that the more advanced user requiring MQTT likely already has an existing/external MQTT broker. I wouldn't want to impact the responsiveness of the HE hub by adding this although I understand that HE is more likely I/O restricted than CPU, but this an I/O intensive feature. When (and if) MQTT become more plug and play and useful to an average HE user I can see that having it onboard is tidy and advantageous.

Also a comment on Home Assistant's experience. They added an internal broker based on Mosquitto and a lot of support questions arose related to that broker rather than external. They now recommend an external broker but that maybe to do with Docker issues, or it maybe that new users of MQTT start with the included broker, or it may be a resource issue based on a lot of people running HA on Raspberry Pi's.

Give me a shout when you're ready (as can anyone else here BTW using MQTT) and ...

Ласкаво просимо - welcome - maybe the first Ukraine user ?


#21

Sounds great.
Broker itself is not a performance bottleneck. I have it on my rpi3b+ more than a year now and cpu load is less than 1% ( mosquitto )
Yes, it depends from number of clients connected, but still .
I'm going to have ~25 mqtt devices connected to broker, just fyi. And I'll share use case, for sure.

Дякую за гостинність @kevin