Why restrict MQTT to drivers only? Why not allow MQTT in App code too?

The Hubitat MQTT documentation states "All [MQTT] code needs to be contained in a driver, there is no option to open an MQTT client connection from an app.". Why -- philosophically, and functionally -- does Hubitat not make the MQTT interface available within App code?

Naively, I would think that if App code is allowed to do things like httpGet() and httpPost(), then it would also make sense to allow App code to call the MQTT functions (Especially mqtt.publish(), where the app is sending an event to the outside world, much as the app might alternatively do with httpPost()) . However, I do notice that (at least according to the Hubitat documentation), the driver-only restriction applies not only to the MQTT functions, but also to the EventStream, Telnet, Websocket, and Raw Socket functions -- I might as well be asking this same question about those protocols, but I happen at the moment to be interested in MQTT. Is it, perhaps, the long-running, event-generating nature of these protocols that makes them unsuitable, in a philosophical sense, for direct access within App code? Is the idea, perhaps, that externally-generated events are supposed to be communicated to an App only by means of the App subscribing to (Hubitat-native) events generated by a Device? From a functional standpoint, what would break if App code were allowed to call the MQTT functions?

1 Like

It’s not a restriction as such. You just create an MQTT driver that handles the MQTT event driven parse routine. Then you can call that driver with say a publish or subscribe command from your app. If you wish you can pass payload updates back to your app from the driver too.

Actually rereading your Q. You could expose a command in your driver to open and close connections to an MQTT broker and call that from your app too.

1 Like

I appreciate the response, but this does not answer my question.

Meaning of life questions, really. What features or functions belong in a driver and what belongs in an 'app'? One important problem with Mqtt in an App is connection set up and tear down. Now that there is the preferences settings it could be easier to do that setup outside of an app or driver. Unless you have two mqtt brokers.

Until you pointed it out, I hadn't appreciated the single-broker-per-driver (or, perhaps more accurately, single-broker-at-a-time-per-driver) nature of Hubitat's MQTT API (I neglected to completely RTFM). But I think you have hit the nail on the head with that observation; the single-broker-at-a-time-per-driver design of Hubitat's MQTT API in combination with the long-running nature of MQTT connections probably explains why Hubitat decided to make the MQTT functions available only in driver code and not in app code; the idea is that a device (i.e. a running instance of a driver) encapsulates the connection to a single MQTT broker. Even though a single call to mqtt.publish() feels a bit like doing a single httpPost(), I was forgetting about the long-running connection, to the mqtt broker, that has to exist in the background in order for mqtt.publish() to work. Thank you.

1 Like