LED lights wait for the right IoT standards and wireless protocols01-04-2015
Early Internet of Things (IoT) initiatives in smart buildings are already making business in billions of dollars in value through improvements in operational efficiencies. In commercial markets, LED lights technology and advanced lighting controls, when done right, can light up buildings with useful data.
Whether dealing with new construction or retrofitting existing buildings with energy-efficient LED lights, placing advanced sensors with every light fixture gives organizations the ability to capture vast amounts of data and gain deep insights into their workspaces. The energy savings from such systems more than justifies their installation costs, while the insights they produce create an environment responsive to each user and create new real estate opportunities.
Such systems require wireless networks to connect all the sensors; yet, nowadays, no single wireless standard exists that adequately supports the rapidly evolving needs of data-intensive enterprise IoT applications such as advanced lighting controls.
Most wireless networking protocols in use today were developed with a certain reasonably well-defined set of problems and restraints that they were meant to solve. Wi-Fi, for example, was designed to provide wireless connectivity to computers and smart devices. The diversity of device types, power sources (e.g., battery, solar), and physical environments for the new wave of IoT devices presents a challenge for existing protocols.
One of the best marketed protocols, ZigBee, is a low-cost, low-power wireless mesh network standard designed for battery-operated, small-scale, low-bandwidth home networking. Lately, ZigBee has been going through various deformations to meet the needs of applications for which it was never originally designed.
The problem with ZigBee is that it ties the application layer (i.e., how a LED light fixture should behave) to a physical or data-link layer (i.e., how the lower layer wireless protocol behaves). This would be like tying your smartphone and its applications to 2G mobile technology so that it is unable to leverage 3G and 4G networks as hardware and wireless technology evolve. ZigBee thus lacks the network scalability and performance that would enable it to ride Moores and Metcalfes Laws.
Years ago, when new advanced lighting control systems with limited functionality were introduced, ZigBee filled the space for a standard. Fast-forward to today, though, and ZigBee has quickly grown too old for advanced lighting controls. It now in fact has become the source of bottlenecks, blocking the greatest source of value from modern enterprise IoT applications - all the data these applications produce.
ZigBee was also developed and is maintained by a group that requires paid membership. Yet history has shown that the best way to drive technology innovation is through standards developed by organizations committed to an open process. Protocols that have enabled the Internet and that have stood the test of time, such as TCP/IP, for example, were developed through an open process.
Similar protocols, such as X-10, Insteon, and Z-Wave, have also filled the space for the fairly basic home IoT applications of today, and a number of major manufacturers are making the leap to Wi-Fi for IoT in the home. Other standards, such as AllJoyn and Thread, that are being built from the ground up to enable the flood of coming IoT applications and data have real perspective. Yet these standards also were primarily developed for small home deployments with limited scalability requirements.
Whats the solution? The shortcomings of ZigBee make it unacceptable for advanced lighting controls or other enterprise IoT applications. The release of ZigBee 3.0 is unlikely to solve all of its issues. Yet a wireless networking standard for industrial and enterprise IoT applications, and specifically for lighting controls and smart building systems, will come out within the next couple of years.
In the meantime, and regardless of the standard that finally wins, the discussion around interoperability should focus on open application programming interfaces (APIs). The way the data is produced by sensors and devices is almost irrelevant - there will always be a need for some form of mediation. Deploying systems that have strong and open APIs will ensure that all your systems can work together, which is what is important in the end.