API Days

The university campus  of Paris has been the host of  the 2018 edition of the API Days in Paris. The event gathered some big names of the IT and telecom, as well as some smaller players. A non exhaustive list includes:

  • Red Hat
  • IBM
  • Orange
  • Kong
  • Parasoft

With today’s diversity of hardware and software products and services, the lack of standardization is  one of the bigger issues faced by customers. The good news is that  some companies can solve this problem. Yes, this is about APIs (Application Programming Interfaces). In other words, it is about standardized use of products and services.

A company with a deep enterprise-oriented culture, IBM provides a uniform API for virtually everything. While I am not sure how fast a 3 people team dedicated to the task can cope with ever changing systems as well as with new entrants, there is a high degree of confidence from Big Blue. I suspect there is more than the person I spoke with told me. Maybe it is Watson or something similar. One thing seemed sure: IBM can connect you in a standard way with virtually any database (both SQL and NoSQL). What I liked most was the official position regarding data protection. Without express demand from the customer, IBM stores no data. With the GDPR coming into effect next May, IBM may have positioned as a trusty partner and provider.

A telco with a long history, Orange has a strong position in the IoT market, for both industrial and home market. While the information is still scarce for the end-user,  with no demo portal, the offer has improved significantly. I mean, you need to contact Orange  and/or even pay  first  before seing the IoT portal in action.  From what I saw, the offer includes data communication, specific IoT hardware selling and API provinding. This is a wise move from a company which used to sell only data plans. The strongest part is about API. You can buy non standard IoT hardware from a Chinese company, use data plans from some telco and have Orange translate that non standard information into a conventional API.   Unlike IBM, there was no clear position regarding customer’s data. The meta API could keep intermediary data in caches. however, the user can choose to delete the data.

A less known company, Kong is aggregating APIs from micro services ( REST, Swagger, etc.) into an uniform interface. The solution is platform agnostic and integrates transparently at many levels.

One of the Linux veterans, RedHat has a long history of providing premium services to companies. For example, the company helped Amadeus during its own journey toward the cloud. RedHat is less about API and more about helping reach a specific goal.

Offering an API is good, making it secure is better. Parasoft plays in a different league and it has earned points in the field of software testing. The offer is quite big and covers a good number of languags and and standards.

I tried to write quickly about the event. There were many more companies present and introducing them all would take a much longer article. However, one thing is sure: API standardization is key to the future of IT.  With the advent of IoT, robotics and AI/Machine Learnng, I expect even more players to enter the arena of the API.



IoT powered over the air

According to UWINLOC, a French, Toulouse-based company, it is possible to install battery-less beacons that capture energy from a radio field. At the core of this technology lays a basic principle: very small devices require extremely low power.

The beacons harvest radio energy through miniaturized antennae. Once the internal energy storage system goes beyond a specific level dubbed as “charged”, the devices start to emit a “ping”. It is this ping that enables the location in a 3D space.  Several carefully-placed receivers locate the position of the beacon.

The small devices are packaged as tags that can be attached to any object. I see great potential in such a technology. It is a bit scary, but it might open the door to free energy. All it takes is to balance the power requirements of a device with its capacity of harvesting energy from the electromagnetic/radio field.


Build an simple Arduino-based wait time display for the bus stop

The real case

The styled bus stops J.C.Decaux has put in Paris have displays that indicate how many minutes one has to wait for the next bus. I like the simple matrix display put atop a 5m pole. The size of the LED matrix and their brightness allow a good read from more than 10m for the average person.


Unfortunately, there is only one matrix and as such, it is visible only from one side. While it is good for a MVP, the design has a big flaw: people coming from the opposite direction cannot see the information. The worst case is when someone sits across the street.  The bus could come from around the corner and go in just one minute. So much for the wait time display.


The idea of having a small matrix placed high enough to avoid destruction of property is quite good. The only bad thing is that I need to be near the bus stop in order to get the information. And this suggested the following project: a matrix display placed on my door, so I can see how minutes I have before the next bus arrives.

The schematics


The circuit uses two components:

  1. a WeMos D1 R2 board with the the excellent ESP8266 chip
  2. a 8×8 LED display driven by the MAX7219 chip

And now to the project

The display

The MAX7219 and the 8×8 LED display have a bright red color, easy to spot from a few meters away. Put on the front door (on the inside, of course), it is visible from a few meters away.

The excellent Arduino LedControl library is easy to use. It has only one drawback: no support for displaying figures, especially two figures, as the waiting time can go up to 60 minutes. Most of the existing stuff on the internet does not accommodate so much information in such a small space.


That is no problem. One piece of paper, a pencil and time. Not much. Ten minutes later, the display problem is solved.  The design of the font for the figures is simple, yet sufficient. Enough to show one or two digits.


And just in case, I’ve  added several text messages, like Err for error and WF for WiFi.


Updating the wait time display

A waiting time display must update itself on a regular basis. The precision is down to minutes, so it feels right to refresh it every minute.  There is no secret recipe:  one needs a network connection.

While today we have many IoT options like LoRA, ZigBee, SigFox and the likes of them, for sake of simplicity, I used a regular WiFi connection. Thus the presence of the WeMos D1 board, featuring an ESP8266 WiFi enabled chip. It is a low-cost solution to the problem.

The wait time provider

For this project, I use the excellent API from Pierre Grimaud. It is easy to use. The only caveat is the necessity to connect in https instead of http, which is not the default role  of ESP8266. Fortunately, there are alternatives.  The whole project is on GitHub. Feel free to use it and don’t judge too harsh the quality of the code. I did it in a rush. Don’t forget to replace the placeholder values with real stuff.

Flashing the ESP8266

I used the Arduino editor. It is the best thing to use when playing with Arduino devices.

A word of caution

The LED display draws a certain amount of current. The USB port of the computer has its limits. During the flash, I disconnected the LED matrix from the board. Maybe this step it is not necessary, but better safe than sorry.

One more thing

Be careful, the real LED matrix has a slightly different order for the pins than the image above. The order is the following: Vcc,GND,DIN,CS,CLK. Make sure you connect pin D6 to CLK, respectively pin D5 to CS.


Combining a proximity sensor with a RGB LED


The sensor and the RGB LED

The basic idea

Let’s say you want to have a device which can tell you in a simple way if something is dangerous. In the present case, let’s assume there is a very hot stove and you must avoid at all costs to touch it.  There are many ways to do it. In my case, as I am playing with  Arduino, the best way to see the shields and other components in action is to combine them in a useful way. The current project uses a proximity sensor, made by Sharp, a  common anode RGB LED and of course the classical Arduino board plus the breadboard.


The proximity sensor with the color-coded connectors

The sensor

The proximity sensor is 0A41SK (or GP2Y0A41SK0F). It comes with a connector which is color coded:

  • red –> 5Vcc
  • black –> GND
  • yellow — Analog pin 0

RGB LED in common anode configuration


The LED is not very hard to use, but mine didn’t lit and I learned about the two possible RGB LED configurations:

  • common anode
  • common cathode

In case you assume the first type and the LED doesn’t blink at all, you must conclude it is the opposite type. Such was my case. I was afraid the LED was broken, but  it functioned normally.


1K resistor


The resistors

I used three 1K resistors.  Surprisingly, while people over the internet say that the LED is poorly lit when combined with 1K resistors, in my was it was very bright. Maybe the common anode configuration is favoring this type of LED.

The schematics

The only particular aspect of the circuit was the use of the 5Vcc pin instead of the GND  for the RGB led. This requires an inversion of the values on the pins D5, D6, D7, but more of it later. As it can be seen in the picture, there are two distinct circuits that can be tested independently. In fact I used the half-circuits  before putting everything together.

The configuration of the LED

Due to the peculiarities of the LED, it is lit when there is a voltage between the 5Vcc pin and the pins D5, D6, D7. In other words, the three individual diodes that make up the LED are lit when the three pins are set on LOW. Similarly, the LED is unlit when the pins are set on HIGH.

The configuration of the sensor

The proximity sensor is connected to the A0 analog pin. AS I am using a WeMos card, it is the only analog pin and I am glad it is available on the board.

Playing with the values

The ADC converter returns a value between 0 and 1023, corresponding to a voltage between 0 and  5Vcc.  I used a mathematical formula in order to calculate the voltage. Now, there are many libraries that ca be used, but as I didn’t like the distanced produced, I preferred to do the job myself, so I wrote my own distance calculation  function, based on the plot tables provided by Sharp.  I will provide the code later, on GitHub.

The LED and the sensor

The main idea is  split the range of the sensor in three smaller sub-ranges and associate a color to each one of the:

  • 4 – 10 cm blue
  • 10 – 20 cm green
  • 20-30 cm red

if the object or the hand is at more than 30 cm (or a foot) from the sensor, we consider the stove is not harmful. However, if that is not the case, we have three intervals and three warning colors.  Each color is independent from the others.

IF the frequency of the loop is set to  say 50 ms, the whole system is very reactive to the movement of a hand.


I use a WeMos board. As many have pointed out, the Expressif chip has some current leakages.  in my case, the D5 pin, which is SCK and powers the red color,  is connected to an on board led.  I suspect there are some issues with it. Any way, the red color indicates a capacitor that needs to recharge periodically.  Anyway, I am happy with my WeMos board. I have already tested several interesting configurations.

AS a final remark, when I tried to use other pins than D5, the led stayed unlit. It might have an issue with the current available to the board. There are plenty of forums and  groups out there and I will dig out this.