Skip to Content
Technical Articles

Smart Coffee Machine – IoT Service Cockpit and Edge Processing

This blog is part of the blog series about our Smart Coffee Machine.

 

In the previous blog, Dries Van Vaerenbergh has explained how we connected the sensor to Raspberry PI, Installed an SAP Edge Gateway and how we send the data to the cloud. You’re probably wondering why the hell we’re installing an Edge Gateway on a Raspberry PI and why we’re not using the Cloud Gateway. This is what I’m going to explain in this blog together with the device configuration in the IoT Service Cockpit.

IoT Service Cockpit

Let me start with the IoT Service Cockpit. This is the place where you can configure all devices with sensors and the capabilities of a sensor. The capabilities of a sensor will define the structure of the message that you need to use to send data from the device. This means that Dries needs to format his message in his python script exactly like I configure the sensor with the capabilities to be compatible.

Device config

We have configured a demo Coffee Machine. This will have a sensor with a sensortype. The alternateid of the sensor is also something Dries needs for sending his message.

The Sensortype contains the capability:

The capability contains the properties like:

  • CoffeeTakenTimeStamp
    • Timestamp that the coffee has taken on the device. By default there is always a timestamp that IoT Service receives the message but it could be different from the real time that the coffee has been taken.
  • MaxFlow: The highest pressure that went through the sensor while taking the coffee
  • MaxFlowTimeStamp: the timestamp of the highest pressure. Could be interesting to know if it’s at the beginning when the water starts flowing through the senor, at the end or in the middle…
  • WaterFlowDuration: time it takes for the water flowing through the sensor
  • TotalMiliLiter: total water that has been taken for the coffee
  • CoffeeType: type of the coffee. This is something we don’t know for sure at the time that the coffee has been taken. It will be decided later based on parameters configured in the device properties by using Edge Processing. This will be explained in the next part of this blog in more detail

Again, Dries needs the alternate ID of the capability to send his data to the IoT Service

Gateways

In normal cases you would probably not even look into this part. As we are using Edge Processing, this is the place where we can see the status of the Edge Gateway.

Besides viewing the status, it also allows us to deploy interceptors!

This is the interesting part!

First of all, what is an interceptor? An interceptor enables developers to intercept data flows from the edge to the cloud. During this interception, developers are able to modify or filter the data, so you don’t have any irrelevant data in your IoT Cloud System. You can read more about Interceptors here:

https://help.sap.com/viewer/c4945853cc164aa385973d5938b385ac/Cloud/en-US/3cb5a97911864d2690583cac077a17e3.html

Second, why do we need an interceptor? We want to define the type of coffee based on the amount of water that’s flowing through the sensor. We use an interceptor to read the value total amount of water and compare it with custom properties in the device configuration. Based on this configuration, we determine the type of coffee. In case the total amount of water does not match with any type of coffee, we just ignore it and don’t send the message to the cloud. (it can happen, depending on the coffee machine, that it will use water from to time to time for other reasons then taking a coffee)

Third, what are the benefits? It allows us to add edge processing to our flow and deploy it remotely! Via the Cloud based interface, we’re able to deploy a new version of the interceptor to the Raspberry PI with the Edge gateway from anywhere we want.

 

Interceptor

As mentioned before, we use the interceptor to define the type of coffee, but how does it work technically?

Before I explain the code, I need to point out one more part of the configuration. The amount of water that’s being used for a coffee can be different on each coffee machine.  We’re (mis-)using the custom properties of the device to make this configurable and reusable for other devices.

The key contains a range which is mapped to a type of coffee. In the interceptor we’re able to access the device configuration, based on the target of the message. We also have access to the values in the message that is being send to the cloud. This means we can compare the value with all the configured ranges and determine the coffee type.

It was not possible to access the name of the different properties in the message with the Interceptor SDK, so we didn’t know the field that contained the value with the amount of water. Therefore, Dries added “101” in front of the field WaterFlowAmount so I could look for the value 101 and take the number behind it as the value of the WaterFlowAmount:

We had the same issue for determining the field for the Coffee Type. Here Dries has added “CT” as a placeholder in his python script so I could replace it with the Coffee Type.

For comparing the measured value with the ranges defined in the device configuration, I’ve used the following peace of code:

  • It will get the device properties
  • Loop over all the ranges
  • Compare the ranges with the measured value
  • Loop over the possible fields and search for the field that contains the placeholder “CT”
  • Set the value from the device custom properties in the value of the coffee type

For testing the interceptor, we need to start by running the python script from Dries that reads the sensor data and sends it to the gateway.

In the gateway log we’ll see something like this:

It will show all the logs printed by the interceptor with the determined coffee type. It will also mention when it drops values in case that the interceptor was not able to detect a coffee type.

For starting with interceptors, you can follow this blog:

https://blogs.sap.com/2018/08/20/how-to-do-edge-processing-with-iot-ae-interceptors/

Let’s recap

  • We have configured a capability, sensortype and a device with sensor
  • After that, we have developed an interceptor to determine the coffee type and only keep the relevant coffee types
  • We used the custom properties to configure the different coffee types
    • After changing the custom properties, you need to restart the Edge Gateway
  • Last but not least, we deployed the interceptor

This is how we configured our Coffee Machine and made the Coffee Type configurable with different ranges for each device!

 

Be the first to leave a comment
You must be Logged on to comment or reply to a post.