Third-Party Sensor Data in DT Cloud

Introduction

When using Disruptive Technologies sensors, your data is continuously captured and forwarded by a Cloud Connector to the DT Cloud where it is stored for 31 days. While our current range of devices already covers many use cases, some sensor types, like barometric pressure, are yet not in our repertoire. However, while we continue to expand our offerings, a method of including third-party sensor data into our cloud does exist.

In this application note, we will take a look at how a Raspberry Pi can be used to sample barometric pressure data from a Mikroe Environment Click breakout board, then periodically publish events to the DT Cloud using our Python Emulator API. This lets the third-party pressure data propagate our cloud just like any first-party sensor, allowing you to effortlessly expand your integrations.

Prerequisites

• Development Platform A Raspberry Pi or any other development board that can connect to our REST API. It is assumed that you are at least familiar with your platform of choice.
• Third-Party Sensor An Environment Click or any other third-party sensor that can be sampled by your platform.
• Service Account Creating, deleting, and interacting with emulated devices require that your User or Service Account has been granted the role of Project Developer or higher.

DT Studio Configuration

Only minimal DT Studio setup is required to recreate the steps in this application note.

1. Navigate to the DT Studio project into which to forward your third-party sensor data.

2. Make sure you have a Service Account with a role of Project Developer or higher that is granted membership in the project.

3. For each third-party sensor data stream, you wish to forward, Create An Emulated Sensor. We will use the Temperature Sensor type as a proxy to our data, even though we sample pressure data.
4. Take note of both the sensor- and project IDs as these will be used for publishing the events.

Implementation

This application note uses a Raspberry Pi with an Environment Click breakout board, but the implementation would be the same for any other platform. However, the GPIO pins and Python environment makes the Pi a good choice for quick and easy prototyping.

Raspberry Pi 3 Model A+

It is assumed that your Pi is set up with the latest version of Raspberry Pi OS and has a working internet connection. If you're unfamiliar with this process, you should read the official introductory guide.

Enabling I2C

We'll be using the I2C communication protocol to exchange information between the Pi and Environment Click breakout board. By default, this is disabled on the Pi, but can be enabled through the shell.

• sudo raspi-config -> Interface Options > I2C > Enable

Python Environment

We'll use the Disruptive Python API to publish emulated sensor events with only a few lines of code. Therefore, a working Python 3 environment must be configured.

1. Install Python 3.7 or greater, either through the use of Pyenv or the official repository with sudo apt install python3 python3-pip.
2. Install the Disruptive Python API package with pip3 install disruptive.

3. Additionally, install any device driver packages to interact with your sensor. For our Environment Click board which hosts the Bosch bme680 sensor, Adafruit has a readily available package we can use pip3 install adafruit-circuitpython-bme680.

Mikroe Environment Click

The Environment Click requires no configuration other than connecting it to the Pi.

• As we're using I2C, connect the SDA and SCL pins between both devices.

• Power the breakout board using the Pi 3V3 and GND pins.

Sample and Publish Events

Once you have a working Python 3 environment and the breakout board is connected, the sensor can be sampled by the Pi, then published as an event to the DT Cloud. The following snippet does exactly this.

1. Authenticate the Disruptive Python API package using your Service Account credentials.
2. Initialize an instance of the bme680 sensor which the Pi will sample every 1 second.

3. For each new pressure sample, append a buffer list for storage between publishing events.

4. Once every 60 seconds, publish the median pressure value to an emulated device.

Remember to replace variables on the form <VARIABLE> with your own details.

import time
import statistics

import adafruit_bme680
import board
import disruptive as dt

# Publishing-related constants.
PUBLISH_INTERVAL = 60  # seconds
PROJECT_ID = '<YOUR_PROJECT_ID>'
DEVICE_ID = '<YOUR_EMULATED_DEVICE_ID>'

# Authenticate the disruptive package.
dt.default_auth = dt.Auth.service_account(
    key_id='YOUR_SERVICE_ACCOUNT_KEY_ID>',
    secret='YOUR_SERVICE_ACCOUNT_SECRET>',
    email='<YOUR_SERVICE_ACCOUNT_EMAIL>',
)

# Create sensor object, communicating over the board's default I2C bus.
i2c = board.I2C()
bme680 = adafruit_bme680.Adafruit_BME680_I2C(i2c)

# Set sea-level barometric pressure to match your location.
bme680.sea_level_pressure = 1006  # hPa

# Initialize a buffer list to hold values between publishing.
pressures = []

# Start a timer for tracking publishing interval.
t0 = time.time()

# Suspend in an infinite loop, exiting at KeyboardInterrupt.
try:
    while True:
        # Read and append barometric pressure reading from bme680.
        pressures.append(bme680.pressure)

        # Print new pressure value to stdout.
        print(f'Pressure: {pressures[-1]:.2f}')

        # Check timer interval.
        if time.time() - t0 > PUBLISH_INTERVAL:
            # Have pressure be the median buffer value.
            pressure = statistics.median(pressures)

            # Publish a new event for the emulated device.
            dt.Emulator.publish_event(
                device_id=DEVICE_ID,
                project_id=PROJECT_ID,
                data=dt.events.Temperature(pressure),
            )

            # Reset timer, clear list, and tell stdout what you did.
            t0 = time.time()
            pressures = []
            print(f'Published event with value {pressure:.2f}.')

        # Sleep for a second.
        time.sleep(1)

except KeyboardInterrupt:
    pass

You probably notice that we use the temperature event to publish our data. This is because a pressure event type does not exist, and since the data type is simply a floating-point number, it does not matter.

Viewing Your Data in DT Studio

Once your script is running on your Raspberry Pi, head over to DT Studio. Here you should see the sensor data updating at each publishing interval. Using the Dashboard, a card can be created to inspect how your data behaves over time.

Again, our cloud thinks the data is from a temperature sensor, but this is only a visual side-effect. If you choose to interact with- or forward the data it is, of course, unaffected.

Next Steps

Now that your third-party sensor data is in our cloud, all services that are available to our first-party devices can be utilized. Here are a few examples of what you can do with your data.

• Examples of how to integrate with various cloud services
• Building a real-time heatmap
• Outlier detection on multiple data streams