I’m currently building a web-application to control multiple IOT devices over the 4G network. In essence the app will enable the user to control each device by issuing a series of commands to a device and have the device perform those commands. For example one command might be move to ‘x’ location. The user will also be able to see the location of each device displayed live on a map.
I have built a prototype using NodeJS, in the back-end of the web-app I have an MQTT client which subscribes to a general ‘telemetry’ topic, this receives telemetry updates for all connected devices.
For example if 2 devices topics are as such:
‘telemetry/device1’
‘telemetry/device2’
I subscribe to ‘telemetry’ receiving updates for both devices. I then send these updates over websockets (socket.io) to the front-end of my application. It works like the following:
(device1 telemetry update) → MQTT-client → socket.io → display UI update
I discarded the idea of an ‘MQTT over web-sockets’ client library (ie: Paho mqttws) as it exposed to much information on the client side. Sending commands to a device are handled much the same way, I send the command over websockets to the MQTT client which publishes the command on the topic the device is subscribed to.
When sending a command to a particular device I need to receive a response from the device indicating if the command has been successful. Note I don’t mean successfully received by the device but the result as to whether the device has successfully started the issued command or failed.
ie: a command of move to x location - the response should be a success which indicates the device is now proceeding to the specified location or return an error code as to why it couldn’t comply.
I want replace sending commands over websockets with a ‘commands’ API which will allow the caller to send commands and receive a response as I have previously described. I wanted to accomplish this using HiveMQ’s extension framework.
I found a post in this forum similar to what I’m describing - it includes a response which links to a request/ response example on github:
Now from my understanding its not generally not a good idea to try and combine the synchronous request/ response of an API with the asynchronous approach of pub/ sub. However with the new MQTTv5 spec is this type of design finding its way into API’s or is this just a bad practice to try and put MQTT request/response into an API?