It seems Lars lost his brain – in Future

During Oktoberfest many people lose something like an umbrella, a shoe and control. But it seems Lars lost his brain that lies on his desk with some LEDs under it.

“Lars, is this your brain?”

“No, Lars, this is not our brain, it is just some slimy gimmick, which looks like one. I’m fine, don’t worry.”IMG_0433

“And why are there LEDs under it?”

“This whole thing is a prototype for a project. First of all I’ve connected a group of three LEDs and let them fade and pulse. The next thing was to control it with my Laptop. Therefore I’m using the USB connection to the Arduino and send the CPU idle time of my Laptop as numbers. The more my computer thinks the faster the brain pulses.”

“Can you say something about the project?”

“Yes, but we can also time travel to it.”

“What? Do you think we can time travel?”

to be continued…

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.

arduino_ide_screenshot

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.

arduino_serial_screenshot

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.

IOT taking off – this is just the beginning…

It’s been a bit quite in here for the last weeks – we had to recover from the awesome hybris Customer & Partner days 2014 ­čÖé We’ve not been sitting around and doing nothing, we got in touch with a lot of stuff, mainly hardware. We’ve been preparing for 2014 and IOT is #1 on my list of trending topics. In 2013 we’ve already built several connected prototypes – “things” that were able to communicate in some sort with the internet. We even added Facebook to the game and posted the winner alongside a coupon on Facebook. All these things had commerce-driven ideas (couponing) at it’s heart. That was cool, but now we’ve gotten deeper into the microcontroller space and actively investigate IOT – the Internet of Things.

We’ve just been advising and speaking at the Mobile Tech Conference in Munich, which for the first time dedicated a full day to IOT. And even the evening was filled with IOT because we had an open house for the IOT Munich meetup, right at the conference. I am very much looking forward to the IOTCon in Berlin later in September, where I’ll be helping to organize the tracks and topics as an advisor. And I am pretty sure I have to tell the one or other story, too.

So what is the internet of things? Definitions have been changing, but this is the one that’s fitting for me right now (also see the illustration below):

A thing on the internet is connected to the cloud/internet, so it is possible to send messages down to the thing and also send data back to the cloud. Also, elements of the internet of things have their own processing power so they can react and work with the data received or create data to send back to the cloud. Things are also connected to the physical world via input (sensors) and output (visual, electrical, mechanical, etc.).

Screen Shot 2014-03-19 at 16.28.44

 

The definitions of IOT have changed a lot, from simple NFC/QR code based tagging systems to connected electronics with a steady connection to the internet. But from observing the market and the current new products coming out, it seems an IOT in which all devices are truly connected to the internet or at least some intermediary hub (smartphone, etc.) seems really feasible.

The question for hybris is: what does it mean for retail and for commerce in general? I believe the impact will be huge, as we’re able to capture a lot of currently untracked data about customer behaviour using sensors. Also, we are able to interact with the physical world and change it (via selection, lighting, sound, motors). Combined with proximity services like iBeacon, or paired with NFC some really smart customer-focused use cases become possible.

We’re working on stuff, and I’ll share more over time and once we’ve hardened a few ideas and designs.

Creating a dynamic NFC Tag with Arduino and the TI

Creating a dynamic NFC tag, e.g. a NFC Tag that looks like a static tag to an Android/Windows Smartphone but whose content (e.g. URL) can be changed dynamically, is a bit complicated if you’re not using the Android APIs and accept the “form factor” of a smartphone. There are commercial solutions available, like the DTAG100 but you pay an extra $100 for not knowing how to update an NFC chip. So figuring out how to program a dynamic NFC Tag has been a long time goal of mine. Finally, I’ve something to share.

IMG_20130902_090543

What you see above is the RF430CL330H from Texas Instruments (TI). Actually, you see the target board that includes the chip in the middle. The target board adds some electrical components such as a few resistors and capacitors here and there that are required to make the chip work correctly. Also, the target board adds a built-in NFC antenna and makes it really easy to connect wires to it. The wires shown are connected to an Arduino.

To understand how to program the NFC chip, you have to dive into a few protocols and standards. The NFC target board communiates with the Arduino via I2C, a pretty well-known communication protocol that only consumes 2 wires on an Arduino and is therefore very popular. It is all byte-based, so you read and write from registers to communicate with the NFC chip. We’ll not go into detail here, but the above link to the NFC chip would give you the register info for the NFC chip.

Next up is NDEF – NDEF is the NFC Data Exchange Format – a standard by the NFC Forum. It defines, which byte-array exactly makes up a valid NFC message – for a URL for example. It’s again bytes, lot’s of bytes. Around 40 for a smaller 10 character URL. The hard part here is the composition of the bytes. “http://” in a typical URL is for example replaced with a single byte, as it saves space and NFC tags typically cannot hold a lot of data.

Together with Ten Wong, whom I met via the TI Forums and we later communicated along on Google+, I was able to put it all together. He also wrote a library which abstracts the NFC chip. There is one pretty bad issue with the Arduino Wire library, which does the I2C Communication: it will send a stop-bit after 20 or so characters. The problem is that the NDEF message is > 40 bytes. That was causing the messages to be broken. Which files to change exactly can be seen here.

My final addition to this mix was to make the Arduino communicate via a serial connection to a PC or Mac and update the NFC chip with the URL received via Serial. The format is this:

^www.hybris.com^

I am omitting the http:// at this point and only support http:// URLs. Changing that is not very hard though.

Finally, here is the code that is required to make this all work. It is processing code, Arduino Uno and Mega compatible. It will assume the TI NFC Target board is connected as shown in the pic above to I2C and the +3.3V and GND.

The loop() method is waiting for the first ^ and will then call the updateURL method, which will read all data from Serial till another ^ is received. This method is also calculating the dynamic NdEF byte array and then finally hands it over to Ten’s library for storage on the NFD chip.

The cost of the setup is around $15 for the dynamic nfc chip on the target board, plus an Arduino. If you buy a clone, you can get one for around $10 which brings the total solution to a price point of around $25 plus shipping. Of course, this is prototyping and mass producing this probably costs a few dollars only.

Play, Collect, Redeem

This post is a follow up post to the physical endeavors we’re currently undertaking. We’re not only looking into “physical” because making is a huge trend, we also believe there are many interesting applications when it comes to in-store usage. Prototyping with electronics and other physical components gives us the required knowledge to build up prototypes around in-store ecommerce. One example is couponing. How would you use in-store couponing to drive sales to your online or offline store? How can a social profile be merged with coupons and used to gain insights or create viral coupon campaigns? What are the elements of coupons, the characteristics and how do users collect and redeem these coupons?

Our prototype explores exactly this.

The big picture – Play, Collect, Redeem

IMG_20130603_141449

The somewhat ┬á­čÖé technical architecture below shows the key components and how the are linked together for form a couponing system. Customers can play physical games, then collect coupons that they can later redeem for products (or get discounts, etc.). Let’s take a look at each component, seperated via the swimlanes in the below graphic. For the better understanding, we begin with the physical gaming frontends.

hybris Coupons (1)

Physical Frontend

The physical frontends are easy-to-play games that customers will love to interact with and try out. These games are crossover projects between gaming, art and technology. The games include a physical keyboard (via PVC foil and capacitive sensors), a push-button game and a foosball table (kicker) which we put light barriers inside to get the scores.

We designed the system in a way, that only “authenticated” frontends can be used to obtain coupons from the backend. This authentication is done via a simple shared secret (more complex scenarios possible), but the shared secret is not in the web app or otherwise saved in resources that can be accessed from the web. The shared secret is part of the Arduino hardware and trasmitted via a set of keystrokes to the web frontend. That means, only if you are in the posession of the physcial game and the Arduino prototyping board, you can obtain the access token to the coupon backend.

IMG_20130704_111802

Web Frontend

The web frontend is used to receive the game inputs from the physical games, receives the authentication key from time to time and is used to display the coupons. At a later stage, we will also use it to show the game rules to the users of the game (right now these frontends are very basic, ready to be skinned by an CSS guru!).

Via the web, or mobile web, users can also “sign-in” to a physical game frontend. The users can scan a QR code or scan a NFC tag to be redirected to a facebook login page. Once they’ve authorized our coupon application, their profiles and names appear on the web UI. Later on, these profiles will also be used to share the coupon activity to Facebook and to personalize the received coupon itself. We have all the stuff in place to help coupons generated go viral.
Coupon Backend

The coupon backend is the heart of the system and shared among all three frontends. With the required authentication token from the physcial game frontends, the web apps are able to create new coupons via AJAX calls after the users have played a game. Based on the score, a different coupon is created. Each coupon is unique and protected via a signed URL. This allows the coupon backend to trust incoming requests, as the secret for generating the URL signature is known to the backend only. If you get a coupon, tamper with the URL and try to view or redeem it, it won’t work.

The three main RESTful/JSON APIs that the coupon backend exposes are the APIs required to create coupons, view coupons and later redeem coupons. The viewing part has different representations – one is pure JSON, meant to be used for mobile clients or other systems accessing the coupon. The second is a web representation, e.g. a responsive web page which holds the coupon as a QR code. The third is an image-only representation, ready to be embedded into a HTML img tag. These three representation make it very easy to integrate coupons into any application.

As an example, we’ve already upgraded our hybris Wishlist Android application with the feature to collect coupons. As it is a native Android application, the QR code or NFC tag is scanned, which transmits the signed coupon URL to the app. The app then resolves the Coupon via the REST api and chooses the JSON representation to obtain access to all coupon data.
Mobile Frontend 

There are actually two mobile frontends: there are the shopping assistants, who scan the coupons and redeem the coupons for the users. They use a simple QR code scanner on any OS to view the coupon. They are the only ones who can mark ┬áa coupon “used” – that means the coupon’s “use count” is increased by one. Once a coupon hits the max use count figure it is no longer valid.

The other frontend, used by normal users, is either a web representation of the coupon or a mobile app, such as our Android-based coupon app. The benefit of the app is that you can collect multiple coupons, store them, revisit them and later redeem them.

 

So far so good, what’s next…

We got a lot of essential systems in place, but there would be a lot of opportunity for further research. Think about data analysis, different coupon/product combinations, geofencing wishlist items and coupons or just coupon variations (one-off coupons, product segment coupons, single product coupons, shareable/viral coupons, etc.).

We’ll also go on a roadshow to present all this. First stop will be Derry in the UK for a technology and art festival. Next up might be a swiss conference which is not yet finally approved. All these conferences and presentations will help us to interact a lot with real users, potential customers of hybris systems and also end-users. It’s a great, playful and uncomplicated way to get real and honest feedback. It all begins with a game…

IMG_20130724_130656

Physical Computing

If you’ve read Chris Anderson’s “The new industrial revolution” you’ll likely be infected with the virus of┬ámaking. So are we. Chris writes about electronics, laser cutting, 3D printing and how this could lead to a new industrial revolution. It’s about connecting the physcal world to the internet. Expanding your reach to the physical world, which – as you know – is damn big! Among our hybris colleages, we discovered many that also “play” with robots, flying drones or automatic gardening systems. What previously looked like pure play got a serious touch as many of these things can be relevant even in an commerce setting. To explore physical frontends other than “just screens” in combination with ecommerce, we’re currently working on not just one, but already a few protoypes. This blog post will be the first one of (very likely) quite a few others that explore physical computing and “making”. If all works out, we’ll be presenting and talking about our experiences at the CultureTech Conference. Till then, a lot of making and learning has to happen!

Custom PCP board

Before we delve into our first prototype in more details, let me tell you one thing that we’ve learned already: ┬áconnecting physical things to the internet, to your computer or to other systems requires a bit of learning, but it has been an extremely rewarding process. Learning how to make a box yourself via a lasercut service is simply awesome and a great skill to learn. Armed with some basic knowledge of electronics, like the Arduino board you quickly realize that pretty much everything is possible. Connecting arcade buttons to a in-store display? Easy. Create a physical keyboard as a frontend for a coupon-generating backend in the cloud? Done. Flying into space? Well…

(very) first prototype

The very first prototype we were working on is a physcial keyboard. The idea is that users have to successfully complete a music challenge to be rewarded with a digital coupon via QR code or NFC. The idea was born at hybris’ customer and partner event 2013. We disdovered how much fun we all had interacting with technology in a physical world (in this case, it was hand gestures via Kinect). We used a simple poster printing service to print a keyboard on a large piece of PVC foil. Next, we had to think how we get the keypresses as input into a computer. Arduino, the low-cost board which can be easily programmed was a natural choice. The communication to the computer was prototyped with a Node.js server running on a Mac that opens a serial connection to the arduino. At the same time, that Node.js server is creating ┬álocal websocket to be connected to a local web application (served by Node, too). This allows us to keep the UI in the browser, the logic of the game in JavaScript and use lightning fast connections via a 115200 baud fast serial connection. It took a while to connect the dots, but it does work.

malte malte_sven

Figuring out how to create the sensors was a challenge in itself. I initially prototyped a keyboard with a few pressure-sensistive resistors before Malte┬áhad the idea to use simple and cheap copper foil for capacitive sensors┬á(we ordered copper foil from eBay and finance was *not* impressed). He created our own, custom PCB board, send it to a PCB manufacturing service and finally programmed an ATMega chip you control a special capacitive sensing chip. We had to solder all these SMD (=SUPER SMALL) components onto the board, later connect the cables and fine-tune the sensing. The original goal to use the keyboard with your foot was dismissed due to too much jitter in the signals, we’ll now hang the keyboard at a wall and you’ll have to use your hands to operate it.

arduino_cables

A physical frontend, like our physical keyboard is not created overnight. It requires all kind of disciplines to be combined. A diverse set of skills hase to come together to make this happen. I went to a local stitcher and paid her for stitching the PVC foil so the sensors cannot move freely between the top and bottom layer.  Malte and me soldered and I cannot tell you how many times I sat at home and tried out circuits and early prototypes connected via breadboard to the Arduino. For the software, I had to get into Node.js programming which I did via 2 hands-on books on my Kindle. I am still a total beginner when it comes to electronics but the basic knowledge is there and all the rest can be read on the internet. The diverse combination of disciplines is awesome, as it sparks creativity (diversity is a key principle of innovation).

In the end, we figured out that there is most likely and easier way to connect the keyboard to the web application ­čÖé We’ve ordered two more keyboard foils and I am pretty confident that we’ll simplify the whole system.

stitcher

 

Now that we have┬ágained all this knowledge, we’re ready for a few more physical frontends. Likely, we’ll be creating gamification ideas using LED buttons, lasers and all kind of sensors. Stay tuned and go ask us questions. The hybris technology group on g+ is a great place to get in contact with us and discuss.

Exploring the physical world and connecting it to the internet was an awesome ride so far and the good news is that we just tapped into it!