Posted by - filed under android, conferences, hybris, mobile, wearables.

My second talk last week at the Mobile Tech Conference in Munich was about Google Glass. At hybris, we’ve explored the two main ways to get content onto Glass – using the Mirror API and also native Apps using the Glass Development Kit (GDK). Of course we’ve been applying our retail-focused use cases to both of them. Have a look and comment in the G+ hybris Technology group.

Be the first to comment this post

Posted by - filed under Uncategorized.

This is a presentation I gave at the Mobile Tech Conference last week – it was very well attended, the topic seems to be getting more and more attention. From labs, we’re working on a few IoT applications in the retail and commerce space, too early to talk and write about, but the presentation is really an effort to bring to together all our findings and learnings so far. Happy to discuss in the hybris G+ Group.


Be the first to comment this post

Posted by - filed under arduino, BLE, hybris, iot.

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.

Be the first to comment this post

Posted by - filed under BLE, mobile.

We just had the hybris customer and partner days in Munich, a full week of hybris labs duty and we ended the week with an open spaces un-conference with our partners. This is also the reason why it did become a bit quiter on this blog over the last few weeks and christmas. Nevertheless, we’re back. During the open spaces conference I had the pleasure to join a iBeacons/electronics/BLE/all cool stuff conversation and among the guests was Alex Sbardella from Red Ant. He mentioned that one could build an iBeacon using a Raspberry Pi and a BLE dongle and was kind enough to follow up with the link to the original article this was mentioned in from Adafruit. I was able to install this on one of our PIs here and as I had a few minor issues which I was able to solve in the end I thought this makes an excellent blog post for the techblog. Here we go, self-made iBeacons with Raspberry PI.

For the following, I assume you have the Raspberry Pi setup with Raspbian, the default OS of the Pi. Also, you will need a BLE dongle and as Alex noted, there seem to be differences. I was ordering this BLE dongle here that works for me. One should maybe note at this point, that the total price of all components included in this setup will be higher than a single Estimote beacon. But this is for dev and the value herein is the flexibility to define the iBeacon the way you want it.

So let’s start with installing some libraries that will be required. And just to make sure, you should update the package list and upgrade the apt system, too:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install libusb-dev libdbus-1-dev libglib2.0-dev libudev-dev libical-dev libreadline-dev

Next, we create a new directory for the bluez bluetooth utility that will later be our coomand line tool for the bluetooth dongle. Download the bluez build 5.11 or feel free to explore a more recent version if you like.

sudo mkdir bluez
cd bluez/

sudo wget
sudo tar xvf bluez-5.11.tar.gz
cd bluez-5.11/

Before we can get the bluetooth dongle up and running, we need to build the software from scratch. This will take a while, so grab a cup of coffee in between:

sudo ./configure --disable-systemd
sudo make
sudo make install

At this point the bluez bluetooth software should be compiled and installed on your PI. Shut down the Pi and add the bluetooth dongle that you bought, then fire up again.

The hciconfig tool should be available, as it is part of bluez. If you just type hciconfig, you will see the basic information of the bluetooth dongle that hopefully was detected. We will now perform three steps: enable the dongle, turn on advertisements and then turn off the scanning for devices (as it can interfere with the advertising).

sudo hciconfig hciO up
sudo hciconfig hci0 leadv 3
sudo hciconfig hci0 noscan

If this all completed successfully, we are now able to overwrite the Manufacturer Specific Data (MSD) for the advertising packet that is sent out. Adadruit did a great job explaining the parts of the MSD which I will not repeat here as they’ve done an excellent job.

sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 E2 0A 39 F4 73 F5 4B C4 A1 2F 17 D1 AD 07 A9 61 00 00 00 00 C8 00

At this point, the BLE dongle should be advertising and you should be able to scan for the iBeacon. There are Apple iOS apps available to scan for beacons, but Android from 4.3 on is also able to run iBeacon scanners. I am using the iBeacon Locate app from Radius Networks – they btw also have an excellent Android library for scanning iBeacons.

The fun comes in, when you realize that you can change the MSD, meaning you can tweak the data in the advertisement packets. For example, you might want to increase the minor field, which is typically used to differentiate nodes within one location (e.g. the major field is used to differentiate the store location, the minor the location within a specific store). This can easily achieved by changing the minor version fields to this for example:

sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 E2 0A 39 F4 73 F5 4B C4 A1 2F 17 D1 AD 07 A9 61 00 00 00 01 C8 00

iBeacon Locate If you have the iBeacon scanner app open and active, you’ll see how first a new beacon joins the list and then after some seconds the old beacon that is now no longer advertised is removed. Pretty cool!

It would be great to hear your stories around iBeacon – let us know what you think in the hybris Technology Google+ group.

Be the first to comment this post

Posted by - filed under Uncategorized.

You must have heard of Bitcoin, the digital currency without any central control. Bitcoin was already a big and exciting topic 1-2 years ago in the tech/nerd community and recently went mainstream in the media: from CNN to even German conservative Handelsblatt. Some see bitcoin as a hype, some purely as an investment option (like Gold, Silver, etc.) and some have high hopes in it to become the first global and friction-less payment system. For the sake of global ecommerce, I am hoping that it will not just be a good investment, but also a payment system – one that finally really works well for websites, mobile and at the POS.

I’ll outline a few features of bitcoin over the next paragraph until I’ll take a more technical twist to this and will show you how you can run your own transation-free (almost) payment system using Bitcoin.

First of all, Bitcoin exists since 2008 and was born out of a paper written by Satoshi Nakamoto. This is not a real person, it might be a single or a group of developers. Nobody knows them, which many consider a good thing because there is nobody to hold accountable for. In the recent years the Bitcoin Foundation took over the source code of the Bitcoin software (via GitHub) and continuously improves it.

So what are the characteristics of bitcoin:

  • Instant P2P transactions: ther is no middle man. No bank. People can send money from one account to any other bitcoin adddress. These addresses typically are presented as QR code or encoded onto an NFC tag and include a checksum – so it is hard to get it wrong.
  • Little transaction feeds: Credit card companies charge 2%, with bitcoin you pay a fraction. The fraction paid is a reward to all P2P nodes confirming the transaction. The more nodes confirmed the transaction the more unlikely it is the transaction does not go through. Typically 1-2 nodes that confirmed a transaction are enough for smaller payments. Larger payments can wait a longer time or increase the transaction fee to speek up the process.
  • Bitcoin is the first global currency. The same everywhere. Travellers love it.
  • Low risk of inflation: there is a total amount of 21 million bitcoins – ever. This surely has caused speculators to invest and is both a good and bad thing.
  • Bitcoin can be used anonymously: I think this is by far overrated as most people today have bought bitcoin through an exchange and have gone through ID processes. There are of course ways to send the money on to anomynous addresses, but it should be pretty tough for most people to figure a perfect system out.
  • It i super easy to get started: It depends how you want to use bitcoin, but in the most simple case you open an online account to accept and buy bitcoins or you download a free app (e.g. on Android) and are instantly ready to receive bitcoin. To get some, you’ll need a marketplace like or to know someone who has some.

But speaking of ecommerce, why is this so exciting for shop owners – both online and offline:

  • Low transaction fees: even if you use a payment provider, e.g. BitPay, the transaction fees are radically lower than the 2% of a credit card company.
  • No reverse transactions: a transaction cannot be reversed. This one is big – retailers can still refund a returned item, but it is again a forward/new transaction. There is no way to cause troubles for retailers by calling the credit card companies and denying a 120 days old transactionPayment providers like BitPay take off the risk of converting Bitcoin into a local currency and depositing the amount into your bank account. You pay a fee for that. If you are more radical, you can explore to setup your own bitcoin server, using the openly available software.

I recently just did that:

Once you have the software running – use the GitHub link to get and compile it – you start the bitcoind process. It will quietly download the blockchain for a day or so and then you can use the system.

To get your default account address that was generated, type this:

bitcoind getaccountaddress ""
> 1JDa7ht2DgL1ai42hGTWRTkR3iM7XRyBeY

You should setup a new address (you can generate as many as you want) for each order. Very simple:

bitcoind getnewaddress ""

Now transfer some money from another bitcoin wallet. Wait until the blockchain is updated:

bitcoind getreceivedbyaddress 1DFCV6SkfehpYUstsjneU8yr41Epe6j9iq
> 0.00010000

You can also check how many nodes have confirmed the transaction by adding another parameter stating the amount of nodes known to have confirmed the transaction. In the end, you can very easily transfer the balance to another wallet and from there on cash it out or convert to local currency.

Besides the command-line interface, bitcoind has a JSON-RPC style interface that is simple to use. I explored this using a small Groovy-based utility already and will post about it if you like (let me know).

If you don’t want to run your own bitcoin server you have the choice to use a bitcoin payment provider. Another smart choice might be to use something in between – e.g. offers nice callback options for your integration. Once funds are received, a callback informs your server about the received payment. You can then mark the order in question paid and continue the order fulfilment process.

We’ll have more news and discussion around bitcoin soon – for now I have to catch my flight from Beijing back to Germany. Just coincidentally, China is having most Bitcoin transactions globally and the largest marketplace. – the Chinese search giant is now accepting Bitcoin, too!

Be the first to comment this post

Posted by - filed under android, BLE, mobile.

We’ve been exploring and implementing geofencing features in our Android prototypes even before Google added geofencing support to the Android OS (official Geofencing was added via the Play Services Add-On soon after Google I/O in May ’13). One example that we showcase on conferences is the hybris Wishlist & Wallet App. We now explore Bluetooth Beacons to move to the next level of geofencing. While the geofencing we’ve explored so far was using the wifi and cell phone networks to trigger geofences based on a relatively low accuracy (e.g. 50-250 meters), we now are excited about BLE Beacons. BLE (Bluetooth Low Energy) Beacons allow us to locate a device the customer is carrying up to a few meters.


Above you can see a recent prototype that we’ll soon be integrating with our other apps. A background service scans for BLE devices, filters them down to the ones we want to use for geofencing and determines the closest one. Using the BLE Beacons, we can now sense the location up to a few meters, which opens up totally new use cases for retailers. While it would be possible to provide an approximate distance in meters, we’ve created three ranges for proximity: VERY_CLOSE, CLOSE and IN_RANGE. This should be ideal for typical ecommerce in-store use cases.

The BLE devices that we have used to explore this are the TI SensorTags. These cool-looking BLE devices are have something like 6 sensors from pressure, accelerometer to humidity built in. All we really use them for is to sense the devices, filter based on the BLE names and then determine the distance. It is not a perfect solution as these devices turn off the BLE advertisements after 30 seconds, but it was enough to get started with micro geofencing and BLE.


We expect BLE beacons to become available very soon and for a very small price. Estimote is already offereing a BLE Beacon developer pack (3 Beacons, $99) for example and we expect the prices to drop sharply once the final products are on sale.

Let us know what you think – either in the Google Tech Group or via direct comments.

Be the first to comment this post

Posted by and - filed under 3D, WebGL.

You might have heard of the The Leap Motion Controller, which is a tiny and cheap device to enable gesture-based input to a PC or Mac. While Leap calls itself a “gesture-based” controller, it is even better. You can get detailed x/y/z coordinates of the hands, fingers and pointables that the device detects. The SDKs that Leap offers already convert this into some key gestures like the swipe and circle gestures, but you are free to work directly with the underlying x/y/z coordinates if you want.

Another piece in the technology puzzle that recently became very popular is WebGL – a 3D rendering context for web browsers. All modern browsers but the current version of IE10 support it (see at “CanIUse”). Luckily IE11 is planned to have support which makes WebGL the universally supported 3D context in the desktop web world. Unfortunately, WebGL is a pretty complex, you have to work with 3D vertices and shaders which is pretty tough. The good news is, that Three.js, an open source JavaScript library, hides much of this complexity.

Bringing the two things together is what we currently find pretty interesting. With the Leap, you get an affordable 3D input device that offers a JavaScript API. With WebGL and three.js, you get a pretty easy to use 3D rendering API. Both together close the loop and 3D/ gesture controlled web apps become possible. We are at an very early stage, where we explore how you could for example select or even manage products using a 3D, gesture-controlled UI. The screenshot below shows how we added a few product boxes to the 3D scene in a circular, wheel-like geometry. Using the Leap Motion Controller and our integration between Leap Motion and the three.js libraries, you can now zoom in and out, rotate the wheel or change the camera y position, the vertical axis of the camera.

Screen Shot 2013-10-15 at 10.10.30 AM

I’ve also captured a video which shows our current explorations.

At this point, we’re looking for feedback and ideas. What could you imagine when it comes to product catalog management or other parts of a commerce system? Would you say there is room for customer-facing ideas that involve the Leap Motion Controller? Please let us know – either via comments on the blog post or via our hybris Google+ Community.

Be the first to comment this post

Posted by - filed under arduino, nfc, physical.

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.


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:


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.

/* Copyright 2013 Ten Wong,
   and 2013 Sven haiges, for the serial
   communication and the dynamic NDEF message assemply. 
*  RF430CL330H datasheet reference

** sample: when reset the rf430, it will write the uri to 
** rf430 tag.
#if ARDUINO >= 100
 #include "Arduino.h"
 #include "WProgram.h"

#define IRQ   (3)
#define RESET (4)  
int led = 13;
RF430CL330H_Shield nfc(IRQ, RESET);

volatile byte into_fired = 0;
uint16_t flags = 0;

byte NDEF_BASE[] = {    \
    /*NDEF Tag Application */    \
    0xD2, 0x76, 0x00, 0x00, 0x85, 0x01, 0x01,         \
    0xE1, 0x03,     /*Capability Container ID*/     \
    /* CC file start */    \
    0x00, 0x0F,     /* CCLEN 15bytes fix*/    \
    0x20,     /* Mapping version 2.0 */    \
    0x00, 0x3B,     /* MLe (49 bytes); Maximum R-APDU data size */    \
    0x00, 0x34,     /* MLc (52 bytes); Maximum C-APDU data size */    \
    0x04,     /* Tag, File Control TLV (4 = NDEF file) */    \
    0x06,     /* Length, File Control TLV (6 = 6 bytes of data for this tag) */    \
    0xE1, 0x04,     /* Type4 Tag File Identifier */    \
    0x0B, 0xDF,     /* Max NDEF size (3037 bytes of RF430CL330 useable memory) */    \
    0x00,     /* NDEF file read access condition, read access without any security */    \
    0x00,     /* NDEF file write access condition; write access without any security */    \
    /* CC file end */    \
    0xE1, 0x04,     /* NDEF File ID */     \
    0x00, 0x0F,    /* NDEF Length 15bytes */    \
    /* NDEF start */    \
    0xD1,    /* NDEF Header MB=1, ME=1, CF=0, SR=1, IL=0, TNF=1 */    \
    0x01,    /* Type Length 1 byte */    \
    0x0B,    /* Payload length 11bytes */    \
    0x55,    /* Type U (URI) */    \
    /* Payload start */    \
    0x01     /* URI Record Type : http://www.  */    \

void setup(void) 
    while (!Serial); 
    pinMode(led, OUTPUT); 
    digitalWrite(led, HIGH);
    //reset RF430


void loop(void) 
  while (Serial.available())
    byte cmd =;
    if (cmd == 94) //^

void updateURL()
  Serial.println("Reading URL until ^...");
  byte buffer[255]; 
  byte pos = 0;
  byte urlByte = -1;
  while (urlByte != 94) //while not ^
    if (Serial.available())
      urlByte =;
       if (urlByte != 94)
         buffer[pos++] = urlByte;    
  Serial.println("Received second ^. Creating new byte array with this size:");
  Serial.println(pos, DEC);
  byte urlPart[pos]; //we expect (no http://)
   //copy to final part array
   for (int i = 0; i < pos; i++)
     Serial.println(buffer[i], HEX);
     urlPart[i] = buffer[i];
   byte BASE_SIZE = sizeof(NDEF_BASE);
   byte ndef[pos+BASE_SIZE];
   byte ndefPos = 0;
   for (int i = 0; i < BASE_SIZE; i++)
     ndef[i] = NDEF_BASE[i];
   //add url part
   byte partPos = 0;
   for (int i = BASE_SIZE; i < (pos+BASE_SIZE); i++)
     ndef[i] = urlPart[partPos++];
   //fix the length fields
   ndef[27] = 5+pos;
   ndef[30] = 1+pos;
   //update nfc tag

    while(!(nfc.Read_Register(STATUS_REG) & READY)); //wait until READY bit has been set
    Serial.print("Firmware Version:"); Serial.println(nfc.Read_Register(VERSION_REG), HEX);    

    //write NDEF memory with Capability Container + NDEF message
    nfc.Write_Continuous(0, ndef, sizeof(ndef));

    //Enable interrupts for End of Read and End of Write

    //Configure INTO pin for active low and enable RF

    //enable interrupt 1
    attachInterrupt(1, RF430_Interrupt, FALLING);
    Serial.println("Wait for read or write...");
            //clear control reg to disable RF
            nfc.Write_Register(CONTROL_REG, INT_ENABLE + INTO_DRIVE); 
            //read the flag register to check if a read or write occurred
            flags = nfc.Read_Register(INT_FLAG_REG); 
            Serial.print("INT_FLAG_REG = 0x");Serial.println(flags, HEX);
            //ACK the flags to clear
            nfc.Write_Register(INT_FLAG_REG, EOW_INT_FLAG + EOR_INT_FLAG); 
            if(flags & EOW_INT_FLAG)      //check if the tag was written
                Serial.println("The tag was written!");
                digitalWrite(led, HIGH);
            else if(flags & EOR_INT_FLAG) //check if the tag was read
                Serial.println("The tag was read!");
                digitalWrite(led, LOW);
            flags = 0;
            into_fired = 0; //we have serviced INT1

            //Enable interrupts for End of Read and End of Write
            nfc.Write_Register(INT_ENABLE_REG, EOW_INT_ENABLE + EOR_INT_ENABLE);

            //Configure INTO pin for active low and re-enable RF
            nfc.Write_Register(CONTROL_REG, INT_ENABLE + INTO_DRIVE + RF_ENABLE);

            //re-enable INTO
            attachInterrupt(1, RF430_Interrupt, FALLING);


**  @brief  interrupt service
void RF430_Interrupt()            
    into_fired = 1;
    detachInterrupt(1);//cancel interrupt

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.

Be the first to comment this post

Posted by - filed under android, conferences, responsive.

While our travel planning for the hybris Labs Roadhow (I guess one can call it like that) is underway, we’ll next be at the MobileTechCon in Berlin. To be exact, this is only me – Sven – and I’ll be in Berlin for September 3rd and 4th. At MobileTechCon I’ll be giving two interesting talks about the new location features for Android (Activity Recognition, Geofencing) and also about client-side, responsive Web applications. We’ve had experience with both technologies and it is about time to share some of this experience with the broader community. So if some of you are interested in meeting in Berlin, just contact me via Google+. Hope to see you there!

Be the first to comment this post