Pale blue cloud  



Raspberry Pi

Request-response message exchange with MQTT and Python


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)
  • Python 3
  • Paho MQTT class for Python

Read more: Request-response message exchange with MQTT and Python

Provisioning a new Raspberry Pi


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.

Read more: Provisioning a new Raspberry Pi

Workaround for RPi's USB webcam problem


Many people have reported problems with their USB webcams on the Raspberry Pi on various forums. The symptom is that the webcam software 'hangs' after shorter or longer periods of time. When the software is restarted everything is fine again, until the next lock-up.

My RPi exhibits this problem as well. When it occurs, the following message is printed to /var/log/messages:

raspberrypi kernel: [1354871.530013] uvcvideo: Non-zero status (-5) in video completion handler.

And then the webcam stream (created by motion) stops.

This is accompanied by the system load going from normal levels (~ 0.10) to 1, and staying there until motion is restarted:

High load on RPi

My first attempt on a work-around was a Perl script that continuously 'tailed' /var/log/messages, waiting for the above error message to occur and then restart motion. It didn't work well.

Read more: Workaround for RPi's USB webcam problem

Raspberry Pi motion detection with Zilog ePIR


This is a quick write-up on how to use the Zilog ePIR motion detector with a Raspberry Pi. The article illustrates how to connect the ePIR to the RPi's GPIO pins and how to make its motion detection operation visible by controlling an external LED using a script.

Sources are provided for background information.

Serial port configuration

Disable serial port login and prevent boot log data from being sent to the console. This is so we can use the serial interface, ttyAMA0, to communicate with the ePIR.

The following commands are executed as root.

  1. Edit /etc/inittab and comment out the line thay says T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
  2. Edit /boot/cmdline.txt and remove the bit that says console=ttyAMA0,115200 kgdboc=ttyAMA0,115200.
  3. Reboot the Raspberry Pi with shutdown -r now.


Hook-up Zilog ePIR sensor

Connect the Zilog ePIR sensor to the Raspberry Pi according to the table below. This will configure the ePIR to run in serial interface mode. I am using Adafruit's Pi Cobbler, a convenient breakout board that sits on top of a mini bread board.

Read more: Raspberry Pi motion detection with Zilog ePIR

Raspberry Pi data logging


I like logging data. I've always liked logging data. As a kid I used to keep track of barometric pressure and make graphs of it. For months on end, listening to Amsterdam VOLMET every morning an{jcomments on}d evening.

And now it's easier than ever before to log data (and display it) with Raspberry Pis, Arduinos and whatnot, all being easily connected to 'the cloud' for storing and sharing data. The Internet of Things.

I wanted a simple logger for my Raspberry Pi, which is online and hosting a webcam and a webserver. The requirements are simple:

  • log CPU load, CPU temperature, bytes in, bytes out
  • show the data in graph form
  • because the data is not valuable it's ok to store it somewhere 'in the cloud'

Read more: Raspberry Pi data logging

© Palebluedot