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)

John S
  • 481
  • 2
  • 7

3 Answers3

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

Mawg
  • 3,147
  • 1
  • 13
  • 35
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.

Sean Houlihane
  • 10,524
  • 2
  • 26
  • 62
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.

kalyanswaroop
  • 1,208
  • 5
  • 16