deandobMy 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:
- 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.
- 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.
- 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.
- 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.
- Why not BLE - lower power but has short range and not meshable. Why not WiFi - too much power drain for the sensor node. Why not Z-Wave - Not open and although has wide adoption today I'm not sure of its future, and needs more expensive modules for the node. Why not ZigBee - It is close to meeting the use-case needs listed above but Thread seems to be a better long term choice by using 6loWPAN and a more flexible application layer.