2 April 2011: for various reasons not much has happened in the way of new albums, but today I finally had a KAP opportunity again! The weather wasn't optimal but I got a couple of nice photos nonetheless.

May 2010: check out my new and awesome Kite Aerial Photography photo gallery, made when on holiday on the island of Vlieland.

February 2010: started 'The Daily Snapshot' photo galleries. The intention is to take and publish one photograph, every day. The subject can be anything and everything. I'm usually only packing a small camera and the photographs will be made 'as I go along' - hence the 'snapshot' qualifier .

Introduction

The Voltcraft CO-100 displays temperature, relative humidity and CO2 levels in the house. It has adjustable alarm levels for CO2 which, when exceeded, illuminate an orange or red LED on the front and optionally a beep alarm. It also has a datalogger that keeps historic data for 24 hours.

But what's the use of a datalogger if you have to be near the device and press some buttons to see the values?

I decided to look into the possibilities of reading the data directly from the device and store it in my Domoticz home domotica system so that the history would be available online in graph form.

For years I've enjoyed the features and possibilities of professional-grade (i.e. expensive) message-based software in my day to day work. So I was very happy to learn that similar software, albeit with fewer feautures, is available for use in the hobbyist area. I am talking about MQTT, "a lightweight messaging protocol for small sensors and mobile devices, optimized for high-latency or unreliable networks".

MQTT is not exactly new, having been around since 1999, but what makes it very attractive now is the proliferation of small, low cost devices running some form of Linux/Android etc. Libraries are available for many popular programming languages - in this article I'll use the Paho library for Python and I'll talk to the Mosquitto MQTT broker.

MQTT is described as a publish/subscribe message pattern: a client connects to a central message server ('broker'), publishes a message to a topic without knowing who is subscribing to that topic, and then leaves the topic without waiting for an answer. This pattern can be used for example by a remote temperature sensor, publishing its own name and the temperature it measured on a topic where a home automation system (e.g. Domoticz) picks it up for display to a user.

In contrast, the request/response (or request/reply) message pattern is one where a client contacts a remote service with a request and waits for the service to return with an answer. For example: software like Domoticz uses a request/response pattern to obtain weather information from the Weather Undergound website.

Many request/response services are implemented synchronously: while the client is waiting for an answer from the service it's not doing anything else. For example: when your browser requests a website from a server it waits and shows some kind of hour glass or spinner picture while the site loads. When implementing request/reply with a message broker like MQTT, the client can be programmed in such a way that it publishes its request, then goes off doing other stuff while 'simultaneously' waiting for the reply to come back from the service. This is convenient and economic for small devices with few resources, doing a lot of things.

It is possible, and indeed not very difficult, to write a request/response service for MQTT. The examples below were made with the following setup:

Raspberry Pi (two actually, but it's perfectly fine to run the MQTT broker, the client and the service on a single device)

This article will be in the form of sections describing particular aspects of the provisioning/installation/configuration process of a new BeagleBone Black (BBB from now, for short). I wrote this for people who feel comfortable working on the Linux command line, using the root account. If you're not then you can accept the challenge, go for it and learn something, or not.

Last week I bought my third Raspberry Pi, it is going to host a new Nestcam server. My other two Pis are running XBMC [Kodi] and Domoticz and because both of those were provisioned a 'long' time ago I had to go back and figure out how I configured them.

With the inevitable (re)provisioning in the future I decided to make a list of configuration actions I performed so I don't have to look them up anymore.

The steps below lead to a lean Raspberry Pi server, without Xorg and related desktop applications, running Raspbian Wheezy, motion and nginx.