These days, we are digitally connecting anything and everything together. You can even get a toaster that pings your phone when your toast is ready! For a lot of people it is just magic that they expect to work, but how does it work and how hard is it to connect something to the Internet of Things (IoT)?

By utilizing cloud services, basic integration is surprisingly simple. To illustrate this, I’ll walk you through the architecture for a basic IoT solution with Google Cloud. For the fun of it, the example device will be a toaster!

Requirements

Let’s say that you want to build a mobile app that you can use to control your toaster and get live updates on the state of your toast (#firstworldproblems). Nothing fancy, but you want each family member to have their preferred toaster settings and to get updates when your toast job has completed.

Architecture

The following is the basic architecture we will use and a brief description of each technology involved.

Google Cloud IoT Diagram
Google Cloud IoT Diagram
  • Firestore: a schemaless document database as a service (DaaS) that allows client applications to connect to it without having to write an intermediate API. It handles validating authentication and authorization as well as streaming live updates when your data changes.
  • Cloud Functions: serverless functions as a service (FaaS) that will primarily be used to route messages between services. Thinks of it like If-This-Then-That (IFTTT) with a more flexible processing power.
  • Cloud IoT Core: a device registry that holds the latest configuration for each device and acts as a proxy for secure communication with a specific device.
  • Cloud Pub/Sub: a distributed message queue commonly used in event-driven architectures.

Solution

You can write the user interface in whatever (I should make a framework named that) but I would probably pick Flutter. We connect it to Firebase Auth for social sign-in and Firestore for the application database. When designing IoT solutions I try to keep all of the organizational pieces and user preferences at the application database layer for simplicity. The rest of the cloud usually doesn’t need to know about anything but how to manage the device. So Firestore will hold the family organization, each member’s preferred settings, and the desired configuration and last reported state for the toasters they own. The user will press a button to start a toast job and this will update the toaster document in Firestore with the user’s preferred settings.

Next, we set up a cloud trigger that will fire when the toaster document in Firestore changes. This trigger will activate a Cloud Function which will check to see if anything relevant to the device changed. If so, then it will create a message that the device will understand and serialize it with something like Protocol Buffers (protobuf). This message will then get sent to Cloud IoT Core via its API. Often I will also dump all messages sent to and from the device (config, state, and telemetry) into an append-only log (usually BigQuery) for audit/debugging purposes.

IoT core keeps a history of the configuration changes sent to each device. If the device is subscribed to IoT Core via MQTT (basically pub/sub for IoT) then it will immediately forward the message along, else, when the device comes online it will send it the latest configuration. The device may also poll IoT Core over HTTPS. All of the communication with the device is encrypted and authenticated. This can be achieved since a trusted source (usually the manufacturer) issued the device a private key and registered the corresponding public key with IoT Core.

After the device receives the configuration update, or if it just feels like reporting its state, it will publish events on the state or telemetry topics on IoT Core. State usually represents the current operational settings of the toaster while telemetry represents an event that has occurred (start toasting, done toasting, burnt toast, …) or sample readings from sensors.

The state or telemetry message is forwarded from IoT Core to Cloud Pub/Sub which queues the messages and triggers a cloud function to process them. This function will update the toaster’s document in Firestore which will send an update to the client app which will display the updated toaster state to the user who will eat the toast.

Ding! Toast is done!

Toast Done!
Toast Done!

It is pretty awesome how quickly you can get to a basic IoT solution that will scale to thousands of toasters. What is more impressive is that you can run this infrastructure with hundreds of connected devices for less than a dime a month. We have done it (but not with toasters)!

Naturally, you will inevitably come up with more complex requirements that take additional time and infrastructure, but this basic architecture is a great foundation for growth and scale. I enjoy working on IoT projects and event-driven architectures in general. It is cool to see how making changes in an app can affect the physical world through a device. So if you have an IoT project you want to build, then hit me up and I’d be happy to chat!

Tags:
  1. IoT

Erik Murphy

Erik Murphy

Erik is an agile software developer in Charlotte, NC. He enjoys working full-stack (CSS, JS, C#, SQL) as each layer presents new challenges. His experience involves a variety of applications ranging from developing brochure sites to high-performance streaming applications. He has worked in many domains including military, healthcare, finance, and energy.