Skip to main content

Using Raspberry Pi as an IoT Gateway to Google Cloud

Adding sensors to devices and sending that sensor data to a public cloud offers many advantages; data can be stored, processed and decisions made with relatively little outlay on initial infrastructure. Having multiple sensors connected to a gateway that process and transmit data to a cloud platform is an efficient architecture to implement an IoT system.

This document describes using a Raspberry Pi v3 B+ (896-8660) as a gateway device and illustrates how we used a Pi to process and transmit data from 10 different environmental sensors.

Hardware selection

The UrsaLeo team chose the Raspberry Pi v3 as the gateway because it offers wired Ethernet, WiFi, and Bluetooth connectivity (BLE) with a reasonably powerful processor. The sensor board chosen was the Silicon Labs Thunderboard 2 (TB2), which offers a good mix of environmental sensors combined with a Gecko class processor that allows sensor data to be transmitted over Bluetooth to the Pi.

In our design, connection to the Google cloud can be done using either wired or wireless Ethernet. The overall architecture receives the sensor data over BLE, pre-processes the data, encrypts, it and then transmits it to the Google cloud over ethernet.

The sensors on the TB2 can monitor temperature, humidity, barometric pressure, magnetic field strength, gyroscopic orientation in space, CO2 and organic compound air quality, and ambient and UV light strength. There is also a microphone used to record ambient sound volume. Each of these sensors is sampled every six to eight seconds and the sensor data is then transmitted via BLE to the Pi.

Normalizing sensor values

The first step after receiving data from a sensor is to normalize the value to a standard range. For example, temperature sensors often output a value using a 16 bit ADC — so a number from 0 to 65,535 is transmitted. However, that number might represent two completely different temperature values from a 0 to 70-degree sensor compared to a -40 to 125-degree sensor. The received data point is converted to an actual temperature value (celsius or fahrenheit can be selected) on the gateway prior to transmission to the cloud.

JSON

After the data is normalised, it is put into a JavaScript Object Notation (JSON) format for transmission to the cloud. JSON is an open standard, human-readable, text-enabled way to transmit data and the most commonly used format for sending sensor data over the Internet. To keep the JSON message as short as possible, a short, unique identifier is used for each sensor in the system.  On the cloud side, the identifier is expanded into a longer device address that allows users to easily select one sensor from thousands by location, type, or other defined parameters.

Provisioning and establishing a cloud connection

Before data is sent to the cloud for the first time, it is necessary to create a Google instance that is listening for the specific gateway. This is done using a unique identifier programmed into the gateway during the manufacturing process. — After the initial login process, the identifier is entered which creates the Google data node ready to receive sensor data from that gateway.

Powering up the gateway device causes a boot sequence which establishes an Internet connection, sets the clock on the Raspberry Pi, and then sends certificate information to the Google cloud. Once a connection is established, sensor data is immediately read over the BLE connection, normalized, converted to JSON, encrypted, and then transmitted using Google IoT core (MQTT or HTTPS protocols).

Cloud activities

On the cloud side, a standard set of features is provided for displaying and processing the data. Once data is received, it is converted to an internal cloud message using a Publish/Subscribe (PUB/SUB) scheme that allows different cloud components to listen for messages from specific sources.

Dashboard

Sensor data is displayed in a customizable dashboard (below). Here both real-time and historical data can be displayed in a variety of user-defined formats selected from a library.

ursaleo_cc7b4896baa64641a3c7b446cb5992d62f6f2bc4.jpg

Event / Alerts

As data is received, it can be compared to pre-set conditions and alerts will be triggered if those conditions are met.

Note: The underlying algorithm is a pattern matching (Rete algorithm) scheme that allows for thousands of messages per second to be compared with thousands of possible events.

Events that might trigger an alert can include:

  • Data meets a trigger value (temperature is over 30 degrees)
  • Multiple data trigger points are met (temperature > x AND humidity > y)
  • Data has not been received for x period of time
  • Data has moved x standard deviations away from the long-term average
  • Data is behaving abnormally (stuck on one value or jumping around)

Many more event / alert conditions can be programmed into the cloud engine.

Further processing

Today our cloud platform stores sensor data, allows users to create a custom dashboard, set and trigger alerts on complex conditions. Future iterations of the cloud platform will further extend data analytics and actions, we plan to add object recognition using AI, machine learning, and blockchain capability, to name a few.

Summary

Raspberry Pi can be used as a gateway to send sensor data to the Google cloud. There is no maximum limit on how much data can be transmitted by multiple Ps in a single system. Cloud side services are securely transmitted and accessible through a browser interface. Use of public cloud / standard platform makes these resources available with no IT infrastructure, staff, or investment.

Next steps

You can purchase the UrsaLeo cloud-enabled Raspberry Pi based system from RS Components. RS stock number (175-0396)

 

John Burton is co-founder and CEO of UrsaLeo, an IoT Platform as a Service technology company that connects OEMs with the cloud. John has had a long career in sales and marketing for technology and manufacturing businesses for more than thirty years. He first worked with Philips, then moved to Memec were he founded and grew a company to 25 millions in revenue in Ireland over a period of five years. He then returned to the UK to run European marketing and global design services for Memec.