My Raspberry Pi runs the Qpid Dispatch Router

This morning my “embedded” soul had an idea for supporting my “messaging” soul and spending some time in a productive way … trying to compile the Qpid Dispatch Router on a different machine with a different architecture : it’s C/C++ code … so it’s portable by definition (even if related to Linux for now) … it uses Python but today this language is available on a lot of different platforms … so it seems to be no problems.

Searching for some embedded stuff in my closet and discarding Cortex-Mx based boards (for obvious reasons regarding Linux lack on them) I got my Raspberry Pi … the first version (ARM11 based … not Cortex-Ax) 🙂


I have the Pi2 as well (I have to by the third version) but I preferred to stop my research for starting immediately. I followed all the steps needed (explained in my previous article) using the Pi as a normal PC (connected via SSH) and after a while for compiling directly on the board, the router was up and running !


The only tweak needed was to force cmake to use the Python 2.7 library with following command line :

cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DPYTHON_LIBRARY=/usr/lib/arm-linux-gnueabihf/libpython2.7.so -DPYTHON_INCLUDE_DIR=/usr/include/python2.7 -DPYTHON_EXECUTABLE=/usr/bin/python

because the 3.x version is installed on the Pi as well but we can’t use it for the router.

I know .. it’s not the right way to compile source code for embedded devices and cross-compilation from my PC is the better way to do that but I preferred it in order to go fast and avoid to setup a complete ARM toolchain on the laptop; of course be patient … building the Qpid Proton took me about one hour ! I can suggest you to have a good coffee …

Before starting the router, another simple tweak was needed in order to make persistent the value of the PYTHONPATH environment variable writing the following line to the .bashrc file :

export PYTHONPATH=/usr/lib/python2.7/site-packages

Now I have an idea … Pi with its Linux version is SSL/TLS capable but there are a lot of resources constrained devices which are able to “speak” AMQP but can’t support SSL/TLS connections. Why don’t use the Pi as a “shadow” IoT gateway and it’s security capabilities in order to bring above constrained devices to reach SSL/TLS and AMQP based cloud platforms even if they can’t “speak” SSL/TLS ?

A new Internet of Things era starts today … the IoT Hub is finally here !

September 29th … what a day for Microsoft and related Internet of Things technologies !

Azure IoT Suite and IoT Hub are finally here ! The IoT Hub is available in public preview and ready to help you to develop your IoT solutions in a very simple manner !

Where you can find all useful information about them ?

First of all the “Azure IoT Suite now available” blog post on official Microsoft web site focused on Internet of Things.

On Microsoft Azure documentation section you can find the dedicated “Azure IoT Developer Center” that will guide you to create a new IoT Hub on the new Azure management portal and connect one or more devices to it.


Starting with IoT Hub is very simple if you follow the documentation page here. A lot of examples, how-to guides for sending data from device to cloud and command from cloud to device, handling devices and so on.

Devices are a very interesting story !

There is a certified IoT program with all current hardware platforms and silicon vendors certified for accessing to IoT Hub. Of course, not only Raspberry Pi and MinnowBoard (we know them with Windows IoT Core) but BeagleBoard and Dragon Board 410C too. As embedded developer I love Freescale FRDM-K64F and Texas Instruments CC3200 LaunchPad too. It’s possible for you to become a partner and certify your hardware platform !


To simplify your life, you can follow the main steps at this page for :

  • Select a device (Raspberry Pi 2, MinnowBoard Max, Freescale FRDM-K64F and so on)
  • Select a platform (Linux, Windows, mbed , TI RTOS). The list is filtered based on above selected device
  • Select a language (C, C#, JavaScript, Java). Pay attention … it’s not filtered …but remember you can’t use C# on Freescale FRDM-K64F 😉
  • Configure your IoT Hub with all steps on the new Azure management portal
  • Connect your device with all steps to do it

Great news … all Azure IoT SDKs are open source and available on GitHub !

A great partnership I like too much is with the ARM mbed platform as discussed on the ARM official blog. Currently only the Freescale FRDM-K64F board is supported but it’s a great starting point. On the mbed web site you can find the official Azure IoT account with a lot of source code related to the IoT Hub client implementation and related examples. Of course the client uses AMQP protocol to communicate with IoT Hub and for this reason the Qpid Proton C porting on mbed is available there. Just think … it can be useful to you to access all Service Bus entities (queues, topics/subscriptions, event hubs, …) from mbed enabled boards like the Freescale one. Remember that the Microsoft Band has a Kinetis MCU from Freescale (here the Sparkfun teardown) ! 😉

Of course .Net Micro Framework support on the boards from GHI or Secret Labs aren’t available “out of box” but using the great AMQP .Net Lite library you can use them with IoT Hub. Don’t worry … my open source developer soul is just thinking to a new project library for it 😉 It’s the same for industrial Windows Embedded Compact 2013 devices.

Regarding Azure IoT Suite and all related services for storing messages and predictive analysis there is a dedicated web site you can start to create a full IoT solution from predefined scenarios (with provisioning and monitoring of course) you can customize.

What if you have MQTT based devices or you want to develop new devices using this protocol ? How you can connect them to the Azure IoT Hub ? Don’t worry, Microsoft provides you the “Azure IoT Protocol Gateway” that is a framework for protocol adaptation that supports MQTT v3.1.1. You can deploy it in the Cloud as a worker role or in on-premises environments such as field gateways.

If all above material isn’t enough for you, there are some great videos on Channel9 from AzureCon :

In conclusion, today starts a new IoT era … after people hub and all the other hubs on your Windows Phone … you have the IoT Hub in the Cloud with all your devices !

Mobile Camp 2015 : telemetria da Windows 10 IoT Core all’Azure Event Hubs


Anche quest’anno ho avuto il piacere di essere speaker al Mobile Camp organizzato da Microsoft a Napoli; quest’anno l’evento era incentrato su Windows 10 e tutte le novità di Build 2015.

Da buon Microsoft MVP su Windows Embedded ed IoT, la mia sessione era ovviamente dedicata all’embedded ed all’Internet of Things ed in particolare alla Raspberry Pi 2 con Windows 10 IoT Core.

Ovviamente, in una soluzione IoT non può mancare il Cloud con i suoi servizi e nel mio caso non poteva mancare l’Azure Event Hubs come destinazione dei dati (temperatura) trasmessi dalla Raspberry Pi 2 (utilizzando la mia libreria Azure SB Lite).

Per chi fosse interessato, il materiale è disponibile su SlideShare (slide) e su GitHub (il codice sorgente della demo).

M2Mqtt su una Raspberry Pi con il progetto Mono

Un nuovo use case per la libreria M2Mqtt !! La sezione dei case studies sul sito ufficiale si è arricchita con un altro grande esempio !

Jon Gallant, parte del Microsoft IoT maker team, ha scritto un interessantissimo articolo relativamente alla sua “esperienza da maker” con una demo sull’utilizzo del protocollo MQTT su una Raspberry Pi. Jon ha deciso di non utilizzare le librerie native C/C++ ma il linguaggio C# e quindi la libreria M2Mqtt grazie al progetto Mono !

L’articolo descrive tutti i passi per mettere in piedi l’intera demo dall’hardware fino all’installazione di Mono sulla Raspberry Pi ed all’esecuzione della relativa applicazione.

E’ bello vedere un ulteriore esempio di utilizzo del client M2Mqtt…e questa volta in ambiente Linux !

Raspberry Pi e Windows Azure Service Bus via AMQP con la libreria Qpid Proton C

Nel corso di questa tutorial vedremo in che modo sia possibile utilizzare la Raspberry Pi come client AMQP (Advanced Message Queuing Protocol) e collegarla al Windows Azure Service Bus che supporta la versione AMQP 1.0.

Ovviamente, la scelta della libreria client da utilizzare è quasi obbligata : Apache Qpid Proton. Tale libreria sviluppata in C fornisce comunque il bindings per altri linguaggi tra cui Java, Python e PHP ma nel corso dell’articolo utilizzeremo solo la versione nativa.

Generalmente, la Raspberry Pi viene utilizzata con la distribuzione Raspbian (basata su Debian) che è a tutti gli effetti una distribuzione Linux. Ciò vuol dire che possiamo installare la libreria Qpid Proton come faremo su un normale distribuzione Ubuntu su un PC oppure su una macchina virtuale ad esempio su Windows Azure.

Connessione alla Raspberry Pi

Tutte le operazioni che seguono possono essere effettuate accedendo direttamente alla Raspberry Pi attraverso un monitor, una tastiera ed un mouse collegati ad essa oppure in remoto attraverso l’utilizzo di SSH.

La seconda soluzione è sicuramente la più comoda, utilizzado un tool come Putty e specificando l’indirizzo IP della nostra board, la porta (tipicamente la 22) ed il tipo di connessione (SSH).



Installazione dei prerequisiti

Una volta effettuato l’accesso, in primo luogo bisogna installare dei componenti fondamentali tra cui GCC, CMAKE (sistema di build utilizzato da Qpid) e la libreria UUID per la generazione di identificativi univoci.

sudo apt-get install gcc cmake uuid-dev

Poichè Qpid utilizza SSL e il Service Bus necessita di questo prerequisito per la connessione, dobbiamo installare OpenSSL nel nostro sistema (che in realtà potrebbe essere già installato).

sudo apt-get install openssl

La presenza della libreria OpenSSL non include la presenza degli header file e delle librerie statiche necessarie per lo sviluppo. Bisogna quindi installare la libssl-dev.

sudo apt-get install libssl-dev

Non essendo interessato ad alcun binding con altri linguaggi, possiamo evitare di installare i package per Python, PHP e così via, passando direttamente al download della libreria dal sito ufficiale. Inoltre, non installiamo le dipendenze che riguardano la generazione automatica della documentazione.

Download e compilazione della Qpid Proton

Dal sito ufficiale possiamo ricavare uno dei mirror da cui scaricare la libreria nella sezione “Download” per poi scaricarla usando il tool WGET.

pi@raspberrypi ~ $ wget http://apache.fastbull.org/qpid/proton/0.6/qpid-proton-0.6.tar.gz
–2014-04-16 07:09:52–  http://apache.fastbull.org/qpid/proton/0.6/qpid-proton-0.6.tar.gz
Resolving apache.fastbull.org (apache.fastbull.org)…
Connecting to apache.fastbull.org (apache.fastbull.org)||:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 629147 (614K) [application/x-gzip]
Saving to: `qpid-proton-0.6.tar.gz’

100%[======================================>] 629,147     1.00M/s   in 0.6s

2014-04-16 07:09:53 (1.00 MB/s) – `qpid-proton-0.6.tar.gz’ saved [629147/629147]

Dopo il download. estraiamo il contenuto del file.

tar xvfz qpid-proton-0.6.tar.gz

Entriamo nella cartella appena create (qpid-proton-0.6) e creiamo una cartella “build” in cui faremo generare dal tool CMAKE il corrispondente Makefile per la compilazione della libreria.

mkdir build

cd build


L’output del comando cmake dovrebbe essere il seguente.

pi@raspberrypi ~/qpid-proton-0.6/build $ cmake -DCMAKE_INSTALL_PREFIX=/usr ..
— The C compiler identification is GNU 4.6.3
— Check for working C compiler: /usr/bin/gcc
— Check for working C compiler: /usr/bin/gcc — works
— Detecting C compiler ABI info
— Detecting C compiler ABI info – done
— Found Java: /usr/bin/java
— Java version: javac is at: /usr/bin/javac
— Won’t build proton-j-impl because one or more Bouncycastle jars were not found. PROTON_JAR_DEPEND_DIR was: /usr/share/java
— Found OpenSSL: /usr/lib/arm-linux-gnueabihf/libssl.so;/usr/lib/arm-linux-gnueabihf/libcrypto.so (found version “1.0.1e”)
— Looking for clock_gettime
— Looking for clock_gettime – not found.
— Looking for clock_gettime in rt
— Looking for clock_gettime in rt – found
— Looking for uuid_generate
— Looking for uuid_generate – not found.
— Looking for uuid_generate in uuid
— Looking for uuid_generate in uuid – found
— Looking for strerror_r
— Looking for strerror_r – found
— Looking for atoll
— Looking for atoll – found
— Could NOT find SWIG (missing:  SWIG_EXECUTABLE SWIG_DIR)
— Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE)
— Looking for include file inttypes.h
— Looking for include file inttypes.h – found
— Can’t locate the valgrind command; no run-time error detection
— Cannot find rspec, skipping rspec tests
— Cannot find both Java and Maven: testing disabled for Proton-J and JNI Bindings
— Configuring done
— Generating done
— Build files have been written to: /home/pi/qpid-proton-0.6/build

Ci sono alcuni warning sull’impossibilità di trovare il runtime Java, Swig e Doxygen. Come già anticipato, non siamo interessato al binding con altri linguaggi ed alla generazione automatica della documentazione per cui possiamo non preoccuparci di tali warning.

L’ultimo step consiste nell’utilizzare il tool MAKE per elaborare il Makefile appena generato da cmake ed installare la libreria nel sistema.

sudo make install

Al termine della compilazione, la libreria è installata nel sistema in corrispondenza della cartella /usr (come specificato nel primo comando CMAKE eseguito) ed in particolare :

  • /usr/share/proton : contiene un esempio di utilizzo;

  • /usr/bin e /usr/lib : contengono i file relativi la libreria vera e propria;

  • /usr/include/proton : contiene gli header file necessari per lo sviluppo di un’applicazione;

Esempio di invio e ricezione su Service Bus

Per poter testare il corretto funzionamento della libreria utilizziamo i semplici esempi di send e receive distribuiti con la libreria stessa durante l’installazione.

cd /usr/share/proton/examples/messenger/

Anche in questo caso possiamo sfruttare il tool CMAKE per la generazione del Makefile necessario alla compilazione (da notare che è necessario l’esecuzione come Super User).

sudo mkdir build

cd build

sudo cmake ..

sudo make all

Al termine della compilazione avremo i due file eseguibili recv e send corrispondenti a due semplici applicativi che permettono di ricevere ed inviare messaggi ad una coda via AMQP.

Per fare questo, creiamo un nuovo namespace per il Service Bus sul portale di Microsoft Azure ed in corrispondenza di questo anche una queue. Nel mio caso, il namespace è qpidproton.servicebus.windows.net e la coda banalmente “myqueue”. Attraverso il portale dobbiamo ricavare due parametri fondamentali per la connessione che sono lo SharedSecretIssuer (tipicamente “owner”) e lo SharedSecretValue.


L’indirizzo per la connessione al Service Bus avrà la seguente struttura :


Poichè il Service Bus usa le connessioni SSL, dobbiamo utilizzare AMQPS in luogo del semplice AMQP.

Per inviare un messaggio con testo “Hello” alla queue dobbiamo eseguire l’applicazione send nel modo seguente.

./send –a amqps://username:password@namespace.servicebus.windows.net/queue_name Hello

Per poter ricevere un messaggio dalla stessa queue possiamo utilizzare l’applicazione recv nel modo seguente.

./recv amqps://username:password@namespace.servicebus.windows.net/queue_name

Con un risultato di questo tipo.

Address: amqps://username:password@namespace.servicebus.windows.net/queue_name
Subject: (no subject)
Content: “Hello”

Hai una Raspberry Pi ? Ti serve assolutamente questo libro !


Questo post è ben diverso da quelli che generalmente scrivo sul mio blog, soprattutto in relazione al fatto che si tratta di una mini recensione al primo libro (spero di una lunga serie) appena pubblicato da un mio carissimo amico, quale è Valter Minute (MVP Microsoft per Windows Embedded).

Qualche mese fa, il caro Valter mi propone di fare da “cavia” per un suo progetto in corso d’opera; io ovviamente accetto senza pensarci su due volte, ritrovandomi a leggere in anteprima i capitoli del libro “Raspberry Pi – Guida all’uso” (Edizioni FAG Milano), per poter proporre ulteriori spunti e carpire eventuali errori (di testo, non di certo di contenuto ben conoscendo l’autore).

I libro è per i neofiti che si avvicinano al mondo dei makers o che vogliono realizzare in casa un proprio centro multimediale ma anche per utenti più avanzati che vogliono ottenere il massimo dalla loro Raspberry Pi. Sono affrontati tutti gli argomenti necessari per poter prendere a pieno il controllo dell’oggetto, dall’installazione del sistema operativo alla relativa configurazione, dalla programmazione in Python alla connessione del dispositivo al Cloud per assaggiare l’Internet Of Things.

Voglio solo aggiungere che per la Raspberry Pi sono disponibili anche una BSP Windows CEin versione alpha ed in corso di sviluppo da parte di Douglas Boling, così come un supporto per il .Net Micro Framework, che purtroppo non ho avuto ancora modo di sperimentare.

L’autore è sicuramente una garanzia, considerando la sua enorme esperienza nel mondo embedded sotto tutti i punti di vista e relativamente a tutti i prodotti da Windows CE a Linux ed Android.

Ieri ho ricevuto ne ho ricevuto una copia in omaggio (che rileggerò ovviamente), scoprendo anche che Valter ha riservato qualche preziosa parola nei miei confronti per l’aiuto dato; ovviamente ho fatto tutto con estremo piacere per un professionista che ho sempre considerato un punto di riferimento nel mondo dello sviluppo embedded. Dai forum su MSDN al corso su Windows CE 6.0 che ho seguito (di cui lui era ovviamente il “docente”), ne ho apprezzato l’elevatissimo livello di compentene … bisogna farne di strada per essere come lui !

Per me è quasi un idolo !!

Ovviamente, non mi resta che dire … accattatevillo !!! (parafrasando una famosa pubblicità)

Tradotto dal mio dialetto … correte subito ad acquistarlo oppure fatelo comodamente da casa, eccovi il link al sito ufficiale !!