IoT MQTT/Thread/6loWPAN wireless sensor platform

Use OpenThread to develop a wireless MQTT 802.15.4 mesh sensor platform with the TI CC2538 programmable with Javascript

Similar projects worth following
Thread is an up and coming IoT wireless protocol that is gaining momentum now with an Open Source implementation OpenThread with support from Google/Nest, Qualcomm, TI, ARM and even Microsoft.

Wireless networking standards for IoT solutions are fragmented and difficult as there is no predominant standard (ZigBee and Z-Wave being the most popular for home automation) and each standard has its pros and cons. Given the momentum Thread has got in the last 2 years it has a good chance of becoming the future predominant IoT wireless network standard.

I want to develop a generic wireless sensor platform that can be programmed to collect sensor data by using JavaScript (the new IoT.js being developed by Samsung) to manage the sensors.

This project is in the conceptual stage and although I'm confident I can build this on my own (having done similar projects) I'd like to get community feedback and potentially even help to develop the platform.

My needs are as follows:

  • A reusable sensor platform that can be applied to many different wireless sensor use-cases (eg. motion sensors, window sensors, light detector etc.).
  • Utilise Open Source components (not reinventing the wheel)
  • Use widely used standards / implementations that have a future
  • Long range, cell or AAA battery usage for 1 year
  • Mesh based
  • Use a high level language to manage sensors
  • Windows and Linux PCs used as the edge routers
  • Integrated MCU and radio to keep size & parts count down
  • DIY without too much difficulty (ie. not having to write too much complex code, ICs that are solderable at home etc.)

After some research, it seems there is finally hope for consolidation of all the IoT protocols and standards coming together. Alljoyn and Iotivity's parents Allseen and Open Connectivity Forum (OCF) have merged and future versions of Iotivity will incorporate some of the best aspects of Alljoyn and be compatible with older Alljoyn systems. Thread will also be a standard supported by OCF and ZigBee will be supported over a Thread network and is already supported today by Alljoyn. Z-Wave can be supported on Alljoyn today with an adaptor code from Microsoft. My feeling is that the new OCF implementation will eventually overtake ZigBee and Z-Wave to be the predominant IoT networking standard, but that is still a few years away.

The focus for this solution isn't the application layer standards like Alljoyn or OCF, which describe functions like discovery and configuration but on the first 4 network layers of the OSI model, specifically the wireless link layer (MAC) using 802.15.4, the IP support from 6loWPAN and the mesh / routing support from Thread. And there doesn't seem to be a low power implementation of Alljoyn or Iotivity for smaller devices (there is a 3rd party closed source for a fee solution by a Texas Instruments partner but only for WiFI).

But choosing Thread as the layer 3 protocol will enable a future implementation of Iotivity which should have Thread as one of its supported protocols when the Alljoyn functionality is merged. I see Iotivity as the 'end game' for IoT networking as it will provide all the rich application layer services that will make IoT implementation for the developer and end user easier. In the meantime, as the rest of my solution is pub/sub based and uses MQTT which will be sufficient for the OSI data layers in my environment, and Thread supports encryption and commissioning services anyway.

Other reasons for choosing OpenThread:

  1. There is a TI CC2538 software implementation available at GitHub, as well as drivers for Windows and Linux. This alone is the major reason - implementing complex services like mesh routing and UDP over IP is something I definitely didn't want to code.
  2. CC2538 is both a MCU and a radio on the same chip, which simplifies implementation, size and cost. Although Thread does not support yet the newer, smaller, lower power and cheaper CC2630 which would be a preference, there isn't that much difference with the CC2538 that porting shouldn't be too hard. The CC2538 has a lot of IO that isn't needed for a sensor platform and the reduced RAM/ROM and GPIO of the CC2630 will be better suited.
  3. I have been developing all my microcontroller solutions on the microchip PIC platform and although I know the platform fairly well it has a lot of quirks in the architecture and implementation, and I want to switch to a toolchain that uses Visual Studio (my preferred development environment). There also isn't an integrated radio / MCU like TI has, and I prefer TI as a silicon vendor as they seem to have the best support (although the Microchip community is also good). The TI CC2538 has a GCC toolchain that can be run in Visual Studio using an add-on VisualGDB.
  4. I would prefer a sub-Ghz radio (eg. 915Mhz) to the crowded and shorter range 2.4Ghz however the multi-channel hopping and mesh features of Thread and CC2538 will negate these factors.

  5. Why not BLE - lower power but has short range and not meshable....
Read more »

  • Next Steps

    deandob10/30/2016 at 06:38 0 comments

    This project is at the concept stage. If you are interested in contributing or provide feedback, please use the comments system. If successful I may launch a Kickstarter and will make the source and gerbers available on GitHub.

    To do:

    • Design the sensor hardware platform - from the CC2358 reference design + battery power supply.
    • First implementation will be for a pool chemical sensor that I am in the process of designing.
    • Implement the Thread drivers on Windows (being developed by Microsoft now)
    • Integrate IoT.js JavaScript engine into the ARM M3 code from the CC2358 Thread reference implementation, including a UDP terminal function and MQTT for pub/sub.
    • Prototype the board and software
    • Implement the next version of Iotivity for plug and play IoT.
    • Release on GitHub

View project log

Enjoy this project?



Wassim wrote 10/03/2018 at 09:20 point

Hi, I find the reasoning coherent, and noticed that the Zigbee Alliance are catching up with dotdot to allow a common app layer for both Zigbee and Thread, that should guarantee a smooth transition.

Have you taken MQTT-SN in consideration ? Nordic has an MQTT-SN over thread implemented on their SDK. Same as standardised bridging using ipv6 in RF mesh networks, I would expect MQTT-SN to standardise the interfacing the RF mesh network with the real MQTT over ethernet.

I like the idea of making the interface with the RF mesh network more generic and have been working with such concept since the early stages of my custom mesh network (, now that Zigbee devices got cheaper, I'm integrating them in my home automation using an open dongle (The ConBee with REST and websocket API).

On the long run, I think our efforts have common purpose.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates