5 IoT Deployment Flaws to Avoid

For the third time in as many weeks, the IoT alarm system deployed in my home decided to go on the fritz.

The first time, sensors started to chirp annoyingly right after I had gotten the kids to bed. A simple battery change seemed to resolve the problem. The second time it happened, I was boarding a red eye flight from the west around 2 a.m. PDT, which left my wife scrambling to find, lift, and use my extension ladder to silence the devices before the noise woke the kids. Finally, tonight (does 3 a.m. count as tonight or this morning?) the devices again went off—this time, allowing me to realize that it was the same two culprits causing the problem. These three late-night shenanigans led me to unveil five flaws that undoubtedly plague many consumer IoT devices, which we should be avoiding as we are designing.

Flaw #1 – Not Automatically Setting Device Time and Using It Wisely

An Internet-connected system should be able to go out onto the Internet and retrieve the current time. That time can easily then be sent to each sensor node in the network, so that time is synchronized throughout the system. Time information can be useful to determine whether it is an appropriate time to signal the user that there is a problem with the system. For example, notifying a user with an annoying, loud chirp that the battery is low probably is not something that should be done at 2 a.m. A few lines of code could easily defer sounding the alarm until 6:30 a.m. or, heaven forbid, some user configurable time.

Flaw #2 – Audible Alarms that Are Confusing

As part of my alarm system, I have at least a dozen smoke and CO₂ detectors that are located throughout the house. In my late-night grogginess, I had narrowed the culprits down to two CO₂ detectors—one of which was located about 20 feet off the ground in the living room, and the other which was thankfully within arm’s reach. When these sensors went on the fritz, they started to chirp like a smoke detector that needed to have its battery changed. The first time this happened, the solution was to change the battery. The second time, since it was a different troubleshooter, the solution was also to change the battery. The third time, when both troubleshooters were there, we looked at each other and said, “But I just changed those batteries!”

So what, then, is the deal with that low-battery chirping noise? Enter Google. A quick late-night search reveals that these detectors, when tripped, make the same noise as a smoke detector that has a low battery. This makes me wonder: Two sensors both tripped; is there a CO₂ leak? Changing the battery cleared the alarms and they have consistently gone off seven days apart within a few hours. Could it be something else? Did I mention that these detectors are located right next to a smoke detector? 

As designers, we need to make sure that the audible alarms our devices produce are distinct and easily recognizable. Having a CO₂ sensor that trips with a sound that is recognized as a low battery indicator has some very serious potential safety consequences.

Flaw #3 – Not Tracking When Assets Need to Be Replaced

The CO₂ detectors were definitely the issue. After having to scale 20 feet in the air while half asleep, I had the common sense to bring the sensor into the light and carefully examine it. Swapping out batteries had cleared the alarm and one would hope that if CO₂ was really present, the devices would trip again. Since this didn’t seem to be the case, and no one was more confused or loony than normal, a good bet was that there was something wrong with this connected device.

Upon careful examination, I discovered that there was a sticker inside the device located near the battery that stated: “Replace by Feb 2018.” It’s currently October 23, 2018 at around 4 a.m. Yes, I have sensors that are supposed to be monitoring and protecting my home that are past their usable shelf life! The problem is that the company that is supposed to be managing these devices has no clue that their asset has expired and instead is waiting for system failures to occur before they come out to replace them.

As designers and companies, if there is a usable shelf life for our products or even for batteries that need to be replaced, we need to track:

This allows service technicians to be proactive in maintaining these devices in the field. If you know that you are servicing client A, and client B needs to have their system maintained in a month but you’ll be in the area, scheduling the two together can dramatically save travel time and costs. This not only maximizes the number of clients serviced, income, etc., but also keeps customers happy and, more importantly, safe.

Flaw #4 – Not Assigning Understandable Location and Device Information

What is interesting about the system I have is that, despite a really cool application that I can use to check the status of the system, the location and device information is sorely lacking. For example, the sensors did report to the server that there was a problem. Checking the application, though, revealed that sensor #18 in the living room was having a problem. There are six sensors in the living room. While our systems may be designed to be generic, for system users, we need to make sure that we can assign human readable and accessible information, such as “Sensor #18, Living Room CO₂, Get the ladder.”

Flaw #5 – Reactive, not Proactive, Customer Service

As engineers, we probably don’t give the customer experience much thought. That’s something that the marketing and sales team should be worried about and can relay to us developers. The fact, though, is that at the end of the day, the customer experience is what will determine whether our company is successful. For that reason, I believe customer service should be proactive. Despite my home system being actively monitored, I did not hear a single peep. The alarms were actually tamper alarms; shouldn’t that signal to someone that something isn’t right?

At the end of the day, it turned out that the CO₂ detectors had actually expired and were triggering a tamper detection signal. As I mentioned earlier, this was no different than the CO₂ detected alarm, which also matches a smoke detector's low-battery alarm. When we design our connected world, we need to pull ourselves away from the cool technology that we are building and look at the system through our customers' eyes. How will they feel being woken up in the middle of the night? Will they realize instinctively what that alarm means?

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost, and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer, and holds three degrees, which include a Masters of Engineering from the University of Michigan. Feel free to contact him at [email protected], at his website www.beningo.com/, and sign-up for his monthly Embedded Bytes Newsletter.