Real-time web-app for IOT devices

Question

Goal

I'm currently building a web-application to control multiple IOT devices over the cellular network, given the nature of the devices (working off battery power and operating in network constrained environments) I have chosen HiveMQ as the means to facilitate communication, this is a message broker which implements the MQTT protocol. I need to maintain a constant stream of telemetry updates from each device which are displayed in the web-app to the user in real-time. In addition I need to be able to send a command to a device and receive a response from the device as to whether it has successfully started (not completed) performing the issued command. If the device cannot perform the task for some reason it sends back an error code which the user will be notified of in the web-app.

Current Prototype

I have built a prototype (which currently only works with a single IOT device) using a NodeJS back-end by using a MQTT client and socket-io (web-sockets).

I understand its not the convention to see request/ response over a pub/ sub mechanism, however the MQTTv5 spec supports a request/ response pattern and MQTT plays nicely with constrained devices. Honestly I'm not really aware of what a suitable substitute for MQTT would be for this project. Also note I discarded the idea of a 'MQTT over web-sockets' client library (ie: Paho mqttws) as it exposed to much information about the MQTT broker.

Scaling the design

I'm now extending my prototype towards supporting multiple IOT devices, my thinking is to continue using MQTT client -> web-socket to receive real-time telemetry updates and to use a REST API to issue commands to devices. HiveMQ provides an extension frame-work in which I intend to build the REST API as an extension on the MQTT broker.

Future Problem to consider

Lastly, as I continue to extend this project I will need to find a way to handle the event in which two users each try to send a command to a device at the same time. My sense is that using a REST API makes this issue easier to solve as there is a central point in which I can handle / block a second command being issued at the REST API and can avoid the message being pushed to the MQTT broker.

Question

Does what I have described seem to be a reasonable design given the requirements I have outlined or is there a better approach?

I'm wondering if there is a better way to accomplish this as this design feels slightly unconventional. Any feedback greatly appreciated.

Answer 1

If you need to scale this to thousands of devices, I would not have the bottleneck at the cloud, of trying to prevent a second command.
Instead, I'd let the device have the concept of a "session", which starts when a certain command is received and ends when the execution ends or an explicit abort command is received.
When the command session starts or ends, that fact can be broadcast so that all UIs can know. If there's a second command that comes in before the UIs can block it, the device can return a "session ongoing" error (unless the command is for an explicit abort).
Yes. Just make sure that the device does not try to process multiple IoT messages in parallel. This way, your cloud piece can scale and you will be easily (relatively) move it to other IoT platforms if needed.