Tutorial: Building an IoT App with Flogo and Raspberry Pi

In the last part of this series, I introduced Project Flogo as the lightweight edge computing platform to run microservices and Internet of Things applications. In this tutorial, I will walk you through the steps involved in building and deploying an IoT application from Flogo. From pulling the Docker image to running the application on a Raspberry Pi, I will cover all the aspects of using Flogo to build IoT and edge computing applications without writing a single line of code.

The application exposes a REST endpoint that can control the GPIO pins of a Raspberry Pi. Each time we invoke the endpoint, it toggles the state of the pin. The use case can be easily extended to read data from a sensor or control an actuator when a MQTT message is sent.

Prerequisites

This tutorial shows how to control Raspberry Pi’s GPIO from Flogo. We will toggle the state of the GPIO pin to switch on and switch off an LED. Make sure you have the following components at hand:

• 1 x Raspberry Pi Model B+ with default Raspbian OS
• 1 x Breadboard
• 1 x LED
• 2 x Jumper Wires
• 1 x 300 E Resistor

Connect the LED, resistor, jumper wires as shown in the below diagram. The GPIO pin 23 of Raspberry Pi is connected to the LED via a 330E resistor.

On your development machine, install Docker. We need this to run Flogo Web UI.

Designing the IoT Application from Project Flogo

Let’s start by launching the Docker image that contains the Web UI. Run the below command and wait till the console shows the message “[success] open http://localhost:3303 in your browser.”

We are now ready to access the web UI. Hitting http://localhost:3303 will show the console:

Click on New and select Microservice from the popup.

Let’s call the new service as IoTApp and the flow as Toggle.

This will create a blank canvas for us add relevant triggers and activities:

Click on the plus symbol on the left navigation bar to add a trigger. Since we are going to expose a REST endpoint, we will choose “Receive HTTP Message” as the trigger:

Click on the trigger icon to configure the REST endpoint. The service may be invoked by sending a GET request to /led/toggle path on port 8888.

In the next step, we will configure the output parameters sent by the service. To do this, click on the Input/Output button and add the parameters to the output section of the trigger. The code parameter represents the HTTP status and the message contains the output from one of the activities. Click on the Save button when done.

The trigger in itself doesn’t do much except listening for inbound messages or requests. In order to make the application meaningful, we need to add activities. One of the activities supported by project Flogo is accessing and controlling the GPIO pins. We will use it extensively to set the direction of pin. read the state, and change the state.

Let’s go ahead and add the GPIO activity to the canvas. Click on on the plus symbol within the dotted box to add an activity.

The first step in the flow is setting the GPIO pin direction to output. Since the pins can be used for both reading and writing, we need to configure it control the LED. Click on the activity to configure it with the below parameters:

Since we want to toggle the state of the GPIO pin, we need to read the current status. We can do that by adding another GPIO activity that reads the current state. If the pin is high, the output will be 1 or else it is going to be 0.

Add another GPIO activity and configure it to read the state.

It’s time for us to create a decision that toggles the status based on the current state. If the state is 1, we need to turn it into a 0.

Let’s go ahead and add a branch.

The canvas should resemble the below configuration:

We need to add a condition to the branch. Click on the branch and add the following statement as the if condition.

Here, gpio_3 is the identifier of the activity responsible for reading the state of the pin. Subsequent activities associated with the branch will be only be invoked when the condition is met. In this case, we are checking if the GPIO state is set to low or 0.

To toggle the state, we need to add another GPIO activity to the branch where we manipulate the state of the pin.

Notice that we only configured the method, pinNumber, and state parameters. Other settings are optional for this step.

We also need to end the workflow by adding a  return activity, which terminates the flow and returns the output to the trigger.

Add a return activity to the branch by clicking on the + button. Click on configure to invoke the settings popup. Set the code and message variables appropriately.  We set the code to 200 to send an OK response via the HTTP trigger.

Repeat the steps to add another branch with activities that turn off the LED. Make sure that the condition for the second branch is set to $activity[gpio_3].result==1.

Your final flow should look like the below screenshot.

This flow represents a barebone application with minimum number of activities to manipulate Raspberry GPIO pins. You may want to include additional activities such as logging which helps in debugging the flows.

Building and Deploying the App to a Raspberry Pi

With the app in place, it’s time for us to build the binary and run it on the device. Go back to the App and click on Build button. Choose Linux/arm to target Raspberry Pi.

Within a few seconds, you will find a file with .dms extension in your Downloads folder. Rename it to get rid of the extension, and copy it to Raspberry Pi. You may use SCP if your device and the development machine are on the same network.

SSH into Raspberry Pi and find the binary you just copied. Change the permissions and run the executable.

From your development machine, hit the REST endpoint with cURL. Replace rpi_IP with the actual IP address of your Raspberry Pi.

You can easily extend this scenario to build complex IoT applications through Flogo. Replacing HTTP trigger with MQTT makes it easy to integrate with existing deployments.

Project Flogo also supports invoking TensorFlow models as activities. It is possible to build predictive analytics that can find anomalies in telemetry data ingested by sensors.