IoT with Arduino Yun and YaaS

Arduino Yun IoT

The Arduino Yun hooked up to an LDR light sensor

Inspired by Georg’s post about connecting the ESP8266 to the upcoming hybris as a Service (YaaS), I thought it would be great to connect an Arduino microcontroller to the YaaS platform to showcase an Internet of Things (IoT) scenario. To keep this proof of concept (PoC) small, I decided that fetching an OAuth2 token and posting a sensor value to the YaaS Document Repository would be a good start.

The Arduino however does not have any out of the box capability to send data to the Cloud. There are many modules (or shields) which are able to connect the Arduino to the Internet, including Ethernet, WIFI or using Bluetooth Low Energy (BLE) through a gateway. Due to the Arduino computing and memory constraints, almost all of those connection options cannot levarage security layers such as HTTPS or TLS. The hybris YaaS platform though requires data to be sent using HTTPS which does not leave a lot of options for secure IoT with the Arduino.

While looking into different options I saw that we had an Arduino Yun lying around in the office and so I decided to use it for the PoC. The Arduino Yun is a hybrid microcontroller board which includes a full-blown Linux System-on-a-Chip (SoC) as well as the same AVR chip found on an Arduino Leonardo. The Arduino IDE includes a Bridge library which lets the Arduino microcontroller talk to the Linux SoC over a USART serial connection.

Instead of implementing an Ethernet and/or WIFI driver plus TCP/IP and HTTP for the limited AVR microcontroller, the Arduino team created a lightweight wrapper for the CURL command line HTTP client which is called over a serial bridge on the Linux SoC.

Unfortunately, this library currently implements HTTP and not its secure variant HTTPS nor sending POST requests. In order to make web service calls to YaaS, I had to implement my own little wrapper around CURL for fetching YaaS tokens and for sending secure POST requests to the YaaS Document Repository.

The sensor that I am using is an LDR (Light Dependent Resistor) which is connected to the Arduino’s Analog-Digital-Converter (ADC) port A0 using a voltage divider circuit. The circuit was set up on a breadboard and connected to the Arduino Yun.


YaaS client library in the Arduino IDE

I am using the Arduino String library to construct the JSON strings for the HTTPS request bodies. The Arduino Yun YaaS library I created only implements the following features: requestToken(), securePostRequest() and a super simple jsonStringLookup() to parse the token from the JSON response. Packing this functionality into 32kb of program memory and 2kb or RAM of an Arduino was a real challenge. When running out of RAM on the microcontroller, things will just stop working without any warning. The Arduino IDE only offers serial messages for debugging.


Successfully requested OAuth2 token and uploaded a sensor value to the YaaS document repository

In the process of writing the YaaS HTTPS library, I realized that doing requests by wrapping CURL requests does not provide a great level of flexibility when it comes to error handling and retries of requests. There are also some drawbacks to having a Linux SoC on the same microcontroller board: the difficulty of battery operation due to its power requirements or keeping a full-blown Linux system maintained and secure over time.

With my Arduino Yun PoC I have proven that it is possible to connect an Arduino to our new microservices based cloud platform YaaS. I learned that doing HTTPS requests on an 8-bit microcontroller is only feasible if you are using a more powerful gateway such as the Linux SoC included in the Arduino Yun. As a next step, it would be great to be able visualize the sensor data which I am pushing to the document repository. That’s a story for another blog post though.

Consuming Spark Core SSE Events via node.js

I am attending ThingsCon right now and was in a workshop with Zach Supalla, the CEO of Spark. Besides hooking up a brand new spark core to the cloud and sending Server-Sent-Events down to a Web Page, I also finally figured out how to consume these events from a regular node.js program (and not *just* a web browser…). Here’s a quick tutorial to show you how easy it is. I am assuming you have a spark core ready and connected via WiFi.



First, the spark firmware. In this case I connected a very simple PIR motion sensor – you could change that and just send a publish event every few seconds.

You can see that a ping event is sent every 30 seconds, and a motion event only if there is motion detected. Very simple, right?

Let’s move on to the node.js code. I initially used the node.js EventSource library, but this did not work. While got event notifications from the library, the events themselves were empty objects. At #thingscon today I looked closer at the Spark Command Line library and finally ripped out the essential parts for subscribing to the SSE events from that lib. The result is this small script. It mainly connects to the Spark SSE source via the request library, then whenever some data is available, it parses the data according to the SSE spec (which is pretty much line by line, plus stripping off the event: starting strings).

I we assume the node.js program is saved to sse_request.js, you should be able to run this program on the command line via

I totally want to note that the code is really ripped out of the excellent Spark CLI – which I recommend to have installed for anyone doing stuff with the spark core. It is a great little helper.

The Smart Wine Shelf – how IoT and retail come together

We’re close to present a new #hybrislabs prototype to the world, this time around IoT and Retail. Now that the technical design is pretty much nailed down, implemented and to a large degree well tested, I figured it’s the right time to write a blog post about it. We will first show this new prototype at the hybris North America Customer Days 2014 in Chicago early May.

You’ve seen me writing and presenting around IoT before and the smart wine shelf is really the project I used to explore and learn most around IoT. So what is the smart wine shelf? Well, a wine shelf (to some degree), connected to the Internet. Here’s a picture:



Why would you connect a wine shelf (aka an “element in a retail space”, hey commerce!) to the internet? Two reasons:

  • customer experience and
  • analytics

Our wine shelf improves the customer experience, as it will show you what wine fits your taste. We’ve created a mobile app which allows customers to walk through a quick wine test, then send the wine profile down to the shelf. The right selection of wine, according to your profile, lights up. Whenever to pick a bottle – either with a previously sent profile or not – you see details about the wine, it’s winery, which food it goes with. If the shelf has a profile, it will also show you why this wine fits: because it fit’s your overall style, acidity profile, etc.




And for analytics – whenever a customer lifts a bottle, either with a previously performed wine test or not, we send that data to the cloud where we analyze it. This analysis is used for two displays, as you can see in the picture. The first display is presenting the analytics dashboard of the wine shelf. It would normally not be close to the shelf ifself, we just put it there for demonstration purposes. The second display will provide details about the wine that is taken out of the wine shelf.




Making our life easier

While this is a great prototype, we needed to make our life a bit easier here and there to actually be able to create it. This is one general thing I learned during the last years and while we’ve been creating more and more prototypes. You concentrate on the main task and simplify the rest. The main task is: figuring out IoT. This means how is hardware connected in the best possible way – stable, fast and secure. We neither want to create the perfect shelf it self (e.g. space for multiple bottles each) nor the perfect “physcial selection mechanism” (we might have better placed the light rings above the wine bottles – but it needs to be portable and all components go into one platform for a bottle). Also using switches for input was mainly chosen because it provides a stable and easy input mechanism. There are other ways: ultrasonic distance sensors, pressure sensors, you name it. That’s not the point here.

Be your own customer

Being myself an absolute idiot when it comes to wine, I’d honestly believe this shelf would provide myself a lot of value (what is your experience with wine?). The real power of this can be realized when you stop thinking about the specific implementation of this prototype – the wine shelf. What if every retail space could become smart? What if you could use these to see which foods you can eat based on allergies that you have? What if the data gathered from these retail elements could be used to provide realtime information for in-store advertising?

The technical stuff

Let’s investigate a bit how the shelf was actually put together and which components have to work together. The following diagram is meant to help guide us:

Technical Wine Shelf - Firmata

  • iBeacon & smartphone app: A smartphone app is used for the wine test. The app then allows the customer to send her wine profile to a cloud API for all wine shelves. Part of that HTTP call is the id of the wine shelf, which we resolve via iBeacon proximity sensing.
  • All logic resides in the cloud and is accessed via a RESTful API: Once a profile was received and no one else currently uses the shelf to explore his wine taste, the logic (written in node.js) will match the customer profile against the wines in the database. If there are matches, it will look up the wine shelf and determine which positions in the wine shelf need to be highlighted. It will then use a ZMQ publishing queue under the topic name of the wine shelf to send the highlighting data to the shelf.
  • A Raspberry PI and an Arduino are the physcial, non-cloud elements that make the shelf smart: The Raspberry PI acts as subscriber to the cloud which publishes the selections. It was chosen mainly due to (network/internet)  stability reasons. We’ve explored Spark Core, Electric Imp and a few other options (like Espruino with a CC3000 module, Arduino with Ethernet Shield), but none was stable of fast enough to get the job done (this is changing quickly, but at the time we based a decision this was the case). The Raspberry PI’s main job is to act as a broker of data between the hardware and software world. It interfaces the Arduino, which is a well-known prototyping board. The Arduino handles the “last mile”, or “last centimeters” which is the actual control of the lights (output for selection)  and switches (input for analytics). Raspberry PI and Arduino also have to understand each other – we’ve used the so-called Firmata protocol to let them both talk to each other. It’s a blazingly fast serial protocol and allows us to connect the Arduino to the Raspberry PI via a single serial USB connection.
  • Switches and NeoPixel rings: these are very basic electronic components for the input and output of the shelf. There is almost no drama here, but I tell you that soldering 16 NeoPixel rings which each have 4 pins to solder plus the switches created a mild headache for a few days. The pic below also shows these 16 platfors, each housing a NeoPixel ring and switch for one bottle in the shelf.


Because we both send data down from the cloud to the hardware and collect data from the hardware and send it up to the cloud, our wine shelf is really an excellent example for my current valid defintion of IoT: a thing connected, able to receive and send messages from/to the cloud, able to process data and able to gather input and perform output.

You need a team for this

This is where I am really proud of #hybrislabs. A project like this requires so many diverse skills, no single person can get that done in a reasonable amount of time without going crazy. We’ve truely worked as a multidisciplinary team and many people with very different skills (mainly from software) have contributed to make that happen. Thx to Bert for the great iOS app, thx to Scott for figuring out the perfect bottles on top of the platforms, thx to Elke for designing the physical shelf, thx to Uwe for iteratively working with me on the platforms that house the switches and NeoPixel light rings and of course thx to Nick for already creating a script for a soon to be produced lab video, collecting and curating all data used (wine data, profile, matching, etc.) and discussing a lot with me about how to best build the shelf. Of course thx to Paul for many discussions and also letting us do this.

Global Making

I mentioned the hybris NA Customer Days 2014, where this will be shown for the first time. I happen to be in Munich, Germany and the event is in Chicago, USA. This means on top of all this, we’re also producing the wine shelf in the US while I will bring the platforms that house the components, cables, computers the day before the event. This is also the reason, you see so many connectors between these component platforms: It all needs to be disassembled, put into my travel bag (airport security will love me) and assembled in Chicago for the event. So a big thx to Tom in the US, too! After the event, we will build the shelf a second time for our permanent lab space in Munich. I expect the second whine shelf to take a fraction of the time needed for the first.

Like always, let’s discuss IoT in the hybris Google+ Community!