Securing ESP8266 Communication

Having a tiny device based on the ESP8266 and connecting it directly to the internet, is not a trivial task. The ‘thing’ needs to communicate somehow to at least one remote entity, and it needs to do this in a reliable way.
Regular plain communication, like TCP, HTTP or WebSockets might work in a sandboxed environment, localised on a single monitored and protected network. However, if only one single byte needs to escape this comfort zone, then all precautions need to be taken.

NodeMCU 1.0
NodeMCU 1.0

There are several problems that need to be accounted for in order to secure the communication. Out of these, three will be handled in this article:

  1. End-to-end encrypted transmission
  2. Remote server identity
  3. Local device identity

One way to handle device identity is to flash a generated client key and certificate alongside with the sketch, and use them to authenticate against the server. However, this aproach is rather bulky, and hard to implement when provisining multiple devices.
A simpler option is to generate a unique set of device address/keys and implement safe storing and mapping mechanism:

  • the device stores its unique adress either in memory (if always on), hardcoded in the sketch, flashed as data, or stored in the EEPROM (a bit insecure, because it can easily be read). For additional security, the final device address can be interleaved with pieces of the ESP8266 hardware adress.
  • the remote server contains a mapper which maps a single device address to a unique device id, in this case maybe even human readable. This is required if the device owner needs to do some registration or administration, so he/she should not know the ‘physical id’ of the device. Also with this, the human factor of exposing the device adress is eliminated.

For the other two problems, the end-to-end encryption and remote server identity, the Arduino port for ESP8266 has a nice secure client library called WiFiClientSecure. It’s not really a state of the art, but if used properly, it will do the job just right.

The WiFiClientSecure uses a TLS implementation which is based on the axTLS library. It supports TLS 1.2, so generally a default up to date server configuration will work.
However, the ESP8266 is still a limited embedded device, and the library itself is also constrained. In order to properly use it, please be aware of the following:

  • the device can’t store and process trusted CAs in order to verify the server certificate. In order to do so, the SHA1 fingerprint is only saved and compared.
  • the axTLS library supports only the following cypher suites: TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256 and TLS_RSA_WITH_AES_256_CBC_SHA256
  • the library can also be a bit buggy of the certificate is too big, or if you’re dealing with big payloads
  • the server configuration needs to be as precise, complete and simple as possible, meaning full correct configuration with no redirects and no rewrites

Getting the pieces together

1. Server configuration (apache httpd)

In your apache.conf, you need to map port 443, enable SSL, and bind the certificate(s):

2. Check the configuration

Go to and scan your server.
In the results, first check the following sections:

  • Server Key And Certificate. They should all be valid, up to date, and the name of the certificate pointing to your domain/server name. Check the RSA KeySize as well, 2048bits works just fine, and according to the docs, axTLS can handle 4096 as well
  • In the configuration section, see if TLS 1.2 is there (TLS 1.0 and 1.1 will work too) and from the list of Cipher Suites search for the supported ones listed above. At least one of them should be present.
  • Find the Incorrect SNI alerts entry in the Protocol Details sections. It must not show any problem at all.

3. Extract the fingerprint

With Chrome:

  1. Open your website (use https if you use both HTTP/HTTPS)
  2. Open DeveloperTools
  3. Go to the security tab and click on View certificate
  4. Expand the details and go to the bottom to see the SHA-1 fingerprint

4. Client implementation

The Arduino code is rather straight forward, and a sample is included in the library examples. If you can’t find it in the examples menu, you can check it out from github:
For your implementation, adapt the server hostname, the location(s) to your resources and of-course the logic.
Since in most of the cases, the devices will periodically communicate to the server, you can instantiate the WiFiClientSecure object globally and reuse it at every loop.

5*. Debug (if needed)

If something goes wrong, simple tracing and logging throughout the code will not help you a lot. When the SSL comm breaks or fails, a little is shown directly. One layer of additional debugging output can be achieved by executing “Serial.setDebugOutput(true);” after initializing the Serial object in setup(). But most often, that will not be enough.
In order to get all the details, you need to enable full debugging. If you use a NodeMCU as a development board, and you have it selected in the Arduino, then the debugging option will not be visible.
To enable full debugging for the NodeMCU, follow these steps:

  1. from the boards menu, select Generic ESP8266 Module
  2. from the freshly appeared options, find Flash Size, and choose 4M (3M SPIFFS)
  3. select nodemcu as Reset Method
  4. from Debug Port choose Serial
  5. from Debug Level choose core + ssl (or even + TLS mem)

Re-flash your sketch and open Serial Monitor. You should now see a lot more info.

At the end, again, if something goes wrong, rarely a direct error message will appear. My suggestion here is, if you’re up to date with your Arduino SDK installation and board libraries, inspect in details your server settings, because there is not much you can do wrong on the client side.

DIY Java & Kubernetes (Videos and Samples)

This year, on three occasions, I presented about Kubernetes and how you can use it on the Google Cloud Platform, or your own home-built cluster.

Kubernetes RaspberryPi cluster
Kubernetes RaspberryPi cluster


Two of these presentations were recorded, and are available on youtube. The presentations, alongside with the code samples explained below, can be a great quick-start guide for making Java microservices or apps with Spring Boot and deploying them on a Kubernetes cluster.

The code samples (a bit modified though) are available on github:
In order to smoothly migrate from a single app deployment and basics of running Kubernetes, to splitting the app into microservices and deploying a full distributed scenario, I made two implementations:
– kub-calublog is a monolithic Spring Boot application which works with in-memory database and represents a very simple blog platform.
– kub-calublog-ui and kub-calublog-service are ‘microserviced’ pieces of the same application which use HATEOAS RESTful calls between them.
– kub-calublog-deployment contain the scripts and resources for deploying the app or services on a cluster. /simple is for basic single app deployement with docker-like commands, while /kubernetes is for the reccomended declarative methods. /kubernetes-arm is just a showcase if a RaspberryPi ARM based deployment is to be done.

Things to do in order to get started:
– Sign up for a Google Container Engine free trial.
– Create a project, allocate machines (up to 4 shared will do)
– Install gcloud SDK on your machine
– Watch the video(s) and experiment on your own, having the samples for help. (make sure that you replace properly the docker.prefix places in both the pom.xml files and deployment scripts)

– jPrime ’16:
– Voxxed Days Belgrade ’16:

Other resources:
– Devoxx presentation done by Ray Tsang (@saturnism) and Arjen Wassink (@ArjenWassink):
– gcp-live-k8s-visualizer:
– Setting up Kubernetes on a RaspberryPi cluster:
– RaspberryPi Kubeternetes stack 3d design:

TheThingsNetwork LoRa node with ESP8266 and RN2483

TheThingsNetwork is a global community with a mission of bringing the Internet Of Things world closer to the people and making the connectivity easy and completely free. It’s doing that by providing open to use communication base stations and distributed back end system that handles all the communication, security and data availability throughout your devices and target system.

The communication protocol used is LoRaWAN. It allows low powered devices to connect from far distances, having in mind that they can only send or receive short bursts of data every now and then. The communication works on open frequencies, meaning that they don’t rely on regulators or major telecommunication providers.

Recently I applied for a local TTN community in Skopje, which got approved and the infrastructure is still in development. For the first test subject, I used Arduino Uno combined with the Microchip RN2483 for LoRaWAN connectivity. It’s the most basic example and it worked just fine. However the real requirement is to have an ESP8266 main controller that will talk to the RN2483. The reason for this is, that the case I’m working on needs an end-user configuration mechanism, and the ESP’s integrated WiFi and WebServer are just the thing.

For convenience and easier prototyping, I used the NodeMCU devkit board which is based on ESP-12E chip. It resembles Arduino quite much, has direct micro USB connection removing the need for FTDI and has all the pins necessary to connect the RN2483 chip and additional sensors / actuators you’ll need. For development, you can use the Arduino IDE and SDK with the ESP8266 boards and port. I’ve written on this topic before here (it may be a bit outdated though…).

Part 1: Connecting the parts

For a very basic setup, you’ll be needing a proto PCB (or a protoboard if you don’t wan’t to solder everything just yet), NodeMCU 1.0 devkit, RN2483 chip, some patch wires, solid core wire to act as an antenna, and soldering wire.

The NodeMCU has a bigger form factor than the RN2483 chip, so it’s possible even to solder them tightly together or one under the other by using some header pins aside.

The connection between the two goes like this:

RN2483 TX (6) <-> NodeMCU D6
RN2483 RX (7) <-> NodeMCU D5
RN2483 VDD (12 or 34) <-> NodeMCU 3.3V
RN2483 GND (20 or 33 …) <-> NodeMCU GND
RN2483 RESET (32) <-> NodeMCU D7
RN2483 RFH (23) <-> Antenna or 8.6cm solid core wire

My gruesome implementation looks like this:

NodeMCU + RN2483 side    NodeMCU + RN2483 top

Part 2: Prepare a TTN app

Go to TheThingsNetwork and create an account if you don’t have one. Check afterwards in your local community whether you have LoRa TTN coverage in your area.

After that, go to the staging app and create a new application. Choose Activate Devices with default app key in order to be able to use OTAA (this is not mandatory, I’m just using OTAA in the example code). When the app is created, take the App EUI and in Settings get the Default App Key. You’ll be needing them in the code afterwards. Leave the main app page opened, so that you can see the connections and the data sent afterwards.

Part 3: Code

Before you go off coding, first do some preparations:
– get the latest Arduino IDE
– install the nodemcu devkit driver
– install the esp8266 board in the Boards manager (or update to the latest)
– install the RN2483 library
– install the ESPSoftwareSerial library

The code I’m using is a modification of this nice tutorial done by jpmeiers.

*) this is the bare minimum you need in order to start things working. I got it by modifying the original code and removing the other parts afterwards, so let me know if something is not right.

When you got all packed, choose NodeMCU to be your current board, fire the serial monitor, set it to 57600 baud rate, and flash the code to the device. If everything is fine, you should see nice messages in the serial log, and by refreshing the app page on ttn, you should see your device registered and messages arriving every minute.

Part extra: extend and pack

The final product I made with all this is a Dust, Temperature and humidity TTN sensor node. You can do that by combining DHT22 (tutorial here) and sharp dust sensor (arduino tutorial here). However, the code still looks a bit shaky, and the dust sensor might need some extra work and/or calibration, so I don’t dare yet to publish it.

Dust, Temperature and Humidity LoRa TTN Sensor
The final sensor node prototype

And as a final touch, I designed a custom enclosure in OpenSCAD (a mix of this design by b2vn) and I 3D printed it. I just made it longer and wider, and put holes for the DHT and the dust sensor opening, to have air circulating.

The final result:

Dust, Humidity and temperature TTN sensor node with 3d printed housing
Dust, Humidity and temperature TTN sensor node with 3d printed housing

OpenJFX with RaspberryPi

JavaFX on the Raspberry Pi is a particularly nifty platform to use when you need a nice looking GUI on a regular monitor or a touch-screen. The platform used to ship along with JDK8 for ARM directly and was bundled (last I saw it still was) with out of the box Raspbian.

However, from update 33,  Oracle decided to drop the support for JavaFX on the ARM distribution of their JDK, and stopped shipping it within as well.

However the story doesn’t end here. This change just expedited my idea to give OpenJFX a try, after which I wished I did that way sooner.

My test bed was a RaspberryPi with PiTFT and a touchscreen adapted JavaFX application. Previously I had implemented a headless start of the JavaFX application with fbcp running in the background, and having all the parameters for the touchscreen set right in order to get a nice and correct projection of the FX framebuffer. With OpenJFX, this was no longer needed, cause it is directly supported.

In order to quickly get and use OpenJFX on Raspbian, follow these steps:
– Get and flash a fresh Raspbian image. Make sure you have java and javac present.
– Download a built OpenJFX package (OpenJFX 8u## stable for armv6hf). I used @chriswhocodes OpenJFX builds. There are others listed at the OpenJFX community builds page.
– Extract the contents of the zip file. Copy the /jre/lib folder contents somewhere in your project (I simply copied everything to the project root folder).
– (include the /ext/jfxrt.jar file in your classpath if you compile in an environment without JavaFX present in the JDK)

Finally, when executing your java application, pass the following arguments to the JVM:
-Djava.ext.dirs=dir/to/jfx/ext (I used .dirs=ext because I unpacked the lib contents in the project root)
-Dmonocle.screen.fb=/dev/fb1  (only if you use a touchscreen (like the PiTFT)
-Dprism.order=sw (again only for touchscreen, but I’m not really sure. If you experience problems with eventual hardware rendering, use this)

The outcome was pretty pleasant. The UI was looking good and it adapted just fine, although be careful with the dimensions and the general conditions (see tips here).  Also, I had no need to calibrate the screen, it was working correctly from the first run. And last but not least, having not to use fbcp in the background is a huge performance boost and resource saver.


Main screen with buttons LED light screen with color picker


WiFi light with ESP8266 and Arduino code

The ESP8266 microcontroller chip is out there for almost a year now and it has already made a huge boom in the makers and IoT communities. It is cheap ($5),  it has built in WiFi capabilities, and as of a few months ago, it is Arduino compatible.

Besides the unique built in WiFi capability, the ESP8266 has its own 32bit CPU running on 80MHz, up to 4MB flash, and can be extended with other devices via the GPIO pins which can act individually or as SPI, I2C or UART interfaces.

The early versions of the chip were used as add-on modules which provided WiFi access to an Arduino board. The communication was done via the exposed Rx and Tx pins and by using series of AT commands.  However, after a while, the manufacturer released an SDK allowing code to be uploaded directly on the ESP chip and thus removing the need for a separate driver board. But still, the experience wasn’t nice, since the tools were buggy and the code was to be done in Lua. Then, after months of adaptations, an Arduino IDE port was release targeted for ESP8266, and it was a game changer.

What I did as a POC of the entire platform is a Colored WiFi light that I can control via my phone browser. My whole idea is to have this integrated in a home automation system, but let’s go step by step.

Hardware requirements:

  • NodeMCU devkit (preferrably for ease of usage and testing; or other ESP8266 board properly connected via FTDI)
  • A WS2812 / 2811 / NeoPixel LED strip. (any would do, just keep the number of LEDs low, so you won’t need external powering. You can even use PiMoroni’s Unicorn HAT)
  • Jumper wires
  • Micro USB cable (if NodeMCU) is to be used

To connect the WS2812 LED strip, use the jumper wires and connect the DataIn pin to GPIO4 which is actually D2 from the board, the input voltage to 5V on the board, and GND to any GND pin.

The NodeMCU devkit is a device board for prototyping with the ESP-12 chip. I’m using here the 0.9 version of the devkit, which is not the most recent. Bear in mind that the pin numbering on the board is NOT the same as the GPIO numbering in the SDK.

NodeMCU devkit 0.9
NodeMCU devkit 0.9

Next, download and configure the Arduino IDE:

  • Download and install the latest Arduino IDE with the Board Manager for ESP8266  as described here.
  • Get and install the device driver for the on-board USB to Serial from here. (needed for NodeMCU)
  • Get and install the NeoPixelBus library to your Arduino installation. Do that by placing everything in the folder arduino/libraries/NeoPixelBus.
  • Launch the Arduino IDE and choose the board to be NodeMCU (or generic ESP8266 if using the sole chip via FTDI) and select the COM port to which the device is connected.

Finally, the code to make it all work. You can see prior to this that there are already several examples which can get you started (look at the web server examples and the ones from the NeoPixelBus library). What is needed here is basically a mix between those two , some proper handlers and a simple web UI.

My try:

In order to make the code work, you need to enter the SSID and the password of your network in the code. In my case, I set my phone to broadcast a personal hotspot, and I’m connecting directly to it. Also, set the pixelCount to the exact count of pixels you have in your WS2812 strip.

To upload the code to the device, you just click on upload in the IDE, and if everything is fine, the code will be compiled and flashed, and the ESP will be restarted immediately. To see the status, you can use the Serial Communication inspector in the IDE. It will also output the designated IP address from the DHCP server on the network.

At the end, open a browser in the same network and point to the device IP directly. Click on any color and see what happens. Here’s how it turned out on my side.

WiFi light
WiFi light: device
WiFi light: UI
WiFi light: UI

As a conclusion, I’m pretty satisfied with the outcome. The entire process was relatively short and straight-forward, and besides the device driver troubles I had, everything else went smoothly. I’m also pretty excited, cause more and more stuff is getting adapted for this platform (e.g. DHT sensor library) and inevitably will become the platform to code  and make future IoT prototypes.

Useful links:

Hi-Fi Audio Center with RuneAudio and RaspberryPi A+

For quite a long time, I had a RaspberryPi A+ just laying around and doing practically nothing. Every now and then I used it for some testing and occasionally playing around with the Unicorn HAT, but overall, because of the lack of connectivity and performance limitations, it remained heavily unused.

Then one day, I stumbled upon and I liked every aspect of the software and the concept behind it. Having a miniature audio center at my apartment which can connect to my music library and be able to accept music streaming, was a great idea. So I decided: my A+ will finally meet the reason it was created for.

The procedure for getting the whole thing is rather forward, but can be bumpy based on the equipment you have.

  1. Acquire a RaspberryPi A+ with a microSD card (preferably class 10, 8GB) and an adequate power source
  2. Think of how you want to connect the rasberry pi to your home network. The A+ doesn’t have an ethernet port, so if you want wired connection, get a USB to ethernet adapter. If not, do what I did, and get a wi-fi dongle. I used Tenda Pico wireless adapter. It was one of the supported adapters at the official RaspberryPi documentation site, and it hasn’t caused me any troubles before. Also, it’s rather cheap.
  3. Download the image for the rasbperry pi based software.
  4. Follow the steps for flashing the SD card with the image.
  5. Connect everything.

Now, if you have an usb to ethernet adapter, I suppose everything should work right off, if your router has DHCP enabled.

If however you use Wi-Fi for connectivity, the procedure is a bit more complicated, since the A+ has only one USB port and it will be used by the Wi-Fi dongle.

There are two possible ways of handling this:

  1. Try to connect a self-powered USB hub and attach the dongle + usb keyboard to it. Then, through the console, try to configure the Wi-Fi connection by using wifi-menu. Some details here. The username is ‘root’ and password is ‘rune’
    This however, regardless of how simple it seems, I failed to configure. Therefore:
  2. Get a B+, connect it to your router (or crossover to a computer) via ethernet and plugin the wi-fi dongle. Boot everything, and wait enough time (around 1-2 minutes) for the software to start. Then, from a computer on the same network, try to open http://runeaudio.local/ in your browser. If that fails, then seek for the IP address in your router (the hostname is runeaudio) and try with it (e.g. In the menu open network and configure your wireless connection (http://runeaudio.local/network/). Next, shutdown the system via the UI and poweroff your B+. Eject the SD card, insert it in the A+, move the Wi-Fi dongle to the USB port as well and power the device on. If everything is OK, you should be able to access the system at runeaudio.local.

At this point, runeaudio will use the audio jack on the A+ to render the music at. However, this is not the perfect option since the Digital to Analog converter there is possibly trivial. Therefore, you might think of acquiring an external DAC which will improve the overall quality. Some of the supported DACs are listed in the homepage of the project. Bear in mind, that the DAC will add no value if you use cheap RCA cables or low-end audio system.

I used HiFiBerry DAC+ with RCA connectors. The price is fine and the shipment was quite fast. In order to configure runeaudio to use the external DAC, simply open the web UI, go to settings and choose your device from the listed I2C kernel modules. It will require a reboot which is not a problem. Then, open the web UI again, go to MPD and choose the Audio output interface to be the DAC you’ve just configured.

Sweet, sweet sound (RasPi A+ with HiFiBerry DAC+ running on RuneAudio)
Sweet, sweet sound (RasPi A+ with HiFiBerry DAC+ running on RuneAudio)

After installing and getting the whole thing up and running, you can resume on with configuring it.

RuneAudio has a pretty nice web UI which will allow you to do everything you need. By now, I haven’t got to the point where I need to access the device via SSH and do some manual config.

Out of music sources, you can add several. I would just mention shared network libraries, AirPlay, dlna and spotify.

RuneAudio WebUI
RuneAudio WebUI

As a conclusion, I must say I’m pretty satisfied with the outcome of this project. I’m mainly using it via AirPlay and so far it hasn’t caused me any troubles, regardless that it is connected solely by a cheap Wireless g USB dongle.

There might be some situations where the web UI will be non responding, some settings will not be saved from the first time or the loading spinner will not disappear (often happening during active air play stream). Besides that, the entire system is a rather cheap but effective, high-quality and most importantly, very usable.

DoorNFX: Touchscreen JavaFX 8 on Raspberry Pi

As of March 2014, Java8 is finally out there. Bunch of new features and improvements, not that they weren’t known previously, but good that they went official. The ones that I’m targeting with this blogpost are JavaFX, JDK8 on ARM devices, and their joint functionality.

The new JDK for ARM is targeted specifically for v6/v7 ARM HardFloat ABI devices running on Linux. The best and world-wide accepted example for this is the Raspberry Pi running on an OS like Raspbian. This JDK was around for some time with the early access program, so I had the chance to play around with it previously. However, for the example below, I’m using the official version.

JavaFX is, as the definition says, a set of graphics and media packages that enables developers to design, create, test, debug and deploy rich client applications that operate consistently across diverse platforms. In short, it’s a Java framework building Rich Internet or Desktop applications. Some of it’s features include:
– Pure Java API integrated in JavaSE: as from Java8, JavaFX is an integral part of the JRE and JDK. It’s API i in pure Java so it can be used any language that runs on the JVM.
– UI can be defined either programmatically or declaratively via FXML
– Interoperable with the old Swing
– All UI components can be styled with CSS
– New theme ‘Modena’ which makes the UI look very nice fora change
– General 3D features, hardware acceleration support
– WebView component which allows two-way interfacing (Java to JavaScript and vice-versa)
– Canvas and printing API, support for RichText
The easiest way to explore JavaFX is to play around with the Ensamble app on the Oracle web site.



So, as an example, I decided to make my NFC PN532 Java port to some usage and make some exact device out of it. My idea was to make a protected door access node which reads NFC Tags, prompts for a user code, authenticates it against some remote server and grants or declines access based on the output.

The core of the device is a RaspberryPi model B. The GPIO section has more than enough options for connecting multiple external devices. For the device, I’m using two such devices which are made specifically for the RaspberryPi: PiTFT and ITEAD PN532 NFC module.


DoorNFC - Device

The touchscreen used is the adafriut 2.8” PiTFT resistive touchscreen with 320×240 resolution. It is a actually a Pi HAT device with a socket the same as the raspberry pi. Its assembly is very easy, and it’s usage with the Raspbian OS is relatively simple. For communicating with the RaspberryPi it uses the SPI interface.

The ITEAD NFC Module is a PN532 based board with an integrated antenna. It exposes the same functionality as all the other PN532 boards and uses either SPI, I2C or UART for communication. However, this device also has a native RaspberryPi header interface. One bad thing is, this interface can only work with SPI. Since the SPI and the same channel is already taken by the PiTFT, I made some alteration of the NFC module in order to patch it to work with the same header but by using I2C. I’ve described that procedure in my previous blogpost.


As the core for starting the device, I used the pre-built adafruit image of the Raspbian OS. This image is described in details in the adafruit tutorials section. Basically, it is a Raspbian OS with the patched kernel, driver and necessary configuration to enable and use the PiTFT. Besides all that, it also comes with JDK8 and nicely split GPU/CPU memory which is the core need for running JavaFX applications on the Pi.

With only the image however, the job for configuring the device is not done. First, the FrameBufferCopy tool (fbcp) will be needed:

Then,  the start-up console needs to be disabled. Do this by removing the fbcon map and fbcon font settings in /boot/cmdline.txt.

Next, and this is the trickiest part, the display needs to be adaptad to be with the same format as the PiTFT. The touchscreen is designed to be in portrait mode with resolution of 240×320. The original configuration of the X server done here is by rotating the display and re-calibrating the touchscreen. JavaFX runs in a framebuffer and it’s not connected to X whatsoever. Therefore, the display and the touchscreen behavior work differently and wrong. This can be fixed by force-adjusting the display resolution to 240×320 and not rotating the screen by default. In order to do so, alter the settings in /boot/config.txt:

and by resetting the rotation in /etc/modprobe.d/: rotate=0

At the end, in order to enable I2C, modify /etc/modules by adding:

and comment out i2c in /etc/modprobe.b/raspi-blacklist.conf.


The software for the device is already on github:

There are two packages present:

Writing JavaFX code for the Pi is rather straight forward. The  most important aspects have to be met at start, as they are more environment related. Others are just tips. Some that I can mention:

  • The CPU/GPU memory split needs to configured correctly in order to achieve nicer performances (or even to get the JavaFX app up and running). 128MB for the GPU is a decent amount.
  • The JavaFX app will run in a framebuffer. This is maybe the biggest difference that you must have in mind. Running JavaFX apps on the Pi is not conditioned by the presence of an X server: they don’t run in a widget or a frame and can be invoked straight from a console. Even better, running a JavaFX app from an X session will most likely break it and freeze the UI after you exit it. Always execute the JavaFX app from a console, local or remote.
  • Because the app will run in a Framebuffer, make sure that you use and manage all the visual space that you have in your disposal and run it in full screen. You can still run it with fixed size, but then it will most probably end up centered on the screen.
  • JavaFX will register it’s own Keyboard and mouse handler and render a mouse pointer. If you have some settings done in X that change the behavior of the mouse or the keyboard, they will not be present here. E.g.: a major problem with the touchscreen was the initial rotation. The screen was rotated, but the touchscreen was only calibrated for that in X. That’s why the settings here are reversed and the display is in portrait.
  • Last but not least: JavaFX runs in its own thread. If you are to populate other heavier operations from the main routine or an event handler, do it in a different thread. If you need to alter something UI related from a different thread, use Platform.runLater.

You can see some examples already implemented in the source code. It’s not very pragmatic or anything, but enough to get the idea and to get the device working.

A general frame of a basic JavaFX app looks something like this:

The other part of the code is the pi4j usage. Here I’m using the managed way to access the hardware aspect of the Pi and send/receive data through it:

  • I2C is used for communicating with the NFC PN532 module. The API is simple but the hard part is maintaining the protocol set by the device manufacturer:

    The adress of the device can be given by the manufacturer of the device,  or you can look it up with the tool i2cdetect or something similar. See some tips in this adafruit tutorial.
  • General I/O pin provisioning can be also combined, regardless that both SPI and I2C are used. Just make sure that you don’t provision a PIN somehow that will break the other two interfaces. Again, here I’m using the managed API of pi4j:

Some remarks about using pi4j:

  • Since pins need to be provisioned (exported), the java process MUST be started with sudo, or else it will fail.
  • I2C is used for communication, so make sure that the device is enabled and not blacklisted
  • The communication is not reliable. Your app should be prepared for that and easily recover from misscomunications.


For ease of access, I’ve added two shell scripts ( and to make my compile&test experience on the Pi bearable. The pi4j library is automatically added in the classpath in both compile and test, the java process in run with sudo and fbcp is run in parallel.

The performance of the app itself is so-so. I can’t really deduct a conclusion since fbcp is an important parameter, and it may alter the visual response. Overall it is usable, but still not on that level that I want to see.

Always bear in mind that the device is quite limited with resources, and the platform itself is still catching up. It would be great if some ideas done in OpenJFX like setting a target framebuffer or altering the touchscreen input are implemented in the Oracle JDK too. That way, the output will be independent and I would presume more efficient.

P.S. I’ve also done a different JavaFX app which reads RFID tags, runs on an HDMI monitor, and is used as a poll. The output is quite bigger, the solution is simpler, but the overall user experience is still similar.

ITEAD PN532 NFC Module and RaspberryPi via I2C and Java

In my last post I explained how I got the ITEAD PN532 NFC Module up and running with a RaspberryPi by using plain Java code with pi4j and SPI as an interface for communication.

However, for a different idea, I needed the SPI interface to be available completely, and that meant that I must somehow change the implementation for the NFC module. One option is to use I2C as an interface and to adapt the hardware and the software to use it instead.

The ITEAD PN532 NFC Module, has only the SPI pins connected at the RaspberryPi connector. I believe this is some compromise that the guys at ITEAD must have did. However, the PN532 supports SPI, I2C and Serial, and all these interfaces can be accessed through the other connector, having in mind that they share the same pins.

In order to achieve I2C communication with a RaspberryPi, the following steps need to be made:

1. Change the switches on the NFC module to indicate that I2C will be used: SET0 set to H and SET1 set to L.

2. The I2C pins need to be rewired manually to the I2C pins of the RaspberryPi connector. My gruesome workaround is this:

itead back rewire

3. The SPI pins of the RaspberryPi connector are still conected to the same shared pins, and with the rewiring, the I2C and SPI are interconnected and they won’t be functioning properly. To avoid this, the SPI pins need to be removed. Again, my workaround by cutting the 5 pins from the connector:

itead front rewire

As of now, the device is ready to work with I2C. In order to test it, you can use the libnfc as described in this ITEAD studio blogpost. (see from number 8 onward).

The final step was to make all this functioning with Java code. For that, I extended my library by porting the elechouse PN532 implementation for I2C to Java with pi4j. After some struggle with the proper API usage, the implementation got quite clean. It is already added in the same project at GitHub.

As of this point, since I got everything working, my idea is to resume with this projec, port the whole PN532 implementation to Java, and making the API more clear to use. That I will cover in a future blog post.

NFC with RaspberryPi and Java

For a presentation I did, I needed to come up with a neat example of directly connecting a RaspberryPi with some add-on device. The ITEAD PN532 NFC Module looked perfect for this case, and I started working with it. My end goal was to operate it with Java code.

RaspberryPi with ITEAD PN532 NFC Module
RaspberryPi with ITEAD PN532 NFC Module

The ITEAD blog has a nice example plus a library done in C for interfacing the NFC Module.  It uses the SPI interface and operates on a low level by using the WiringPi library.

The pi4j library is a JNI to the WiringPi C library, so in basic terms it should be able to do the same thing.

I started by porting an Arduino code first (github link) and using the Serial interface for communication, but I failed. Then I started porting the ITEAD provided library and used the SPI interface as in the original code. After some struggle, I managed to devise some working code:


  • there are two interface implementations: PN532Spi and PN532Serial. The second one is marked as @Deprecated because it’s not functioning for some reasons
  • the SPI implementation at the moment can only get the firmware version and read the passive target id of an NFC tag. Hopefully I’ll implement the other functions soon.
  • before using the SPI interface, make sure that it is enabled. See the notes in the ITEAD blogpost and in the github repo readme.
  • when starting the example, execute java with sudo in order pi4j to work properly.

WebSockets in Java

At the second JavaDay in Skopje in 2013, I talked about WebSockets and how to do them in Java. As a base for explaining, I’ve created a simple chat room application along with three different WebSocket implementations: JavaWebSocket, JavaEE7 and Spring4.


The application prompts for a username on start, shows all the present users in the room, provides basic chat functionality and does automatic log out when the browser tab/window is closed.

The slides of the presentation are available at SlideShare.
The talk is available (in Macedonian only) at Parleys.
The whole source code (explained in short below) is avalable at Github.


Client application

The client application is built with jQuery 1.10.2 and Bootstrap 3.0.3. For the first two examples, native WebSocket API is used for the communication.

At the start, a bootstrap modal dialog is shown for entering the desired nickname. When it’s confirmed, the whole application is being initialized, the communication procedure is started up, the events are bound and the jQuery assisted DOM manipulation is defined.

The JavaScript WebSocket API is quite simple and it involves just creating a web socket connection and binding the four communication events:

  • onOpen – when the connection has been successfully opened
  • onMessage – when a server sent message has been received
  • onClose – when the connection has been properly closed
  • onError – when a communication error has occured and the connection has been severed

The basic shape of a javascript WebSocket handler is:

In the implementation, the messages that the client sends to the server are pure text. By convention, the first message sent is the username, while every next one is a message that the user is sending to everyone else.

For better manipulation, the messages that are being received from the server are placed in JSON objects. There are three types of messages that the server can send:

  • addUser message – a message that has only one field ‘addUser’ containing the username to be added to the list, i.e. a new user joins the chat
  • removeUser message – a message that has only one field ‘removeUser’ containing the username to be removed from the user list, i.e. a user closed the chat
  • message message – a message that has two fields: nickname and message, describing a sent chat message from the user ‘nickname’ and contents ‘message’

There is no logout option, since the tab/window closing automatically closes the WebSocket and the server gets this event.


JavaWebSocket implementation

One of the simplest ways to start-up a WebSocket server is by using a standalone implementation like the Java WebSocket (github link).

In order to use it, you need to create a standard Java7 application, which defines an extension of the WebSocketServer class, instantiates it and starts in the main routine (or anywhere applicable). The WebSocket server will run as a background thread as long as it is not explicitly stopped or the application is terminated.

The class that resembles the WebSocket server should pass a proper base constructor for the target IP and port, and override the four methods that are basically the event handlers in the WebSocket communication life cycle:

Several notes here:

  • There is just one instance of the WebSocket server. It handles all the connections and the communication.
  • The WebSocket server implements the very same methods / event handlers as present in the client side: onOpen, onClose, onMessage and onError, having now, the onMessage is triggered when a message is received from some client.
  • For every opened websocket connection, there is a single WebSocket object instantiated. That object will remain the same and present until the connection is closed somehow. It can be referenced anywhere from the code and used as the WebSocket handler for that specific connection.

In my example, I store every WebSocket object in a set, and map them in a Map to their nickNames for future usage. When a connection is opened, the WebSocket instance is stored in the set, and when the nickname is passed, in the Map as well. When a message is received, the set is being iterated and the messages is sent to all active clients. In case if a connection closes or it’s being terminated by an error, the WebSocket instance is removed from the map and the set, and the ‘removeUser’ message is sent to all other clients.

For more details, see the JavaWebSocket sample in the source code. In order to run this sample, you need just a Java7 runtime. Start the server as a Java application and then open the chat.html file with your browser. (note: this is an Eclipse project)


JavaEE implementation

JSR 356 defines how the Java API should look like in the enterprise application servers in order to provide server side and Java client side WebSocket functionality. It is already implemented in the most popular application servers.

Apache Tomcat originally implemented JSR 356 and dropped its own WebSocket implementation in Tomcat 8. After a while though, the same functionality was back-ported to Tomcat 7.0.43. It’s usage again is bound by using Java 7.

There are two ways of how a WebSocket server can be defined in JavaEE7. As in many of the other Java APIs, there’s the annotation driven approach, which provides very simple means for creating basic server side constructions. There’s also the extension (interface based) approach by extending the base WebSocket classes and overriding the methods implementations.

A very basic annotation driven WebSocket implementation in Tomcat is comprised by using the following annotations:
– @ServerEndpoint(path) – for defining a class as a WebSocket endpoint at the specified relative path
– @OnOpen(Session), @OnClose(Session, CloseReason), @OnMessage(String), @OnError(Session, Throwable) – for defining the methods handlers for the four events in the WebSocket communication lifecycle.

Sending message back to the client is performed by getting a remote object from the session, and sending data through it. E.g.: session.getBasicRemote().sendText(text);

The session object is unique and persistent for one client throughout it’s communication life-cycle. It can be stored and used in any other place your application.

On client side, everything is the same, except that now the port is 8080 (the same port at which Tomcat is configured to listen).

For more details, see the EESockets sample in the source code. In order to run the sample, you’ll need a Java7 Runtime along with a newer version of Tomcat 7 (> 7.0.43). It is again an eclipse project, so you may need to fine-tune the settings.


Spring 4 implementation

The freshly out Spring4 framework comes with it’s own and improved out of the box WebSockets implementation. It comprises of both well connected server and client side modules which provide native WebSocket communication and give a seamless fallback if no such option is possible.

In order to use the WebSockets implementation in spring,  the context configuration needs to enable both SpringWebMVC and WebSocket, afterwards to define the beans for the WebSocketHandlers and register them. If the spring configuration is done by Java code, it should look something like this:

Several things are important here:
– A web socket server endpoint in Spring is a implementation of a kind from WebSocketHandler
– PerConnectionWebSocketHandler is an extensions which basically says that a new instance from the WebSocketHandler class will be created for each WebSocket client.
– .withSockJS() says that this endpoint should be enabled for, and expect calls from the SockJS client library.

The WebSocket server implementation is done by extending and overriding the WebSocketHandler class. There is a small hierarchy already present in Spring, so e.g.: if only textual data needs to be interchanged, then the implementation class should extend TextWebSocketHandler, since there the encoding/decoding stuff is already handled:

Again here, the same four methods are being overridden, and similar pattern is used for sending data back to the client. The WebSocketSession object is again unique and persistent, and can be saved and used throughout the application.

One crucial difference now is the JavaScript client side implementation. Since the WebSocketHandler is sockJS enabled, the same library can be used for interfacing with it. The difference is minimal: instead of instantiating a WebSocket, include the Sock.JS JavaScript client library, make a SockJS object and bind the same functions to it:

What happens now is, that SockJS will first check if a WebSocket communication can be established (by polling a info sub-path first). If successful, then it is resumed as such. If not, then a fallback option is applied (e.g.: http long polling) and the communication is abstracted on top of it. At the end, only one WebSocket like handler is needed for defining the whole communication. Like this, regardless of the client browser, only one code base is needed to handle all types of communication protocols.

Please note that now when passing the address, “http” and not “ws” is used. This is not an error, since SockJS will try to upgrade the connection afterwards.

For more details, see the springsockets sample in the source code. In order to run the sample, you’ll need a Java7 Runtime along with a newer version of Tomcat 7 (> 7.0.43). It is again an eclipse project, so you may need to fine-tune the settings. In the maven settings, the proper repositories are also added, so if you’re behind a local nexus mirror, please make sure that they will be accessible. Also, I’m using Spring 4.0.0.RC2 here. You can change it to the most recent Spring version.