Skip to content

Data Flow in West Connectivity

The basic components of an IoT system are Internet-connected hardware Products, real-time User Applications, and Integrations with external web & IT services. As a IoT developer, to get these components working together, it is helpful to understand how the data flows within West Connectivity. This guide walks through a West Connectivity data flow involving each of these basic components.

simple-diagram

There are representations of these components inside of West Connectivity. You have to set up and configure Products, Applications, and Integrations to get the full IoT system working.

simple-diagram-iotplatform

For simplicity in this guide, the physical components are replaced with a temperature sensor, a web page showing a graph, and an Email service.

simple-diagram-iotplatform

In this simplified system, a temperature sensor will communicate temperature every 10 minutes, make it so the temperature history can be viewed as a graph on a website, and automatically send an Email if the temperature exceeds 100 C.

To make that happen: * Product: Every 10 minutes, the temperature sensor wakes up, measures the temperature, and sends the value as the variable "temp" via one of the West Connectivity data APIs (e.g., the HTTP API ). * Application: Upon User load (or auto-refresh), the web page fetches the temperature history from a configured API Application that exposes a /history URL endpoint that returns the last N number of temperature values. * Integration: As soon as the system detects that the data exceeds the 100 C threshold, an Email is sent out by an Email Service to a user's phone.

external-flow

Of course, the temperature sensor's data transmissions and the web page's data requests are done at different times. This is shown in the following diagram by:

  • Blue: data flow proceeding from the temperature sensor data

  • Orange: data flow proceeding from the web page request

internal-flow

Project Configuration

A Product called "Temp Sensor" was created to authenticate temperature sensor Devices and to manage all aspects of the Devices—all device traffic uses the Product URL created when the Product is instantiated. An Application called "Dashboard" was created to authenticate Users and to respond to User-driven events on a web page—configurable API Endpoints at the Application URL are created when the Application is instantiated. The Email Service was added to send out Email. And, the TSDB Service is available to all Projects as a built-in Service. All Built-In Services are available to the Rules Engines for both the Product and the Application.

Blue Path

When the West Connectivity data API receives the "temp=101" payload, it triggers a data event for the Product to which the specific Device belongs (see Device Management for more information on Product/Device taxonomy). The Rules Engine for that Product has been set up to do some housekeeping on Product data events:

  1. Store the data in the TSDB Service.
  2. Check the "temp" value and set a warning flag in a "product status" array.

When the warning flag is set in the product status array, that message is carried internal to West Connectivity to the Application's "Product" websocket interface where Rules specific to the Application are run:

  1. Check the "product status" array for warnings.
  2. Look up the User contact information assigned as the alert recipient for an over-temperature warning.
  3. Send a Email with Subject "Over Temp!" to the alert recipient via West Connectivity's Email service.

Orange Path

The Web Page issues a GET request to the Application URL's "/history" endpoint. The "/history" endpoint was created and configured to execute Rules specific to that endpoint:

  1. Fetch the last N TSDB service temperature values.
  2. Return the values as a response to the GET request on /history.

Conclusions

Those are the basics of how West Connectivity Products, Applications, and Integrations work. Although much of the information here was simplified/pseudo-codified (Device management & authentication, using Services to accomplish more, and User/permission control were only skimmed over), these basic transactions can be scaled to many Products, many Applications, and many Integrations—all with many more Devices, Users, and Web Services represented in each area.

Up Next

To put these concepts into action, the Connectivity Quickstart is recommended to get you started on connecting your device. And the Development Quickstart on developing with your own components.