In my previous blog, I provided an introduction to a topic I wanted to understand in more detail, SAP’s HCP IoT service. This blog now goes into more detail about using SAP’s IoT service, what I managed to achieve and a conclusion of the two blogs.

1) How to enable and setup the IoT Services in HCP

This excellent blog guided me through the process of enabling the IoT functionality on HCP.

http://scn.sap.com/docs/DOC-63811

So how did I get on with this initial task?

It took me approximately ten minutes to follow these steps and to enable the service, assign the correct role and install the message management service. So far so good, perhaps a few steps that could have been automated, for example installing the Message Management Service and assigning the appropriate role when I clicked on the enable service button – (SAP a future enhancement?)

I now had an Internet of Things Service Cockpit available and a Message Management Service enabled for my sensor device to publish data to 🙂

I was still scratching my head a little about what I had enabled, but this architectural diagram provided in the IoT starter kit, helps explain the purpose of the two main parts of the IoT Services functionality: 

iot architecture.png

Diagram source: https://github.com/SAP/IoT-starterkit

Message Management Service:

After enabling the IoT functionality, I was then able to access the Message Management Service – This is a HANA Cloud Java Application, which is the central place to view existing messages sent from your sensors (e.g. temperature, rainfall or humidity), send messages back down to actuators (e.g. switching on a water pump) and view registered devices. It was also good to see a client test tool to allow a developer a method to test the two currently supported protocols that the IoT service offers:

  • HTTP/REST
  • WebSockets

The message management service:

/wp-content/uploads/2015/06/cockpit_726878.png

The Internet of Things Services Cockpit:

cockpit 2.png

3) How to set up your first digital representation of a physical device in the IoT Cockpit?

Setting up a device was very simple, there were three new terms to understand initially:

  • Device – this represents a physical object that can send or receive messages.

/wp-content/uploads/2015/06/device_726882.png

  • Device Type – this represents a group of devices sharing the same specification.

device type.png

  • Message Type – this is your JSON data model that will be sent to your device or from your device.

message type.png

In the example below I wanted to represent two different message types, a message from a sensor and a message to an actuator.

If you require more detailed steps, the document here helped guide me through the process of creating the various objects that represent the physical world scenario.

4) How to Test the IoT service:

Now that the device was setup in the IoT Services Cockpit, it was time to run some tests against the newly created HTTP Rest service and WebSocket, these tests would simulate sensor data being sent from a device. The IoT Services provide two test clients one for HTTP Rest and the other for WebSockets:

HTTP Rest:

rest client.png

rest client 2.png

Whilst I found the HTTP Client Test Tool really easy to use, I did notice some of the useful detail had been hidden, which a developer would need if they were coding the HTTP request from the device, for example, coding an HTTP request in python. The detail I found missing from this test tool were the request headers. 

Being the inquisitive techie, I wanted to see the service working from POSTMAN. With the request headers, in the example below, you can see the headers required to execute the service correctly. The Authorisation Header value is the token generated when creating the device, it is worth making a note of this, otherwise you will have to generate a new one.

Generating a new Authorisation key from the device menu:

/wp-content/uploads/2015/06/east_726890.png

WebSocket Test Client:

Alternatively you can use the WebSocket test client.

/wp-content/uploads/2015/06/websocket_726891.png

/wp-content/uploads/2015/06/websocket2_726892.png

4) Deploying the Starter Kit App:

The final piece in the jigsaw for me, was then to understand how to get at the data that was now being stored in HCP through my newly created IoT Service, thankfully a great example UI5 app has been developed and is stored on Git Hub:

https://github.com/SAP/IoT-starterkit

The app was easy to download from Git Hub and after a simple change in the main index.html and a maven build, I was easily able to create the example war file that is needed to deploy into my HCP trial account.

The only change to the starter app code was to enter the correct ids for the device, device type and message ids:

/wp-content/uploads/2015/06/javascript_726893.png

After deployment and configuring the HCP destination (as documented in the starter kit) the Java Application started up and displayed the data currently stored in HCP by the IoT Service.

/wp-content/uploads/2015/06/graph_726894.png

 

5) Potential Use Cases for your Office

While working through this demo, I suddenly became obsessed with the possibilities of using IoT in my office and here are some of the potential use cases I could see already:

  • Predictive Maintenance: We have a posh coffee machine, which frustratingly needs descaling every couple of months. Would it be possible for the coffee machine company to know intuitively when the machine needs servicing and arrange to come out and do this for us automatically?
  • Who is in the office today? Using IoT you could monitor entry and exit of your colleagues and display this information in a useful way.
  • Office Environment: It would be good to constantly monitor the office temperature, combined with understanding peoples’ personal preference to a hot or cold office, you could then analyse this data to decide on the perfect temperature for the people in your office. The same could be applied to saving electricity and heating costs around the office when unoccupied.
  • Office First Aid: monitoring colleagues for health conditions and alerting the Office first aider of a potential problem. Imagine knowing a colleague is about to have a heart attack and being able to react to the alert by calling for an ambulance.

This is just a tiny sample of ideas, there are 100’s more use cases for IoT.

Final Thoughts:

So that was my journey into getting HCP IoT services up and running. In total it took a few hours end to end and I was impressed I did not need to write a single line of code to make this all work and to produce a working set of services with a demo app to view the data. The IoT Services cockpit and test tools are really easy to use with no developer knowledge needed.

It was great to see the beta service and I am excited to see where it will go in the future. After completing this end to end demo, the question at the top of my list was how will HCP IoT Services cope with the volume of data that could be expected from sensor devices and will other IoT protocols be added such as MQTT? 

/wp-content/uploads/2015/06/future_726896.png

I hope there are plans for an Event Stream Processing capability in the cloud, perhaps combined with  “If this then do this” capability similar to what is offered at If This Then That. (https://ifttt.com/products)

Looking forward to future releases!

To report this post you need to login first.

1 Comment

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

  1. anamika Pathak

    Hi  Hardman,

    First i would like to say, its a very useful blog for initial study.

    I am done till this part to collect data from devices and show in graph and now i need to trigger sms/PNS if any sensor value goes beyond a certain point.

    could you pls help me to complete this use case.

    Thanks

    (0) 

Leave a Reply