11

MQTT is widely used in IoT when it comes to exchanging application data between the end device and the host service. The publish-subscribe model makes it easy to use: no handshaking, negotiating etc (at least above the MQTT protocol layer). It's primarily geared towards data-producers being able to distribute their data easily to consumers.

However, when it comes to a central server wanting to configure settings on an end device, I'm not sure that the model is very suitable. The server will want to send a command to the device and wait for a response back (e.g. read a specific setting, wait for response), which doesn't really suit MQTT's publish-subscribe model.

I was wondering whether there are any existing protocols that are geared towards send and receiving commands and configuring remote devices?

Improve this question
5
  • 1
    Are you sure MQTT doesn't permit the client to subscribe to a control channel? I think this is the place to start looking for answers, but I'm not well enough up-to-speed to sumarise in an answer en.wikipedia.org/wiki/Representational_state_transfer
    – Sean Houlihane
    Commented Apr 28, 2017 at 12:30
  • 1
    Don't forget, the endpoint needs to be the one initiating the channel, so it's in control of power consumption.
    – Sean Houlihane
    Commented Apr 28, 2017 at 12:31
  • 1
    @SeanHoulihane It is certainly possible to use MQTT to send and receive commands/settings as you describe, but the way I see it, ideally you need to have a protocol that is "session-based", i.e. you create session, send a command and receive a response in that same session, thus easily linking the response to the original command. MQTT is message based, so there is nothing at all to link messages with each other - it's up to you to handle that part. I was wondering whether there was a readily available protocol that I could use for that purpose.
    – Amr Bekhit
    Commented Apr 28, 2017 at 13:19
  • 1
    en.wikipedia.org/wiki/OMA_LWM2M I'm not sure exactly how, but the cloud seems to be able to make PUT or POST calls to trigger a callback in the client.
    – Sean Houlihane
    Commented Apr 28, 2017 at 13:29
  • MQTTv5 has header fields to mark a message as a response to earlier message.
    – hardillb
    Commented Mar 15, 2019 at 17:28

2 Answers 2

Reset to default
7

Sounds like a job for CoAP:

Like HTTP, CoAP is based on the wildly successful REST model: Servers make resources available under a URL, and clients access these resources using methods such as GET, PUT, POST, and DELETE.

From a developer point of view, CoAP feels very much like HTTP. Obtaining a value from a sensor is not much different from obtaining a value from a Web API.

It can apparently be implemented with very low overhead:

CoAP has been designed to work on microcontrollers with as low as 10 KiB of RAM and 100 KiB of code space

CoAP is specified in RFC 7252, and there are various implementations (e.g. in C).

It's very heavily inspired by REST as used with HTTP for web APIs, so if you're familiar with those, you'll quickly pick up CoAP. If not, you might find this presentation useful for context. The idea is that each HTTP method has a semantic meaning, e.g. GET requests information from the device without changing anything and POST, PUT and DELETE mutate the data.

As you say, publish/subscribe models wouldn't work for a situation where your device acts as a 'server' to the central system coordinating (which acts as a client to each device). Instead, a model similar to HTTP is ideal, except HTTP has far too much overhead, which is where CoAP comes in.

Improve this answer
-1

I was wondering whether there are any existing protocols that are geared towards send and receiving commands and configuring remote devices?

Yes, there is a better protocol for device management in IoT. It is LwM2M - It is much more efficient than MQTT and above COAP, MQTT and HTTP.

LwM2M comes with a well-defined data and device management model, offering a variety of ready-to-use standard objects (IPSO Smart Objects), connectivity monitoring, remote device actions and structured FOTA and SOTA updates, whereas in MQTT these features are entirely vendor and platform-specific. What follows is that with MQTT, firmware updates or any other management features must be created from scratch. Contrastingly, LwM2M offers firmware upgrades as one of its basic functionalities, so there is no need to invent any new building blocks for communication.

Here you have comparison MQTT vs LwM2M and whole crash course.

Improve this answer
1
  • LwM2M is not a protocol.
    – not2qubit
    Commented Mar 18, 2023 at 22:36

Your Answer

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

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