1

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).

Current prototype

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.

enter image description here

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.

enter image description here

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.

3
  • 1
    Will your devices be constantly up, connected to the network, waiting for commands? This will dramatically increase their power consumption and decrease battery life.
    – jcaron
    Apr 18, 2022 at 9:00
  • There are operating hours for these devices, when they are turned on they are there to do work. Think along the line of robots performing actions, they will return to a charging station when their battery runs low. However, during this operating period even when not performing an action they remain powered on and are publishing telemetry information about the status of the device.
    – Edmond.D
    Apr 18, 2022 at 15:39
  • Could you clarify exactly how Paho websocket client exposes too much information about the broker? Jul 3, 2022 at 12:08

1 Answer 1

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.