Skip to Content

Introduction

After I introduced you to the microbrewery project in part 1, this post is all about connecting the “thing” to the SAP Cloud Platform, so sit back relax and enjoy the following lines, sláinte 😉.

 

Previous post

 

Goal / Requirements

As stated in the introduction I wanted to connect the brewery to the cloud. Yet I wanted to reduce the message overhead to a minimum in order to be able to operate in high latency environments. Additionally I wanted to follow along using a publish-subscribe pattern to avoid having to deal with security issues due to incoming connections to my local network. These requirements led me to the MQTT protocol. In case you are not familiar with the protocol I recommend you to watch the following video.

Initial state

The CraftBeerPi application does not support to communicate via. MQTT by default. Nevertheless it is possible to install the cbpi-mqtt plugin. This plugin allows connecting to an MQTT message broker and “receive sensor data and invoke actors”. Sounds great…well, read again…receive…🙁. In order to be able to send data to a message broker of my choice (SAP CP) I was in the need to develop my own MQTT client. So I accepted the challenge and hacked down the cbpi-MQTTClient plugin.

 

cbpi-MQTTClient

I’ve never had the intention to reinvent the wheel. Therefore, I chose to rely on a working basis which in turn was the Eclipse Paho client library. My idea was to create a tiny client with limited functionality such as connecting to a message broker and publishing data. So I ended up with one class that does the job. The only task left to do was to create a background task within the CraftBeerPi application which reads the sensor information and publishes them to the SAP Cloud Platform. On the CraftBeerPi side the resulting source code was as follows:

import json
import ssl
from modules import cbpi
from MQTTClient import MQTTClient

sap_iot_cfg = {                                                           # define SAP IoT Service cgf
    'device_alternate_id': 'aabbccddeeffgghhii',
    'capability_alternate_id': '0123456789101112',
    'sensorAlternateId': 'zzyyxxwwvvuutt'
}

mqttc = MQTTClient({                                                      # init MQTT client
    'id': sap_iot_cfg.get('device_alternate_id'),
    'host': 'mytennant.zone.cp.iot.sap',
    'port': 8883,
    'keepalive': 60,
    'tls_settings': {
        'ca_certs': '/some/dir/certs/ca-certificates.crt',
        'certfile': '/some/dir/certs/SAP_IoT/credentials.crt',
        'keyfile': '/some/dir/certs/SAP_IoT/credentials.key',
        'tls_version': ssl.PROTOCOL_TLSv1_2
    }
}).connect()

@cbpi.backgroundtask(key='mqtt_client', interval=2.5)                     # create bg job
def mqtt_client_background_task(api):
    sensors = cbpi.cache.get('sensors')                                   # read available sensors
    sensor = sensors.get(next(iter(sensors)))                             # get temperature sensor

    topic = 'measures/' + sap_iot_cfg.get('device_alternate_id')          # define the MQTT topic
    data = {                                                              # define the playload
        'capabilityAlternateId': sap_iot_cfg.get('capability_alternate_id'),
        'sensorAlternateId': sap_iot_cfg.get('sensorAlternateId'),
        'measures': sensor.instance.last_value
    }
    payload = json.dumps(data, ensure_ascii=False)                        # convert payload to JSON
    mqttc.publish(topic, payload)                                         # connect and publish

Don’t worry about the exact details of the source code. We’ll dive into those at a later period. As you might already suspect it is also necessary to define properties on the other side of the message processing. Therefore, we’re now going to explore the configuration on the SAP Cloud Platform end.

 

SAP Cloud Platform IoT Service

There is a ton of information on the SAP Cloud Platform IoT Service out there. Therefore, I’m trying to shorten things a bit. In the following we’re going to focus on aspects of the Cloud Foundry environment. In case the whole topic of PaaS is new to you I’d recommend you to watch the following video.

Device onboarding

Obviously if you want to communicate with your IoT device it is necessary to predefine a handful of settings. In terms of technical onboarding SAP hooks you up with the IoT Service Cockpit. Within this application you have the ability to manage your devices, sensors as well as their capabilities. In order to access the cockpit logon through your tenant account and access the Internet of Things service.

URI: https://mytennant.zone.cp.iot.sap/iot/cockpit/#/welcome

As every device can be deconstructed through its sensors and their respective capabilities, we’re going to create a digital representation based on the entities using a bottom-up approach. Depending on your preference you can choose whether you wantto set up these properties using API calls or via an GUI. In order to access the API capabilities check out the documentation provided by SAP.

URI: https://mytennant.zone.cp.iot.sap/iot/core/api/v1/doc/ 

As mentioned the device consists of sensor types and their capabilities. In detail the CraftBeerPi consists of a mash temperature in °C and the associated DS18B20 sensor and it communicates via MQTT to the SAP Cloud Platform. Within the SAP Cloud Platform all devices are connected and organized through so called gateways. These virtual gateways manage the connectivity to the devices according to the specific communication protocols. The respective entities are connected to each other via 1:N relationships. Based on this information, the following model can be derived.

 

Hierarchy model

Irrespective of whether you create the entities via API or GUI, the following results will be available at the end.

Capability

Sensor Type

Device

As part of the installation, the SAP back end generates unique identifiers to uniquely identify the entities. In order for the sensor information to be transmitted to the cloud and assigned to the digital counterpart, this information must be transmitted. A detailed overview of the required information can be found in the following documentation (step: 13 + 14). Data is the sacred good of our modern times. To transfer our data securely from the device to the cloud we use TLS version 1.2. In addition to transport security, a corresponding key is required for unambiguous identification. The corresponding certificate of the device can be generated and downloaded via the device menu through the custom properties section.

As you probably know, public-key authentication only transfers the public key for the actual authentication to the server. The certificate must be kept secret and serves to validate the public key. To generate this public key I used the OpenSSL library with the following commands.

openssl rsa -in device_certfile.pem -out credentials.key
openssl x509 -in device_certfile.pem -out credentials.crt

After defining all parameters accordingly I restarted the CraftBeerPi application and checked the results through the device menu in the data visualization section.

Final result

Roundup

In this blog episode I’ve written my own Python MQTT client, on boarded the device using the SAP Cloud Platform IoT Service and transferred data securely to the cloud backed system.

Outlook

As this blog is all about technical onboarding no business context nor semantics that enrich the details of the of device was presented. Therefore, I’m going to dive into that topic in the next post. Until then we’ve all earned a nice cold beer 😉.

*Cheers*

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply