Internet of Things or IoT can surely ease our lives. But developing them are something that is not quite easy.
Alan Cohen stated that when it comes to the Internet of Things, it’s both particularly easy to get something magical working a little bit, and particularly difficult to get the thing completed. When developing IoT products, this giant gap can lead to unrealistic expectations about project scope in the early phases.
As a software developer, Alan argues the 80/20 rule for standard product development turns into 95/5 for IoT projects. That is, the first 95% of an IoT project takes 5% of the total development time. This means that 95% of your IoT development time will be spent on that last 5%.
The reasons why is there a gap between the expectation and reality in developing IoT are:
- The general effort to make cool technology easier forexperimenters to use, associated with the Maker Movement, can fool us into thinking that technologies are easy to use forproducts.
- The IoT’s tendency to incorporate sophisticated technologies that can be devilishly tricky to make reliable and to do just what we want in real-world uses. These technologies include wireless, sensors, low power, battery power and charging, low-power operation, and cloud-based services.
Alan even gave a brief explanation on why the IoT technologies mentioned above will give more challenges when they’re combined.
Bluetooth and WiFi can now be founded in cheap and easy. You can purchase a module with WiFi and decent microcontoller in very cheap price, but rather than as something to tinker around with; things get complex, and fast. Here are just some of the issues you’ll need to address (or face unhappy users):
- Wireless association with the access point of our choosing, which may require a passcode. Without a keyboard and screen, how do you do it? Morse code? Magic spells? Of course, it can be done, but it usually involves writing significant software running on a computer or smartphone (that does have a keyboard and screen) to reach out to our device, and programming some parameters, a process that’s challenging to make intuitive and robust.
- All kinds of errors can crop up: Access points go away or passkeys are changed, microwave ovens (which operate at the same frequency band as WiFi and Bluetooth) can temporarily kill radio frequency (RF) transmissions, and so forth. You should handle these issues gracefully, hopefully in a way that lets the user know what’s gone wrong. And since RF errors are pretty common, they should never brick your device — i.e., leave it in a permanently inoperable state. That may sound obvious, but it happens if you’re not thoughtful. The classic bricking scenario is losing your link while in the middle of updating system firmware over the Internet, a scenario that’s easily mitigated by good product design.
- RF means Federal Communications Commission (FCC) certification: This is required in the U.S. and similar bodies elsewhere, particularly if you put your IoT gadget into production. Your product will need to be certified by a third party as being within legal limits for RF radiation and filed with the FCC, an effort that can range from a lot of work and tens of thousands of dollars to very little work and no extra dollar cost, depending on your needs and how clever you are during development.
Sensors are (typically) analog electronic components, and that’s what makes sensors tough. In the digital world, a 1 is a 1 and a 0 is a 0; if the voltages representing these bits are off by a few percent, it’s still pretty apparent they’re a 1 or a 0 — our information is functionally unaffected. By contrast, nothing is ever exact in the analog world, and if a signal is off by a few percent, then our information is off by a few percent. Voltages and currents can easily be off by a few percent for all sorts of reasons, and our circuitry needs to handle this gracefully. Very tricky stuff.
Batteries and Charging
IoT devices can be particularly challenging because they tend to use small batteries that have particularly changeable characteristics under varying conditions. A specific IoT challenge is RF transmission and reception, which can each draw a good slug of energy. (Did you know that active RF receivers can draw as much or more energy than transmitters?) Putting all this together, it’s pretty easy for battery life to be much lower than expected — even when a small battery is theoretically only half-discharged, the sudden power draw from turning on the RF circuitry, even for milliseconds, can pull battery voltage lower than our circuit needs, which can cause a system shutdown or other weirdness.
Low Power Operation
If you want long battery life and small batteries, ultra-low-power circuits are a must. Designing circuits to conserve every last bit of power is a non-trivial task that requires being clever about both circuits and software — it’s much more than picking “low power” parts. If you’re willing to roll up your sleeves and use the same microcontroller as the Arduino (the Atmega 328) with your own custom circuitry, rather than the Arduino’s, you might be able to extend that out to years, again depending on the application, but getting there requires methodical and exacting work. Very challenging stuff.
Cloud Based Service
The challenge with these services is that you cede a measure of control in exchange for ease of use. The control limitations break down into a few sub-issues:
- Can you create the user experience that you want?
- Can/will the service scale if your product is a big hit and you sell millions?
- What surprises await?
Alan’s general thinking here is that fundamental cloud services are fine to depend on, although it’s good to do some thinking early on about how costs will scale as you sell a lot of product. Smaller services are a fantastic way to get started and to do some testing because they are cheap and easy to tweak. But once you have enough experience to know what you want, it’s usually best to move away from these and toward building your own specialized services to maximize user experience and minimize bad surprises.
We’ve seen how many of the core IoT technologies are individually challenging, but things get even more interesting when we put them all together. Systems are, well systems, not simply collections of parts. Turning a collection of parts into an experience that users perceive as a single, seamless system is never easy, and it’s all the more difficult for IoT products because of the sheer number of separate entities that a user must interact with and depend upon.
Even a relatively simple device can become a fairly large system when we take into account all of the different parts of the ecosystem on which it depends. Turning this all into something that feels smooth from end to end, during setup and usage, and when things go wrong, is a significant challenge.