Tiny MQTT Broker with OpenWRT

This post may contain affiliate links. Please see the disclaimer for more information.

So yet again I’ve been really lax at posting, but meh. I’ve still been working on various projects aimed at home automation – this post is a taster of where I’m going…

MQTT (for those that haven’t heard about it) is a real time, lightweight, publish/subscribe protocol for telemetry based applications (i.e. sensors). It’s been described as “RSS for the Internet of Things” (a rather poor description in my opinion).

The central part of MQTT is the broker: clients connect to brokers in order to publish data and receive data in feeds to which they are subscribed. Multiple brokers can be fused together in a heirarchical structure, much like the mounting of filesystems in a unix-like system.

I’ve been considering using MQTT for the communication medium in my planned home automation/sensor network projects. I wanted to set up a heirarchical system with different brokers for different areas of the house, but hadn’t settled on a hardware platform. Until now…

…enter the TP-Link MR3020 ‘travel router’, which is much like the TL-WR703N which I’ve seen used in several hardware hacks recently:

It's a Tiny MQTT Broker!

It’s a Tiny MQTT Broker!

I had to ask a friend in Hong Kong to send me a couple of these (they aren’t available in NZ) – thanks Tony! (UPDATE 2019: Of course now you can get these shipped direct, something I didn’t know about in 2012). Once I received them installing OpenWRT was easy (basically just upload through the exisiting web UI, follow the instructions on the wiki page I linked to above). I then configured the wireless adapter in station mode so that it would connect to my existing wireless network and added a cheap 8GB flash drive to expand the available storage (the device only has 4MB of on-board flash, of which ~900KB is available after installing OpenWRT). I followed the OpenWRT USB storage howto for this and to my relief found that the on-board flash had enough space for the required drivers (phew!).

Once the hardware type stuff was sorted with the USB partitioned (1GB swap, 7GB /opt) and mounting on boot, I was able to install Mosquitto, the Open Source MQTT broker with the following command:

$ opkg install mosquitto -d opt

The -d option allows the package manager to install to a different destination, in this case /opt. Destinations are configured in /etc/opkg.conf.

It took a little bit of fiddling to get mosquitto to start at boot, mainly because of the custom install location. In the end I just edited the paths in /opt/etc/init.d/mosquitto to point to the correct locations (I changed the APP and CONF settings). I then symlinked the script to /etc/rc.d/S50mosquitto to start it at boot.

That’s about as far as I’ve got, apart from doing a quick test with mosquitto_pub/mosquitto_sub to test everything works. I haven’t tried mounting the broker under the master broker running on my home server yet.

The next job is to investigate the serial port on the device in order to attach an Arduino clone which I soldered up a while ago. That will be a story for another day, hopefully in the not-to-distant future!

If you liked this post and want to see more, please consider subscribing to the mailing list (below) or the RSS feed. You can also follow me on Twitter. If you want to show your appreciation, feel free to buy me a coffee.

Smartclock Prototype

So as promised here are the details and photos of the Arduino project I’ve been working on – a little late I know, but I’ve actually been concentrating on the project.

The project I’m working on is a clock, but as I mentioned before it’s not just any old clock. The clock is equipped with sensors for temperature, light level and battery level. It also has a bluetooth module for relaying this data back to my home server. This is the first part of a larger plan to build a home automation and sensor network around the house (and garden). It’s serving as kind of a test bed for some of the components I want to use as well as getting me started with the software.

Prototype breadboard

The prototype breadboard showing the Roving Networks RN-41 bluetooth module on the left and the sensors on the right. The temperature sensor (bottom middle) is a TMP36 and the light sensor is a simple voltage divider using a photocell.

As you can see from the photos this is a very basic prototype at the moment – although as of this weekend all the hardware is working as well as the software drivers. I just have the firmware to finalise before building the final unit.

Time display

The (very bright!) display showing the time. I’m using the Sparkfun 7-segment serial display, which I acquired via Nicegear. It’s a lovely display to work with!

The display is controlled via SPI and the input from the light sensor is used to turn off the display when it is dark in order to save power when there is no-one in the room. The display will also be able to be controlled from the server via a web interface.

Temperature display

The display showing the current temperature. The display switches between modes every 20 seconds with it’s default settings.

Careful readers will note the absence of a real time clock chip to keep accurate time. The time is kept using one of the timers on the ATmega328p. Yes, before you ask this isn’t brilliantly accurate (it loses about 30 seconds every hour!), but I am planning to sync the time from the server via the bluetooth connection, so I’m not concerned.

The final version of will use an Arduino Pro Mini 3.3v (which I also got from Nicegear) for the brains, along with the peripherals shown. The Duemilanove shown is just easier for prototyping (although it makes interfacing with the RN-41 a little more difficult).

I intend to publish all the code (both for the firmware and the server) and schematics under Open Source licences as well as another couple of blog posts on the subject (probably one on the final build with photos and one on the server). However, that’s it for now.

Quick Update…

Well, I’ve not been doing great with posting more, especially on the quick short posts front. I guess it’s because I’m either too busy all the time or because I just don’t think anyone wants to read every last thought which pops into my head. Probably a bit of both!

Anyway, here’s a quick run-down of what I’ve been up to over the past couple of weeks:

  • I’ve been working on an Arduino project at home. I’ll post more on this over the weekend (with photos). For now I’ll just say that it’s a clock with some sensors on it – but it does a little more than your average clock. Although I’ve had my Arduino for a couple of years I’ve never really used it in earnest and I’m finding it refreshing to work with. Since I use PICs at work the simpler architecture is nice. Of course I program it in C so I can’t comment on the IDE/language provided by the Arduino tools.
  • The beer which I made recently is now bottled and maturing. It’ll need a couple more weeks to be ready to drink though (actually the longer the better really, but I can never wait!). I’ll report back on what it’s like when I try it.
  • I’ve been thinking about ways to get the ton of data I have spread across my machines in order. Basically I want to get it all onto my mythbox/home server/personal cloud and acessible via ownCloud and NFS. I also have a ton of dead tree (read ‘important’ documents) which need scanning and a ton of CDRs that need backing up. After that I have to overhaul my backup scheme. It’s a big job – hence why I’ve only been thinking about doing it so far.
  • I’ve also been thinking about upgrading my security with the recent hacks which have occured. Since I’m not hugely reliant on external services (i.e. Google, Facebook, Apple and Amazon) I’m doing pretty well already. Also, I already encrypt all my computers anyway (which is way more effective than that stupid ‘remote wipe’ misfeature Apple have). I am considering upgrading to two factor authentication using Google Authenticator anywhere I can and I want to switch to using GPG subkeys and storing my master private key somewhere REALLY secure. I’ll be writing about these as I do them so stay tuned.

Well, hopefully that’s a quick summary of what I’ve been up to (tech-wise) lately as well as what might be to come in these pages. For now, that’s all folks.

Simple password management with Bash and GPG

A while ago I was looking for a password management solution that I could trust, so of course being as paranoid as I am I decided to write my own. Now I’ve decided to share what I came up with.

My system takes the form of two bash functions which inhabit my .bashrc file. First is a password generation function:

# function to generate a new password and add it to the secure file
# also copies the new password to the clipboard
# clipboard is cleared automatically after 10 seconds
pwg()
{
    CB=$(xclip -selection clipboard -out)
    gpg --decrypt $HOME/secure.txt.gpg > $HOME/secure.txt
    PW=$(pwgen -n 12 1)
    echo "$PW   $1" >> $HOME/secure.txt
    gpg --encrypt --recipient $MY_EMAIL $HOME/secure.txt
    rm $HOME/secure.txt

    echo $PW | xclip -selection clipboard
    echo
    echo "New password copied to clipboard!"
    echo "You have 10 seconds..."
    sleep 10
    echo $CB | xclip -selection clipboard
}

This generates a 12 character alphanumeric password using pwgen and appends it to my password file along with a user supplied token (which is later used to retrieve the password. The password file is a tab separated file stored in the the home directory and encrypted with GPG. The password is copied to the clipboard with the xclip tool, where it stays for ten seconds before being wiped.

The second part of the system is a function to retrieve the password:

# function to retrieve a password from the secure file and copy it to the clipboard
# clipboard is cleared automatically after 10 seconds
pw()
{
    CB=$(xclip -selection clipboard -out)
    gpg --decrypt $HOME/secure.txt.gpg | grep $1 | cut -f1 | xclip -selection clipboard
    echo
    echo "Password copied to clipboard!"
    echo "You have 10 seconds..."
    sleep 10
    echo $CB | xclip -selection clipboard
}

This function grabs the password from the secure file and again copies it to the clipboard ready to be pasted to wherever it is needed. Again the clipboard is cleared after ten seconds to prevent passwords hanging around to long.

To use these function just place them in your .bashrc file along with a definition of the MY_EMAIL variable (to allow GPG to find your key) and then source the file (or restart bash). Obviously you’ll need GPG, pwgen and xclip which on Fedora can be installed with:

$ sudo yum install gnupg pwgen xclip

Usage is very simple, just run each function in a terminal with an identification token as the argument:

$ pwg test

<GPG PROMPTS FOR PASSPHRASE>

File `secure.txt.gpg` exists. Overwrite? (y/N) y

New password copied to clipboard!
You have 10 seconds...
[robert@riker ~]$ pw test

<GPG PROMPTS FOR PASSPHRASE>

Password copied to clipboard!
You have 10 seconds...

That’s it! Feel free to give it a try. Improvments are most welcome, so please post them in the comments section.

Installing Fedora 15 via boot.fedoraproject.org…

I recently decided it was time to upgrade my home desktop machine from Fedora 14 to Fedora 15. Since I generally tend to do a clean install rather than an in place upgrade and because I’ve recently acquired a much better internet connection, I decided to try out the Fedora boot server – boot.fedoraproject.org (BFO). BFO is a service that allows you to boot your computer directly into the Fedora installer over the internet. I think it uses gPXE/Etherboot under the hood, although I didn’t have to touch these directly. The following is a brief review of the service based on my experiences. Unfortunately, I didn’t have time to work out how to take screenshots from BFO so I don’t have any pretty pictures :-(.

I started out by visiting the BFO website and doing a bit of reading. The downloads page doesn’t really give you much info on how to proceed with BFO, so it’s best to check out the FAQ. BFO can be accessed in one of two different ways.  You can either download a boot image for some physical media (CD/DVD, USB and Floppy (!) images are available), or you can boot BFO directly from GRUB. The physical media images are of course pretty tiny since you’re not downloading the whole distro, just enough stuff to boot from the network. However, one of the attractions of BFO for me was to do away with physical media all together and so I went for the GRUB option.

In order to boot BFO via GRUB you obviously need to have GRUB installed as your bootloader. This shouldn’t be a problem if you are upgrading from an existing Linux install. To install BFO you run the following commands (as root) from the BFO FAQ:

wget -O/boot/bfo.lkrn http://serverbeach1.fedoraproject.org/pub/alt/bfo/bfo.lkrn
grubby --add-kernel=/boot/bfo.lkrn --title="Boot BFO"
reboot

This will add a new “Boot BFO” entry to your GRUB config and reboot your machine. Technically, you probably don’t want to reboot immediately since you should check that you have a decent length menu time out for GRUB (edit the ‘timeout’ line in /etc/grub.conf and run the ‘grub’ command afterwards).

Once I had completed these steps and rebooted, I was able to access the GRUB menu by pressing ESC. I then selected the new menu entry and proceeded to boot BFO. At first I got an error because my machine couldn’t get an IP address from the router. I had suspected this would happen since I don’t have the ethernet plugged in and these things usually don’t like wifi. I went searching for my long ethernet cable and everything worked on the second try. After a bit of loading (presumably downloading stuff) I was presented with another boot menu, which asked me what I wanted to boot. I selected the Fedora 15 x86_64 installer. BFO then started loading the kernel and initrd images for this (it took a while).

Once the installer booted up it was very much like the normal Fedora installer (in fact it is). I was able to go through all the usual stuff like partitioning, etc. Once nice feature of this installer is the package selection screen. This lets you install groups of packages (like ‘Games’ or ‘Software Development’) as well as individual packages. I can only think that this is a feature of the full Fedora DVD installer which is why I haven’t seen it before (I’ve only installed from Live CD previously). Happily, it enables you to get a much more functional system out of the box rather than the fairly bare Live CD install (for example it installed LibreOffice by default).

Once I’d finished making my package selections the installer started formatting the drives and installing packages. This was significantly slower than the Live CD install since it had to download and install each package separately (rather than the disk-dump approach taken by the Live CD installer). Once this was complete I rebooted and filled in my user details. I then had a fully functioning Fedora 15 install.

My Verdict:

My experience with BFO has been overwhelmingly positive. The install is significantly slower than a Live CD install, but when you factor in all the time that is saved by not downloading an burning (and reburning!) ISO images it’s probably about the same. Everything worked perfectly for me. except the previously mentioned wifi/ethernet issue which was more my fault than a BFO problem. The only improvement I could suggest is that the commands I mentioned above could be wrapped up into an RPM package and made available in the Fedora repository so they are available for everyone very easily. This would make the whole system very polished and easy to use.

Overall, I would highly recommend using BFO for your next Fedora install. It really beats any other install method I’ve used to date.