Modularity, Reliability and Scalability (Hardware Journey @ Zenatix — Part II)
IoT 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 an innovative hardware (that can give the company an edge over the others), the focus is more on technical specifications rather than 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 realised that they also constrain us in terms of deployment. WiFi (being power 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 realisation 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 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 optimised 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 own 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 are able to 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 setup a Set Top Box or a router in your home)
- Extending the same for other battery powered end nodes with different sensors is straight forward with some minor hardware revisions. We are also coming up with a general purpose end node ourselves which can easily connect to any of the analog/digital sensor 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.
While OpenThread clearly 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 is 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 are 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 has been the focus for 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 a 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 on board) makes the whole hardware ecosystem modular, extensible and scalable.
(As explained in detail here) Together with the software stack that allows for plug and play configuration, deployment and maintenance of these hardware components and a highly configurable dashboard platform (where different screens can be customised 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.
