Setting the scene: A modern smart home solution

The solution you will construct over the chapters of this book is one that models a gateway device for a modern smart home solution. That means we will use the context of a smart home hub for gathering sensor data, analyzing and processing that data, and controlling local devices as functions of detected events, schedules, and user commands. We selected the smart home context as the basis of our solution throughout the book because it is simple to understand and we anticipate many of our readers have read about or personally interacted with smart home controllers. That enables us to use the context of the smart home as a trope to rapidly move through the hands-on chapters and get to the good stuff. If your goals for applying the skills learned in this book reach into other domains, such as industrial IoT, worry not; the technologies and patterns used in this book are applicable beyond the smart home context.

Now, it's time to put on your imagination hat while we dive deeper into the scenario driving our new smart home product! Imagine you are an employee of Home Base Solutions, a company that specializes in bringing new smart home devices to market. Home Base Solutions delivers best-in-class features for customers outfitting their home with smart products for the first time or for experienced customers looking for better service by replacing an older smart home system.

For the next holiday season, Home Base Solutions wants to release a new smart home hub that offers customers something they haven't seen before: a product that includes sensors for monitoring the health of their existing large appliances (such as a furnace or dishwasher) and uses ML to recommend to owners when maintenance is needed. A maintenance recommendation is served when the ML model detects an anomaly in the data from the attached appliance monitoring kit. This functionality must continue to work even when the public internet connection is down or congested, so the ML component cannot operate exclusively on a server in the cloud.

You can see an illustration of the Home Base Solutions appliance monitoring kit here:

Figure 1.8 – Whiteboard sketch of the Home Base Solutions appliance monitoring kit

Your role in the company is the IoT architect, meaning you are responsible for designing the software solution that describes the E2E, edge-to-cloud model of data acquisition, ingestion, storage, analysis, and insight. It is up to you to design how to deliver upon the company's vision to incorporate ML technologies locally in the hub product such that there is no hard dependency on any remote service for continuous operation.

Being the architect also means you are responsible for selecting tools and designing how to operate a production fleet of these devices so that the customer service and fleet operations teams can manage customer devices at scale. You are not required to be a subject-matter expert (SME) on ML—that's where your team's data scientist will step in—but you should design an architecture that is compatible with feeding data to power ML training jobs and running built models on the hub device.

After spending a few weeks researching available software technologies, tools, solution vendors, and cloud services vendors, you decide to try out the following architecture using AWS:

Figure 1.9 – Solution architecture diagram for appliance monitoring kit

It's just a little bit complicated, right? Don't worry if none of this makes sense yet. We will spend the rest of the book's chapters going into depth on these tools, introducing them at the beginner level, the patterns to use in production, and how to combine them to deliver outcomes. Each chapter will focus on one component or sub-section, and over time, we will work toward this total concept. The following is a breakdown of the individual components and their relationships:

1. Sensors and actuators controlled by the smart home hub, such as lights and their on/off switches or dimmers. These will be emulated with the Raspberry Pi Sense HAT, your own hardware modules compatible with Raspberry Pi, or via software components.
2. Home Base Solutions innovative home appliance monitoring kits. The streaming data from these kits will be implemented in this book as software components.
3. Stream buffer running on the smart home hub used to process home appliance runtime data.
4. ML models (one per home appliance) stored on the hub to invoke against incoming telemetry streamed from the home appliance monitoring kits.
5. This is all through an edge software solution running on the Home Base Solutions hub device and its components that are deployed and run by IoT Greengrass Core software.
6. Components running inside the IoT Greengrass edge solution exchange messages with the AWS cloud via MQTT messages and the AWS IoT Core service.
7. The rules engine of AWS IoT Core enables light extract-transform-load (ETL) operations and forwarding of messages throughout the cloud side of the solution.
8. Home appliance monitoring data is stored in Amazon Simple Storage Service (S3).
9. Amazon SageMaker uses appliance monitoring data as inputs for training and retraining ML models.
10. The cloud service of IoT Greengrass, using native features of IoT Device Management such as groups and jobs, deploys code and resources down to the fleet of smart home hubs.
11. Trained ML models are deployed as resources back to the edge for local inferences.
12. A local feedback mechanism, such as a light-emitting diode (LED) or speaker, signals to customers that an anomaly has been detected and that a maintenance activity is suggested.
13. A network feedback mechanism, such as a push notification to a mobile application, signals to customers that a maintenance activity is suggested and can provide further context about the anomalous event.
14. Customer support and fleet operations teams use a suite of tools such as Fleet Hub, Device Defender, and CloudWatch for monitoring the health of customer devices.

By the end of this book, you will have built this entire solution and have the skills needed to apply a similar solution to your own business needs. The patterns and overall shape of the architecture stay consistent. The implementation details of specific devices, networks, and outcomes needed are what vary from project to project.