Make legacy IoT data protocols part of an IoT strategy
IT pros implement IoT devices to create and connect data; however, the lack of one IoT standard protocol counters the ability of IoT devices to work together.
Many protocols used with IoT devices today have been around for decades, but IT pros might not know what is available and the best practices for mixing technology in an IoT deployment.
Older hardware and software that uses low power and covers short ranges to prevent interference can serve current IoT devices effectively. Some of the earliest protocols -- such as the X10 standard and Insteon's proprietary protocol -- work both in radio frequency and power-line connection modes, which are popular modes in home control and security applications and are used by small and medium-sized businesses or branch offices. These legacy protocols can serve IT pros' IoT strategies.
What older IoT data protocols are available?
Wi-Fi is rapidly becoming the personal-area network strategy of choice for devices like thermostats and doorbells. There's increased interest in Bluetooth as a location-oriented IoT model for tasks including asset tracking, warehouse goods movement and in-building navigation. Zigbee is defined by IEEE 802.15.4 and controlled by the Zigbee alliance. Zigbee is the legacy protocol and architectural model most likely to fit an IoT deployment. JupiterMesh, another Zigbee Alliance protocol, is designed for mesh applications in industrial networks.
Even if one protocol has advantages over another for one aspect of an application, don't mix protocols in an IoT deployment.
There is no single standard for a remote protocol, which means that vendors have produced their own proprietary IoT network models, locking users in and creating a major risk if a vendor goes out of business. Amazon, Apple, Google and the Zigbee Alliance have formed a working group to address this issue.
The development framework within IoT hubs has no accepted standard. Every IoT hub has its own set of tools for programming, ranging from simple rules to complex program APIs. The result is that IoT applications developed for one hub are often incompatible with all other hubs on the market. The Zigbee Alliance's All Hubs Initiative may standardize hub development.
The connectivity range issue has divided legacy IoT from the popularized vision of a universe filled with public internet sensors and controllers available for anyone to use. Many personal-area network protocols don't cover a home without careful placement of repeaters. An office building or campus will require considerable network engineering just to build full coverage. Amazon's Sidewalk model seems to promise a federation of home and office IoT networks to create a community network.
How to pick IoT data protocols
Even today, legacy protocols can do a lot for an IoT plan if adopted sensibly. For greenfield installations, the most critical step is to pick only one IoT connectivity protocol. Even if one protocol has advantages over another for one aspect of an application, don't mix protocols in an IoT deployment. Initiatives to address legacy protocol limitations could eventually facilitate the mixing of sensors, controllers and hubs. For now, multiple IoT data protocols will only make an IoT integration more complicated.
If an IoT application can't use only one protocol, consider reviewing tools that can harmonize different IoT protocols in a single installation, such as Dotdot, an application-layer model from the Zigbee Alliance. Harmonizing tools can't share different protocols on the same hub unless the hub itself supports that.
Divide IoT elements by area and application, rather than creating very large IoT networks. Too many elements per hub inhibit effective management of IoT elements, and some hub designs might limit the number of hosted elements. Each area should have its own IoT hub and, where possible, organizations should use the same hubs.
If an organization already has many different legacy protocols installed and an IT pro can't justify replacing them, they will need hubs controlling each IoT area. Whether IT pros can unify on one IoT connectivity protocol or not, they must integrate multiple hubs into an IoT system. IoT applications need an application layer to unify the elements. Individual hubs can't access events generated on another hub's network, nor can hubs control devices not linked to them. The purpose of the application layer is to support unified information collection and control and to provide a single place to store and enforce IoT policies on all devices.
Building an IoT system through hub integration involves using the external APIs exposed by the hubs. Some hubs will provide a generalized northbound API to facilitate multi-hub integration, but most will support things like smartphone access. Generalized APIs can usually be repurposed to support integration at the application level, which provides the ability to see individual events and remotes via the API. If this isn't supported, creating a unified application layer will be impossible and IT pros should replace the hub with one that has better APIs.
Access the hub APIs from a central system to provide IoT-wide control and policy management. Ideally, it should work with the individual hubs. Event and control needs that are entirely within the domain of a single hub should be actionable at the local hub level. The application layer will be responsible for bringing in more modern IoT technology, including those based on 5G or access to public sensors. Dotdot can provide a useful and unified higher-layer model for IoT.
The most important thing to remember in building an IoT plan that includes legacy technology is to make applications sensor and controller-agnostic. Create abstractions that are then mapped to the real devices, insulating the application from the mixture of technologies and vendors. That same step will prepare organizations for the mainstream IoT wave to come.
