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
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?