I have been trying to get MQTT to work on HE for weeks. As I’m reading this thread I at least know I’m not alone in the leave or stay debate. Even with the latest update/integration I have about 2/3 of my Lights sort of working but only RGB from device page. Which is not a solution with my family.
Why? With the Maker API, anything that can send a HTTP Get can interact with any device on the HE. Once I learned about the Maker API, I no longer really needed MQTT for anything relating to home automation.
That’s good and may suit you but it doesn’t suit everyone, like myself that have more than one system integrated using MQTT for centralised state/control . Yes Maker API is workable for two systems but how about more, or when you want to integrate some other device or system that presents itself via MQTT or shares its state and control with others ?
MQTT is as close to an emerging standard across platforms and devices as we have, Maker API is a Hubitat way to do things, and very useful it can be too.
I wouldn't say that Maker API works just for two systems at all. It really depends on your devices. I currently have HE as the heart of my home. All my ancillary systems (various nodejs apps, NodeRed, Tasmota, reporting servers, etc) interact with HE using either the websockets interface and/or the Maker API interface.
What other systems are you trying to integrate that doesn't support HTTP?
I realise as a power user you can interconnect almost anything to anything but it becomes very spider web like if you’re not careful and you introduce many points of failure. True MQTT introduces a single point of failure unless you work hard on redundancy.
In my system for example both my alarm system and my heating boiler directly integrate to MQTT, Neither of these are capable of supporting http gets as they are really peripheral endpoints. They do not attach directly to a controller through a plugin or driver and offer no programmability to speak of in a customisation / script sense.
I’m working towards a system where useful information about the state of my home, even simple things like light status, room temperature, telephone callerID etc are available to anything in my home. Not directly owned by some controller, it’s all shared. This creates great flexibility for options re controllers, dashboards etc.
Directly linking two controllers doesn’t let me achieve that, unless one of them can onward synch to MQTT.
So what do you want from Hubitat in regards to MQTT? Just another client that can publish and subscribe to your main MQTT broker?
Yes , that’s all, a client (not broker) that can publish any Hubitat device to MQTT and can ‘flexibly’ subscribe to external MQTT device topics to support them as virtual devices in Hubitat. I realise mapping an external MQTT device to an appropriate virtual device type raises some challenges (although for my use case I can do some topic structure/content conversion elsewhere)
Community supported, sure. Hubitat integrated and supported; I don't agree. The very mention of Home Assistant and MQTT says you are a power user. IMHO this isn't the right direction for the platform to head. The opportunity is massive for Hubitat to succeed in the wake of Iris closing down and the sad state of Wink and SmartThings. I don't think personally that turning this into a geek's paradise is going to make the platform anymore successful than the previous attempts that have been made. However I do agree with keeping it as friendly to the consumer as possible, without taking anything away from those that want to tinker and build custom apps and drivers.
It's a very difficult balancing act, but if Home Assistant had to survive on volume purchasing to keep the lights on, that would be one dark building.
I use HE for local control & debating going back to ST as it integrates with Home Assistant. I stupidly got my family excited to be able to use HomeKit which all my devices were pushed to from Home Assistant. Which was fed to ST from HE. But no color control so I eliminated ST so I was dealing with 2 “hubs”. HE & Home Assistant. Once those worked 100% I have plan on adding the rest back in. But aggravating as something that works sorta if you want on/off. Or I go buy 36 more Hue bulbs.... It’s that or my family sends me off the plank (lesson learned no hints about features until 100% tested.
Well I would like that option but I believe it’s just not possible to build such a thing currently. The current hack is dreadful architecturally. I think only Hubitat could do it.
As for overlap with volume users look at companies like Shelly and Sonoff with devices directly supporting MQTT... it’s on the increase and avoids every platform needing their own drivers.
Alternatively, support Groovy's
@Grab and let us get Paho (etc) ourselves
With that, community members can do the cross-tech integrations and show how it'll benefit (with an open, event-based and documented delivery system)
Having the API exposed would allow cross controller federation (vs building them one-at-a-time) and ease the process for those wanting to migrate between the various Home-Automation platforms.
- a) Potential to build Support for Homie and/or HomeAssistant conventions for federation/conversion (currently supported by Hass, Home-Assistant, Homie, openHAB )
- b) Simpler data push/pull with InfluxDB / Telegraf.
- c) COTS Phone/Device tracking (via services like owntracks )
- d) One step closer to AWS MQTT, Google MQTT (etc) for paid services
The above wouldn't eliminate the need for Drivers on Hubitat, but they could be used to lessen the amount of code that's required.
eg. Alarm systems integrated via the Homie Convention vs one-at-a-time (as HE specific Drivers)
Initially MQTT would be for the advanced users, but it's often those folks that are writing the AddOns, and then inviting their (non-tech) friends to use the platform.
BTW, I agree that on-boarding new, typical, users should first priority, before some of this, but a few enablers (like
@Grab support) could pave the way
I didn't think HE's WebSocket interface, and underlying protocol atop the WS, was supported. Has that changed?
No, it hasn't changed. However, @chuck.schwer did state in another thread that the devs were going to make a websocket server official at some point in the future (with no ETA).
Ah, so it’s a Logitech Harmony style integration atm...
LOL I think I’ll skip it
Not really a comparison to a home automation hub. Shelly is open source cloud-based. No support staff like here. Sonoff is hardware, with very minimal cloud based software. No support staff writing code and supporting these products at the level a full automation hub needs.
Not to dig up a month old thread, but I was searching for MQTT and came across this thread.
I just wanted to clear up what seems like a lot of misunderstanding.
This is either a misunderstanding or mischaracterization of the relationship between HomeAssistant and Ubiquiti.
Ubiquiti Networks hired the founder of Home Assistant, Paulus Schoutsen.
They did not buy, acquire, or in any other way own HomeAssistant, and have no say in the development or release of it.
Per the press release, "Ubiquiti Networks will not acquire any ownership of Home Assistant. We will remain an independent and open source project."
It's a fully open source project with every single bit of it's source code free to view and fork. It's also maintained a 2 week release cycle since Paulus was hired by Ubiquiti nearly a year ago.
Why I'm leaving for home assistant
Sorry, got your post out of order when moving this to new topic.
Ish? The Harmony integration uses the Groovy websocket client. The websockets I'm using (for various things) are hosted by the HE hub itself (ws://[hubitat]/eventsocket and ws://[hubitat]/logsocket).
My reference was to using an undocumented API, hosted by the (local) Logitech Hub... and then people going nuts when it changes, and their integration(s) break...
A style of integration I casually refer to as Logitech Harmony style, given they've had the most recent / widely publicized failure for doing it.
ie. Move along, nothing to code-against here people
Ohhhhh!!! Yeah, I see what you mean now.
True on all counts.
Sure, you make it sound easy... What API methods would you expect to see or please show me how another hub has what you already want?
Doing an MQTT client that would connect to a server / broker to get and send messages similar to our websocket or telnet capability isn't that hard, but that basically means a driver to map the capabilities to for each MQTT "device" or signal you want to send.
Making Hubitat a full blown MQTT broker is a completely different argument. Which, for the advanced users, who already known what MQTT is, are already going to have a main server to communicate to.
So, please point me to an implementation of MQTT that facilitates the examples you provided that would provide any insight as to how to approach external MQTT interaction beyond just a client interface to the drivers as a communication layer for pushing and getting messages from a broker?