Tell me more Internet of Things — Part 1 — IoT platform cost and value comparison

Comparison of selected IoT (Internet of Things) AEP (Application Enablement Platform) by implementing step by step a specific use-case and adding a possible DLT (Distributed Ledger Technology) implementation to that comparison.

Published in

Coinmonks

12 min readDec 28, 2018

This article (Part 1) explains the project goals. I am introducing the use/business case and how I intend to compare the cloud implementations. At the end we will set up the hardware of the use-case and deploy a simple program which prints the sensors data to the command line.

This is my personal project (multiple parts) which could stretch along month.

Motivation and targets

According to Gartner Hype Cycle the Term IoT Platform is just about on its decline from its hypest and highest rise.

Adapted Gartner Hype cycle with IoT Platform and Blockchain as of July 2018. Yin Yang symbol (describes how seemingly opposite or contrary forces may actually be complementary)

Even though Gartner is not necessarily right about every detail in technology it is certainly true that there is loads of positive business outlook from the very same research team states several trillion industry in just a few years (yes trillion 1,000,000,000,000 🐵)

True is as well that many companies have already opened their devices/businesses to the internet. And some made the collected data analyzation and data visualization centrally to their value proposition.

Whereas companies like Siemens focus in some parts more on the industrial business with their own platform MindSphere, which states to be the Operating System (OS) for the Industrial Internet of Things (IIoT). Others like Google (Google Cloud) or Amazon (AWS) added specially IoT to their vast cloud functionalities in order to advertise this market better.

All of these platforms have in common that they are offered as services. Whereas Siemens MindSphere is a Platform as a Service (PaaS) — Google and Amazon bring the Infrastructure as a Service (IaaS) included in their offerings. Meaning Siemens won’t have their own Servers (Data Centers ~ Clouds) but need to partner up with Microsoft, Amazon or Google.

The maverick approach for IoT combines two of the most hyped topics — IoT and Blockchain (better DLT Distributed Ledger Technology) and with that it would be on the highest hype on that very same curve. IOTA stands for (“A permissionless distributed ledger for a new economy”) — it’s not really the abbreviation I was expecting but it makes sense 😎. We have to be fair here, IOTA is not a platform but rather a protocol.

So adding IOTAs distributed and decentralized approach to the comparison is risky but I think worth it and opens up to a lot of questions and discussion while comparing to centrally managed platforms.

Currently IOTA transactions (messages) are secured by distributed Node software running on personal servers or cloud instances (VPS). So it is neither a IaaS nor a PaaS — it enables with providing node software, the protocol as well as a wide community to promote their vision of IoT.

All IoT solutions have in common beside other things like security, data handling and automation to solve scaling.

But why do we need all that scaling?

The control theory and system identification Professor emphasized us to always apply the most simple and easiest approach before going nuts (meaning just try linearly identify a system before training nonlinear neural networks). Translated to our use-case here that would be starting not necessarily with the BigData approach 😅. The use case (product) we will develop is at the time of writing just one device and we could implement it very easy non scale-able way. Knowing that without the other ~9.999 devices we won’t have any way of doing big data diagnostics which is the real value contribution for the business case.

In order to understand the IoT platforms benefits but as well its drawbacks we define a business case for our product (use-case) to understand how the value proposition develops with those increased functionalities.

Use-case: The product we connect to the IoT “platform”.
Business case: How to make money with this product/service connected to the cloud?
Value proposition: What is in for the customer?

The reference architecture

To structure our approaches and use the same wording we follow the reference architecture for IoT systems introduced by the Institute of Architecture of Application Systems.

Every platform has its own terms which can be mapped on this simple overview.

The use-case

Everyone needs a portable environmental sensing device which tells you at home, work or while commuting which air you are breathing and other influencing health condition you are exposed to.

The prototype

Sensors (Particulate Matter — SDS011 PM2.5 and PM10, Humidity and Temperature)
Device: Raspberry Pi 3b+
Drivers: USB connected (digital), GPIO connected (analog)
Gateway: Raspberry Pi 3b+ — WiFi module
IoT Integration Middleware: IoT Platform (Google IoT, AWS IoT MindSphere, “IOTA” not a Middleware but a protocol and distributed network)
Application: Visualization: metrics, time-series.. , notification: notify when conditions are not healthy, automation: support APIs for controlling {e.g. heating, air …}, manual event input: user can or should log when sick or other metrics, analytics: diagnostics based on big data nonlinear system identification 👍

Use case assumptions

Message-size: 20 words (columns where every word is about 5 chars)

20 words * 5 chars/words = 100 chars ~ 100 Bytes ~ 0,0001 MB

Table representation of the telemetry message (device — message)

Message-frequency: 20 messages/hour

That would lead to data ingest of roughly 18 MB / year per device

20*24*100*365 = 17,52 MB / year per device

As our product get super popular we would account

1.000 Devices ~17,52 GB / year
10.000 Devices ~175,2 GB / year.

If we don’t throw away that data (certainly not) let’s say we gain roughly 300 GB of data in 3 years (10.000 Device ramp up)

Business case assumptions

Only for the sake of staying easy (we want to compare the platforms but not the business case) we only provide the visualization and analyzation.

The device itself can be assembled by open sourced instruction or could be bought by a third parties.

Free to use application (only visualization and alarms) [0 EUR]
Licensed version which gives you health recommendation based on the data analytics (of all users devices and their personal inputs). [20 EUR / year]

*Draft of profit accumulation for our business plan (needs updating for the IoT AEP costs)*

Value proposition assumptions

We really don’t know what we are breathing during a course of the day. Certainly we don’t know individually how it affects our own health.

The value

of having an continuous environmental measurement and the possibility of logging personal health events.
getting recommendation (based on the provided big data analytics) from basic avoiding certain levels to supplement or counter measures.
personal recommendation — e.g. analyzing your next flat or house to be sure it does not affect your health.

That is a long introduction for a comparison of IoT platforms. But I guess in order to compare the solutions we need an end to end use — case. Just comparing the prices of data storage won’t do it.

The Milestones and KPIs

In order to be able to compare the platforms we introduce sections (milestones) and some indicators for comparisons.

KPIs (Key Performance Indicators)

K1: Cost of solution running continuous (€/year, €/user)
K2: Maintenance costs (€/year, €/user)
K3: Complexity of implementation (difficult=1, ok = 2, easy & short=3)
K4: Documentation quality (none=1, some=2, more=3)
K5: Out of the box functionality (few=1, some hacking=2, all is there=3)

Milestones

This is a prototype and we use javaccript where possible (Node.js) even if that is less suitable.

M0: Hardware setup (for all the same).
M1: Hardware connection (Raspberry Pi and its Sensors).

Easiest implementation with available libraries. No HW serial coding or embedded C programming (in case of MindSphere that might be necessary for the prototype 😅 node.js lib is not yet publicly available)

M2: Onboarding sensors (data).

Easiest onboarding of device. Outlook of onboarding further devices (automatic onboarding when user registers)

M3: Visualization of data.

Visualization (out of the box if available)

M4: User visualization and event handling (thresholds).

Users own device visualization and event handling (out of the box if available).

M5: User input in case of events or manual.

User input to enrich event data from the device. Easiest implementation. Outlook for mobile input.

M6: Integration of external data sources.

Adding external API available sensing data e.g. API call for the dedicated GPS coordinates and add them for data quality enriching.

M7: Analyzation of data (for correlation of air quality other factors on own health).

We won’t have big data but we provide data and check how difficult is penetration of this data (automated or manual). Machine learning for identifying correlation between sickness and various inputs.

M8: Automation (Sending commands to actuators)

Closing the feedback loop (e.g. automate the central heating actuator when events occur). Actuator control.

Possible non IoT-AEP implementation (non-sense implementation) — only for the concept

Just make the pi a server — install a LAMP (Linux Apache My-SQL PHP) on the raspberry pi and provide a static IP or do IP forwarding so you can view data via HTML.

Mhhh. that would probably work for our prototype and only one device but even there you would need to update every now and then the LAMP stack to stay secure.

You could add an API (Application Programming Interface) to your backend which allows a stronger server to collect the data from all the devices (raspberries).

Mhhh that would probably work but still a lot of manual administration of devices, when scaling your data-server needs to be scaled as well and we have not even spoken about the security to be implemented for the data exchange as well cost of maintaining the own data center…

completely out of the blue fictitious values — only for conceptual flow

The implementation has high continuous cost position like energy, procurement, invoicing, etc. for the user and the data collector. The data servers need space and cooling K1. High maintenance costs including device stack upgrades to keep device security high as well as continuous updating and upgrading servers when scaling K2. The device as well as the data collector are quite complex to set up. Activities involve creating own solutions for every necessary functionality K3. On the positive side you will find a lot of tutorials and best practices for the different functions (but don’t necessarly know whether they are still secure) K4. When it comes to out of the box services — its all you. From defining the servers HW, setting the OS and installing the complete stack to program the front end and back end K5.

Let’s start with setting up the hardware.

M0 — The hardware setup

If you are not interested in the hardware side you could directly switch to Part 2 — where we start with the IoT platform baby steps for Google IoT.

We need to get our sensor read in our device (pi). We have an analog measurement connecting directly on the analog Input / Outputs (IOs) provided by our raspberry. This measurement is continuous and we do not need to take care of any interval as the lifetime of the device is not dependent on managing the measurement cycle.

The Particulate Matter (PM) sensor is connected via USB and does have a lifetime of approximately 8000h if running continuously (60 meas./min) — it’s less than a year.

We want to query the sensor only every 3 min. for around 5s to get a valid measurement point.

Bills of material (BoM)

Prototype Product BoM:

Raspberry Pi 3b+
Micro SD card 16GB
Sensor 1: SDS011
Sensor 2: HD011

Tools for assembly of components and development

Keyboard & Mouse — for connecting to Raspberry (one time).
HDMI cable — for connecting the raspberry to a TV (one time).
Laptop — for accessing the raspberry remotely (SSH) and development.

*Material cost break down of the prototype (that is all way too expensive — i know)*

Setting up the Raspberry and connecting the sensors

Skip this if you have a running pi with node.js 8*, npm 6* and git

There are plenty of tutorials for setting up a raspberry including the sensors.

At the end the HW should look like below and you should be able to connect to the raspberry pi remotely via PuTTY (on windows) or SSH (linux) from your laptop.

*My device remotely reachable on IP 192.16.0.167 and Port: 22. The devices default user: pi and password: raspberry*

*USB connected SDS011 sensor to the Raspberry (no humidity or temperature connected)*

Once you are connected remotely to the command line (shell) of your pi we can start installing necessary software and packages for the development.

As outlined earlier we will try to us javascript (frontend and backend).

This project uses node.js version (backend javascript programming) 8 and the package manager (software packages for node) npm in version 6.

pi@raspberrypi:~ $ node -v
V8.12.0
pi@raspberrypi:~ $ npm -v
6.4.1

In order to install node on a pi I did some bash piping — meaning execute a script directly from the internet (curl location-of-script-in-the-internet | (hand-it-over) bash). Actually for security reasons it might be always better to look first into a script before executing it!

~ $ curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash 
~ $ sudo apt-get install -y nodejs

With that we should have node on the pi and the package manager npm running. In addition we use github.com for storing and pulling the different self created or adapted program code used for the different IoT Platforms.

The following command installs gits CLI (Command Line Interface) to your pi

pi@raspberrypi:~ $ sudo apt-get install git

Retrieving the signals

Our particulate matter sensor is connected to the USB port but should not be active yet. Let’s check the connection port with dmesg and find our that our sensor is connect on ttyUSB0

pi@raspberrypi:~ $ dmesg | grep ttyUSB
[544416.775421] usb 1–1.1.2: ch341-uart converter now attached to ttyUSB0

We could probably study the specification of the UART communication protocol and implement our own serial driver. https://nettigo.pl/attachments/398

But we could as well just use the work from others

https://www.npmjs.com/package/sds011-client

Before installing this package let us set up our project folder tmmiot, create a tests subfolder, create a file index.js for reading the sensor data and write them to the console.

~$ mkdir tmmiot && mkdir tmmiot/tests && cd tmmiot/tests
~/tmmiot/tests $ npm init -y

This creates a new file package.json which you could change with

pi@raspberrypi: ~/tmmiot/tests $ nano package.json

Now we can add to the package dependencies the package which provides commands for communicating with the sensors.

pi@raspberrypi: ~/tmmiot/tests $ npm i sds011-client -save

This will install all necessary files from the package to a subfolder node_modules. Our package.json file looks now like this — with the added dependencies.

{
 "name”: "tests",
 "version": "1.0.0",
 "description": "",
 "main": "index.js",
 "scripts": {
 "test": "echo \"Error: no test specified\" && exit 1"
 },
 "keywords": [],
 "author": "",
 "license": "ISC",
 "dependencies": {
 "sds011-client": "^0.0.1"
 }
}

Looking on the github page for this package we can use those simple commands to see the readings on our console. Let’s open the index.js file and code our test.

pi@raspberrypi: ~/tmmiot/tests $ nano index.js

In index.js editor paste following code.

After executing the script we see every second a new reading on the console. You could change the frequency to 1 min. for example sensor.setWorkingPeriod(1)

pi@raspberrypi: ~/tmmiot/tests $ node index.js

Output of the sensor data with 1 sec. sample rate

Troubleshoot: Your pi user need to have the rights to access the group tty

@raspberrypi:~/tmmiot/test $ groups
pi adm dialout cdrom sudo audio video plugdev games users input netdev gpio i2c spi

If this looks like this you need to add yourself the tty group

pi@raspberrypi:~/tmmiot/test $ sudo usermod -a -G tty pi

Logoff ~$ exit and the new group is added.

Congratulation you have mastered the hardware setup for the PM Sensor. The humidity and temperature sensor is just for your own exploration 😃

Adding the humidity and temperature sensor DHT22 (all installed on a development board sunfounder super kit)

Next IoT it is. Part 2

I like your comments, corrections, and suggestions 👌.

Get Best Software Deals Directly In Your Inbox