3

I have an existing IoT project based on MQTT and am looking at extending the application to include battery powered end nodes using Zigbee mesh. It logically seems the most appropriate way to do this is by using MQTT-SN over Zigbee for these reasons:

  • I already have an MQTT infrastructure in place
  • MQTT-SN supports battery powered nodes that can go to sleep for power conservation
  • It is designed to operate over non-TCP based communication platforms
  • It minimizes the amount of data that needs to be sent

However after researching how to go about implementing MQTT-SN, it seems there isn't much activity in terms of development being done the past few years.

So is MQTT-SN still a viable technology to use or has it been essentially replaced by something else? I haven't found anything that has a similar feature set that will accomplish what I need it to do. I'm OK with just developing new code to the MQTT-SN specification, but I don't want to put a lot of effort into making it work if it is already a dead technology.

EDIT - To hopefully clarify, I am assuming one or more of the following is true:
1. MQTT-SN is still new enough to be cutting edge and has just not been widely adopted yet. (great, I'll keep moving forward with it then)
2. There are easier and more pragmatic bespoke ways to accomplish what MQTT-SN provides with less overhead. (ok, I won't worry about using standards)
3. There is another technology platform that has supplanted MQTT-SN. (what is it?)
4. Most IoT communication is now over WiFi or cellular instead of BLE or Zigbee so MQTT-SN isn't necessary. (I'll need to rethink my project expansion)

5
  • 2
    Just because something isn't new doesn't mean it's obsolete.
    – hardillb
    Oct 6, 2019 at 6:56
  • 1
    Obviously this is true. My inquiry comes from the perspective that it does not look like there has been much development activity in MQTT-SN clients or brokers for several years. I'm just hoping to find out if there is a reason for that before spending a lot of my own time in pursuing that avenue as a solution. I don't believe my situation is unique and am hoping to get insight from those with more experience in this scenario as to what common practices are.
    – John S
    Oct 6, 2019 at 17:13
  • 1
    "However after researching how to go about implementing MQTT-SN, it seems there isn't much activity in terms of development being done the past few years" - this can happen when a technology is mature Oct 7, 2019 at 7:43
  • 1
    Ahem -> twitter.com/andysc/status/1186685475563757569
    – hardillb
    Oct 22, 2019 at 16:49
  • YES! Even though the version 1.2 spec is from 2013, at least it's being moved to the OASIS TC. This gives me enough confidence to devote time to working on core libraries where necessary. I'm still digging for more details, but this kind of answers my question: MQTT-SN is NOT obsolete, and will likely gain more adoption moving forward. TBH, because the spec was being hosted on the mqtt.org site, I wasn't even aware that it was still officially under the IBM umbrella.
    – John S
    Oct 23, 2019 at 18:42

3 Answers 3

2

First off, great question (and starred as favo(u)rite +1).

However after researching how to go about implementing MQTT-SN, it seems there isn't much activity in terms of development being done the past few years

this can happen when a technology is mature.

I haven't found anything that has a similar feature set that will accomplish what I need it to do

then why not stick with what you know? I am still coding AngularJS v1.x, because I am too lazy to learn TypeScript for Angular (non-JS), which is now at v 8 and counting.

By now you must have a great deal of common code that can be used on future MQTT projects, just as I have for AngaulrtJs.

The only argument I can see for abandoning a mature product, where you have already passed the learning curve and are now productive and knowledgable would be an announcement that there will be no future security patches, and I have not heard this of MQTT.

tl;dr - if it ain't broke, the grass probably isn't greener

1
  • 1
    To me, the current state of development of MQTT-SN clients does not seem to be mature. None appear to fully implement the spec and the ones I looked at are buggy. That combined with the fact that there hasn't been much activity over the last 2 years prompted me to post the question. TBH I will likely move forward with it (since I am stubborn that way), but wanted to put the question out there just in case I missed something.
    – John S
    Oct 10, 2019 at 7:53
1

I can only speculate one one aspect of the question:

  1. Most IoT communication is now over WiFi or cellular instead of BLE or Zigbee so MQTT-SN isn't necessary. (I'll need to rethink my project expansion)

This seems unlikely. Many devices have a battery-powered (or energy harvesting) requirement. Although WiFi and cellular can be implemented in a super low duty cycle, they were never designed for low bandwidth/high efficiency applications.

Of the devices I'm using, some of my lighting and my heating system are both Zigbee - and I'm hoping they are both in a 'live' roadmap.

Yes, there probably is some thinning out of the protocol stack to come in the next few years, but it looks like Zigbee has not yet been replaced.

0

MQTT-SN may have a bit of a difficult time in finding a product-market fit.

Here are the forces against it:

  • RAM and bandwidth get cheaper by the day.

  • It still needs a broker.

  • I havent seen a 'block transfer mode' (like RFC7959 for CoAP).

  • CoAP has been around for constrained devices and has evolved block transfer, observe mode and does not need a broker.

  • CoAP libraries are mature and CoAP has a big community.

Here's the forces for it:

  • Some developers are familiar with the MQTT paradigm.

So, MQTT-SN is for developers who were using MQTT and are now wanting to work with a small device and want to transfer this knowledge there and/or want the UDP aspect of the paradigm and dont want to do a one-off plain UDP or use other UDP based protocols such as those available for streaming media. Makes it a small crowd and alternatives are available.

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.