The Internet of Things is not a smartphone app


Recently, I’ve noticed an interesting trend in product introductions in the Internet of Things (IoT) space.   There seems to be a lot of manufacturers that want you to believe that wirelessly controlling a device by a smartphone app is “the Internet of Things”. Well of course it depends on your definition of the IoT, but simple control of a device via Bluetooth from a smartphone app doesn’t really qualify as an IoT solution to me.

In my opinion, to qualify as an IoT “product”, the product needs to:

  • Be a device that is collecting data and optionally controlling a remote device
  • Have the ability to communicate the data collected to the cloud
  • Have the ability to perform data analytics on the aggregation of the data collected to derive new value

To illustrate the difference between simple local control and a true IoT application, consider the example of a device designed to turn a light bulb on or off from your smartphone. Aside from it being pretty cumbersome to do (start the app on your phone, select the right screen, scroll to find your particular light bulb, then tap to turn it on — I think I’ll just go flip the switch on the wall), simple controllers do not make use of other devices that might work in concert with the light bulb controller — say a motion detector. A more sophisticated light bulb controller that worked in conjunction with a motion detector by passing messages over the local area network could automatically trigger the light bulb controller to turn the light on when someone entered the room. No clunky smartphone interaction is required. By having the ability to have separate devices work together, the process is simplified and much more useful.

Next — consider the integration of a cloud-based server that can communicate with the light bulb controller. By sending the device’s status to a server, I can track when the device is on or off from the cloud. Now imagine that I do this for every light bulb (or any other appliance) in my home.   I now have data available that shows the state of all of my devices in real time and data that shows how each device is utilized over any time interval that I choose. I also gain the ability to control my device from the cloud — I no longer need to be within Bluetooth proximity to control my lights — I can do it from virtually anywhere that I have an Internet connection. This gives me additional capability to create cloud-based software to set up a schedule when I want specific lights to go on or off in my home automatically. Again – no smartphone app required.

Lastly, after accumulating light bulb data over time, I can now look at it as an aggregation and derive important and valuable information from it. For example, I can track my overall energy usage over a day, month, or year. I can tell if a bulb is burned out (i.e. if it is not consuming electrical current) and needs replacement.   I can combine my lighting control data with data from other systems to provide a comprehensive picture of my home or office energy usage / savings.

If I am the light bulb controller’s manufacturer, I can use the data accumulated in the cloud to determine how my customer is using my product (how often, how many times, at what times, etc.). I can also derive quality information about all of my devices in the field — time between failures, most common failure, etc. The data allows me to understand my market and use this knowledge to create better products and more compelling solutions to stay ahead of the competition.

In our small example of the light bulb controller, you can see the value of not only controlling your devices locally, but the additional value of combining the function of the controller with other devices, the value of interacting with your device via the cloud and using data analytics on that data to derive new value. Thinking beyond simple light bulb controllers, imagine applying this same mind set to IoT solutions for factory floors, agricultural applications, transportation, oil/gas rigs, medical, home automation, and any other industry that involves process control.

Now that is the Internet of Things.

Real world wireless communication for the Internet of Things


When implementing an “Internet of Things” (IoT) solution, an important consideration is the wireless technology(ies) that will be employed to get data from your devices (sensors, gateways, etc.) to the cloud. As with most technologies, there is a confusing array of options — each with its strengths and weaknesses depending on the specific application.

Frequently the discussion around wireless technologies centers around specs, throughput, standards, etc., but what is really needed is a practical guide to implementation for specific applications.   Based on our experience in the field deployments we have made, we would like to share some of our thoughts regarding the current state of wireless technology for IoT.

Before the Tech Talk

Before getting into the bits and bytes of any particular communication standard, consider the following factors and decide on the characteristics of your device and its deployment:

  • Will my device be stationary or mobile?
  • Is there a power source that can be utilized for the device or will my device rely on its own power?
  • What is the range necessary to transmit / receive data to and from the device?
  • How often will my device need to communicate to the cloud?
  • What is the volume of data that will be sent?

These factors will be important as you decide on a communication technology for your system. As we will discuss, each form of wireless communication has specific attributes that may either make it a preferred choice or that may disqualify it from your selection process.

Some common wireless communication technologies to consider

We’ve captured a few of the most popular wireless communication technologies used in IoT deployments below along with some useful information to help during the selection process:

  • BLE — which stands for Bluetooth Low Energy. Also known as Bluetooth 4.0, BLE is useful for short haul communication (usually less than 100m) between devices. It has a moderately high data throughput rate and is deployed frequently in battery operated applications due to its low power requirements. It is really a “point to point” communication scheme between devices without networking capability.

Some other key points regarding BLE:

  • Every modern smartphone has BLE compatible radios and software stacks, making communication between your device and a smartphone relatively easy to implement.
  • Bluetooth technology is evolving quickly and specifications change accordingly, making backwards compatibility a potential issue for your device.
  • BLE can be implemented in an embedded design for < $5 in quantity
  • Not really well suited for direct communication to the cloud as it does not support HTTP for REST interfaces. It typically requires a gateway that can transfer data on the BLE side to a HTTP communication path (typically Ethernet or WiFi).       We have used smartphones as gateways for this purpose.
  • Zigbee —  is a radio technology used to create personal area networks and is very useful in certain IoT deployments.   Zigbee is also a short haul communication scheme, but has the additional benefit of being able to operate in a “mesh” network in which all Zigbee nodes can pass messages between other nodes, effectively increasing the distance that can be covered. This is useful in multi-point deployments where you may have multiple sensors distributed in a concentrated area (i.e. manufacturing floors, home automation, etc.).

Some other considerations for Zigbee:

  • Typically Zigbee is very power friendly, with low stand-by current draw and relatively low power consumption during transmission.       This makes it suitable for battery powered devices.
  • Zigbee has found a following over the past few years, particularly with home automation OEMs.
  • Data throughout is modest (up to 250k bits/sec)
  • Secured via 128-bit encryption keys.
  • WiFi — started as a wireless extension of Ethernet for computer networking. It was widely adapted in the consumer and industrial spaces and has become the standard for networking PCs, tablets, notebooks, and associated peripherals. It has extremely high data throughput — however this comes at the expense of its power requirements. Range typically is up to 100m, however this can be extended with specific antenna types.

Some other key points regarding WiFi:

  • Ubiquitous
  • Universal smartphone compatibility
  • Affordable — can be implemented in an embedded design for < $5 and frequently the connection to the Internet can be obtained for free
  • Well suited to communicate through the Internet to a cloud server — universally supports TCP/IP and HTTP to provide REST interfaces to cloud services
  • Well protected and controlled from a security standpoint
  • Relatively high power usage
  • Sometimes difficult to connect IoT devices to corporate IT infrastructure because of corporate policies on security.
  • Cellular — utilizing a network established initially for voice communication, cellular offers a wide bandwidth data capability that does not depend on local access points or routers. Its range therefore is virtually limitless (as long as you are in an area covered by cellular coverage).   However, you will pay for each byte transmitted / received with this technology and of all of the technologies discussed, it has the highest requirement for power consumption during transmission.

Some additional points regarding cellular:

  • Cellular benefits from security models already established for regular voice communication
  • This is the only technology discussed that charges per byte of data transmitted or received. While these rates have come down recently (and will continue to do so), it may be a factor in your deployment
  • Network coverage can be an issue is specific deployments — especially indoors on factory floors, etc.
  • Power consumption is high, especially during data transmission.       However, if your device has a power source readily available, this may not be an issue
  • Device cost is the highest in terms of the devices discussed here — typically $20 in volume. This price will come down as higher volumes of these devices are manufactured for IoT applications.
  • Other
    • A ton of other “standards” in the Low Power Wide Area Network (LPWAN) arena are beginning to surface — including SigFox, Dash 7 Alliance Protocol, LoRaWAN, nWave, Weightless-P and Weightless-N, IEEE 802.11ah, and LTE Cat-M. These standards are emerging as a direct result of needs in machine-to-machine communication.
    • Some of these new standards have started to gain traction, particularly in specific industry segments.
    • Estimates show that today the cost of a typical module ranges from about $5 to $20, depending on the specific technology. However, the cost per module will eventually fall below one to two dollars in volume quantities.

So in summary, selecting a wireless communication technology for your IoT deployment requires careful consideration of a number of factors.   It is critical to understand where your device deployment will happen, what your data requirements are, and how the devices will operate after deployment.   Power is always a consideration, as is the overall cost of the device itself and the costs associated with on-going support.

We’ve seen IoT wireless communication projects suffer due to the mismatch of actual needs versus the technology chosen — spending the appropriate amount of time and energy on this decision will avoid expensive redesign / rework after the fact.