As we established in the previous chapter, sensors/devices are a critical piece of the Internet of Things, serving as a system's "senses" by interacting with the world. Although no complete IoT solution can be built without some kind of hardware, the sensors/devices are often an underappreciated aspect of the system. Choices about the hardware affect everything downstream, from the connectivity you choose, to the analytics you’re able to provide, and to the interactions and interfaces that you enable for end-users.
There are too many sensors/devices to possibly provide an exhaustive list here. Ultimately, the choices you make on hardware stem directly from the needs the specific application your organization is interested in pursuing. So instead of exploring all the possible sensors/devices there are out there for you to use, we’ll be providing some important factors you need to consider.
One of the first considerations is whether or not the sensors/devices that you’ll be using will have power available. If you’re designing, say, a smart agriculture application with hundreds of sensors spread across broad, rural areas, you’re going to have to rely on battery. If your application takes place in a building and only involves a few devices, power may not be an issue.
The reason this is one of the first considerations is because this directly translates into how much you can do with the sensor/device. If your hardware is battery-powered, you want it to last on battery power for a long time - hopefully years (as we’ll cover in the next section, replacing and managing batteries at scale is a huge operational burden).
But to get to multi-month or multi-year battery life, the device can’t be constantly active. Power hungry operations on the device, such as using GPS or sending and receiving messages over the network, must be used judiciously.
To get a GPS fix, a device must “listen” for signals from at least 4 GPS satellites that are in orbit (here’s how GPS works). Depending on the terrain (which can block line-of-site to satellites) and the position of the satellite constellation, this can take 30 seconds, 60 seconds, or more. All of that time is time that the GPS unit is draining precious battery.
The same goes for connectivity. To receive messages over the network, the sensors/devices must be in “listening” mode, and that means battery drain. So when does your device listen? Are there situations where you need to push a critical message down to the device, such as triggering an alarm? Well that’s going to significantly impact your battery life. And if not, how often do you want the device to check in?
A “heartbeat” message is a periodic message from the device where it essentially tells you that it’s still alive and functioning. If you make its heartbeat once-per-week, you’re significantly reducing battery drain, but that also means a device might die and be offline for a week or two before you notice. If it’s every 10 minutes, that’s much closer to real-time but also 1000x the battery drain relative to the once-per-week.
All of these battery considerations also influence the kind of connectivity you choose, which we’ll cover next in the connectivity section. The point is that hardware decisions are extremely important and there are many considerations to take into account, which all stem directly from your specific use case.
However, regardless of application, having support for over-the-air (OTA) firmware updates is essential. At a high level, “firmware” is the program that’s put on the hardware of the device, basically telling it how to function and perform. As the name implies, it’s between hardware (which you can’t change once it’s been manufactured) and software (which you can update with relative ease).
While firmware can be updated (and should be), it’s a non-trivial process. Having devices that can receive updates to their firmware over-the-air (meaning that that you can update them over the network, rather than needing to have them physically in your hands) is critical, especially in applications where you have devices spread over large areas.
OTA firmware updates are a critical tool in addressing issues that may come up as you learn and refine, but they can also cause major issues. If you’re considering pushing a firmware update to all of your sensors/devices, make sure that you’ve tested extensively on a small subset that are actually out in the field. We’ve had experiences where firmware updates caused unforeseen issues and drained the batteries of hundreds of devices before new firmware update to fix it could be sent OTA.
We’ve given a few examples of important hardware considerations above, but IoT applications vary so widely in their requirements that a comprehensive exploration of all considerations isn’t within the scope of this ebook.
One of the key takeaways from our experience is that no matter how much you think through your application, inevitably you’re going to run into things you didn’t foresee. So if your application has been done before, you may be able to find hardware that has been purpose-built directly for your application, which you can and should leverage.
If you’re pursuing something new, make sure to work with an experienced hardware partner and listen closely to their expertise. Every little decision matters, and there are likely many considerations you may not have thought of.