Listen to this articleIoT systems should be deployed where you get the best data and not where the hardware constraints allow you to.
This has been one of our biggest learning through the Zenatix journey. Often (and this is true more so in the enterprise side of IoT than the consumer side of IoT) when one engages in designing innovative hardware (that can give the company an edge over the others), the focus is more on technical specifications rather than a plethora of use cases that eventually the hardware may be used to serve. These varied use cases, if thought from the beginning, can dictate several design choices which can completely change the way the final hardware product will evolve.
When we started focusing on the retail segment at Zenatix, our competitor was deploying wired temperature sensors, running long cables from a gateway in the store to all the sensors deployed for monitoring ambient temperature throughout the store. We took a call to not do the same and instead developed our own WiFi-based sensors. While the WiFi-based sensors served us well over the years, we realized that they also constrain us in terms of deployment. WiFi (being power-hungry protocol) requires the sensor nodes to be powered and hence they often are deployed where the power socket is available (or can be easily retrofitted) rather than where we need the data. That does not mean WiFi was the answer to all the wired problems — Extending the same WiFi communication for our IR-based control of devices was one of the major mistakes in our hardware journey (covered in detail in this post).
Low power, multi-hop, mesh enabled wireless is the way to go for end nodes rather than using WiFi (which is generally a star topology).
This realization made us initiate our path on OpenThread almost 2.5 years ago. It was a well-thought-through and conscious call (backed by months of PoCs and reading — not going into the detail here but happy to discuss one on one if anyone is interested) to select OpenThread over BLE 5.0 at that time. Over this time, this choice also gets validated by the external environment e.g. the new C.H.I.P. project (backed by Amazon, Apple, and Google) also picked up OpenThread as the underlying protocol for communication. We have optimized and innovated quite a bit over the last couple of years to come to a stage wherein:
- OpenThread has become the de-facto protocol for end-node communication with the gateway.
- Powered nodes in the mesh act as routers as well as perform their function (often related to control)
- End nodes are battery-powered and connect to the nearest routing node as a parent. With 2 AAA batteries and 30-second sampling, we can achieve 18+ months of battery life.
- The whole system is very easy to deploy by an inexperienced electrician/technician, and end to end configuration is supported via a remote web application (pretty much the same way an inexperienced person can deploy and set up a Set Top Box or a router in your home)
- Extending the same for other battery-powered end nodes with different sensors is straightforward with some minor hardware revisions. We are also coming up with a general-purpose end node ourselves that can easily connect to any of the analog/digital sensors out there and will be seamlessly supported through a unified system.
- We have also taken some off-the-shelf hardware and run our firmware communicating over the same protocol to enhance the overall product offerings.
Wireless Mesh Connectivity between nodes in one of the field deployment
While OpenThread is beneficial over WiFi (due to its low power and wireless mesh capabilities), it is also beneficial over other low power protocols such as LoRa (due to mesh capabilities and higher bandwidth availability) allowing sensors to sample at a much higher rate and to also perform control (requiring frequent bi-directional communication) through these wireless devices in a much more affordable and robust manner.
Unfortunately, mistakes from which we learned a few years ago are what we see being repeated by the large players (from the Building Management System domain) as they launch their solution for the small footprint retail segment that is taking the WiFi/LoRa approach. Perhaps there are lessons to be learned for them and we are happy to engage in detailed discussions in this regard.
Modularity, reliability, and scalability have been the focus of our gateway design as well. I have covered the specifications and design choices in detail in a separate article. Besides what is covered in the article in detail, in the context of our solution for retail and buildings, the gateway
- Connects to cloud over 4G module (plugged into the mPCIE slot of the gateway)
- Connects to end devices on-site using OpenThread based Mesh (supported via a dongle connected to USB ports or an OpenThread card connected on M.2 connector)
- Connects to other building subsystems over IP protocol — e.g. BACnet over IP and SNMP
- Supports Modbus for connecting to off-the-shelf hardware such as energy meters.
- Allows for local configuration through the WiFi network created by the gateway using which our mobile application connects to the gateway.
We believe that expertise in a multi-hop, wireless, low-power mesh (enabling battery-powered sensing end nodes and modular/extensible control nodes) together with an industrial-grade gateway (supporting extensibility through a wide variety of interfaces available onboard) makes the whole hardware ecosystem modular, extensible and scalable.
(As explained in detail here) Together with the software stack that allows for plug and plays configuration, deployment, and maintenance of these hardware components and a highly configurable dashboard platform (where different screens can be customized for different stakeholders within/across customers without writing a single line of code), we believe we have the modularity, extensibility, and scalability of both hardware and software that puts us in the right position to reimagine the way traditional monitoring and control is done in Built environment.