Get started programming the internet of things

Defining Your System

Creating a problem statement is probably the most important part of this puzzle. Let's start by drafting something that is reasonably straightforward but is enough to encompass a variety of interesting IoT challenges:

I want to understand the environment in my home, how it changes over time, and make adjustments to enhance comfort while saving money.

Seems simple enough, but this is a very broad goal. We can narrow it down by defining the key actions and objects in our problem statement. Our goal is to isolate the what, why, and how. Let's first look at the what and the why and then identify any action(s) that the design should consider as part of this process.

Click here to learn more
about Programming the
Internet of Things by Andy King.

More on Programming the Internet of Things

In an interview, author Andy King gave advice to learn more about IoT and tackle its challenges, as well as what he finds particularly interesting in the industry now.

Breaking Down the Problem

The exercises in this book will focus on building an IoT solution that can help you understand your home environment and respond appropriately. The assumption is that you'll want to know what's going on within your house (within reason) and take some sort of action if it's warranted (for example, turn on the air conditioning if the temperature is too hot).

This part of your design approach considers three key activities:

Measure: Collect data

Let's define this in terms of what can be sensed, like temperature, humidity, and so on. This is centered on the capture and transmission of telemetry (measurement data). The action -- or rather, the action category -- will be named data collection and will include the following data items (you can add more later):

• Temperature
• Relative Humidity
• Barometric Pressure
• System Performance (utilization metrics for CPU, memory, storage)

Model: Determine relevant changes from a given baseline

To decide which data is relevant and whether or not a change in value is important, we need not only to collect data but also to store and trend time-series data on the items we can sense (like temperature, humidity, etc., as indicated in the preceding definition). This is typically known as data → information conversion. I'll refer to this category as data management.

Manage: Take action

We'll establish some basic rules to determine whether we've crossed any important thresholds, which simply means we'll send a signal to something if a threshold is crossed that requires some type of action (for instance, turning a thermostat up or down). This is typically known as information → knowledge conversion. I'll refer to this category as system triggers.

In my university IoT course, I talk about Measure, Model, and Manage often. To me, they represent the core aspects of any IoT design that ultimately drive toward achieving the system's specified business objectives, or outcomes.

Defining Relevant Outcomes

Now that we know what steps we need to take, let's explore the why portion of our problem statement. We can summarize this using the following two points:

• Increase comfort: Ideally, we'd like to maintain a consistent temperature and humidity in our living environment. Things get a bit more complicated when we consider the number of rooms, how they're used, and so forth. I refer to this action category as configuration management, and it goes hand in hand with both data management and system triggers.
• Save money: This gets a bit tricky. The most obvious way to save money is to not spend it! Since we'll likely need to allocate financial resources to heat, cool, or humidify a given area, we want to optimize -- not too much (wasteful), and not too little (we could end up with frozen water pipes in the winter). Since we might have some complexity to deal with here -- including utility costs, seasonal changes, and so on, as well as anything related to configuration management -- we'll probably need some more advanced analytics to handle these concerns. I'll call this action category analytics.

You've likely noticed that each step in the what and why sections has an action category name that will help with the solution design once we move on to the how. As a reminder, these categories are data collection, data management, system triggers, configuration management, and analytics. We'll dig further into each of these as part of our implementation approach.

Although the problem statement seems rather banal on the surface, it turns out that the things you'll need to do to address the problem are actually quite common within many IoT systems. There's a need to collect data at its source, to store and analyze that data, and to take action if some indicator suggests doing so would be beneficial. Once you define your IoT architecture and start building the components that implement it -- even though it will be specific to this problem -- you'll see how it can be applied to many other problem areas.

Let's take a quick look at a simple data flow that represents this decision process; in the data flow diagram depicted in Figure 1-1, each action category is highlighted.

Most IoT systems will require at least some of the five action categories I've called out. This means we can define an architecture that maps these into a systems diagram and then start creating software components that implement part of the system.