So I've been playing with bridging in mosquitto and wanted to share my experiences.

I tried this a while ago and failed mainly because I tried to set it all up at once and had problems with SSL and gave up.

This time I'm splitting it into three sections

1 Get Bridging working on open default install unsecured brokers.

2 Add password protection

3 Add TSL/SSL encryption

So the rest of this document is some notes on the first task, getting bridging working.

Iv'e been working on setting up a bridge from a local mosquitto broker to a remote mosquitto broker. To do this I configured the local broker to set up a bridge with the remote broker. As I'm writing this I'm using Mosquitto version 1.4.4.

So to get started with bridging I used some resources I found online, so I suggest you start there as well.

OwnTracks Booklet - Bridging

Securing MQTT communication between Ardruino and Mosquitto

mosquitto.conf documentation

When setting up bridging my advice is to set the log level to Debug on both brokers and read the logs often.

log conf section

log_dest file /var/log/mosquitto/mosquitto.log
log_type debug

sudo cat /var/log/mosquitto/mosquitto.log or even sudo cat /var/log/mosquitto/mosquitto.log | grep SUBSCRIBE and unless you have a massive amount of traffic on your brokers mosquitto_sub -t "#" -v is really useful for debugging as well.

Because I found that no matter how you interpret what you read on topic mapping it won't work like you think it should and some amount of digging and testing will be required to get the hang of it.

For example

The following topic patterns

topic inbound/# in alpha/ beta/
topic outbound/# out harry/ larry/
topic duplex/# both ying/ yang/

Result in the following subscriptions on the broker from the logs

1447053408: Bridge **** doing local SUBSCRIBE on topic larry/outbound/#
1447053408: Bridge **** doing local SUBSCRIBE on topic yang/duplex/#
1447053408: Bridge **** sending SUBSCRIBE (Mid: 38, Topic: inbound/#, QoS: 0)
1447053408: Bridge **** sending UNSUBSCRIBE (Mid: 39, Topic: outbound/#)
1447053408: Bridge **** sending SUBSCRIBE (Mid: 40, Topic: duplex/#, QoS: 0)

Which is nothing like what the documentation indicate, YMMV

For example the documentation states.

"For incoming topics, the bridge will prepend the pattern with the remote prefix and subscribe to the resulting topic on the remote broker. When a matching incoming message is received, the remote prefix will be removed from the topic and then the local prefix added."

And in my testing the remote prefix is not prepended to the pattern so its just the pattern that is the topic name and the incoming message has the remote prefix added not the local. e.g.

remote publish: mosquitto_pub -t "inbound" -m "foo"
local subscription receives: beta/inbound foo

and for outgoing the documentation states

"For outgoing topics, the bridge will prepend the pattern with the local prefix and subscribe to the resulting topic on the local broker. When an outgoing message is processed, the local prefix will be removed from the topic then the remote prefix added."

and in my testing the local topic is actually the remote prefix followed by the pattern and on the remote broker its published with just the pattern as the topic.

local publish: mosquitto_pub -t "larry/outbound" -m "foo"
remote subscription receives: outbound foo

So while mosquito bridging does work and is awesome I've found it's not necessarily working as advertised and so the best solution is digging around in the logs and testing things out with wildcard subscriptions.


YMMV Your millage may vary. Perhaps I'm missing something with the topic mapping and there's a good reason it's behaving as it is. In any case it's working and usable and can be made to do what you need to do once you figure out where your topics are going to.

Good luck.



I've been playing with Ansible and recently had it installing Mosquitto.

It's a bit too trivial at the moment to turn into a fully fledged Ansible roll so I've just put a Gist here.

It's only three tasks

# install mqtt broker
  - name: add mosquitto key
    apt_key: url= state=present
  - name: add mosquitto repo
    apt_repository: repo='deb wheezy main' state=present update_cache=yes
  - name: install mosquitto
    apt: name=mosquitto state=present




So it turns out it didn't work so well and after a day or two lifx-http becomes unresponsive. Also shortly after working on this LIFX 2.0 came out, breaking the current lifx-gem and introducing a cloud based http based API. I've since moved to using the lifx cloud API. Although I'm still interested in local non cloud communication with the LIFX bulbs.

Original article below

So I'm not a Ruby guy at all. My only current interest in Ruby is that the LIFX SDK and the LIFX HTTP API is written in Ruby.

The one other thing I'm doing in Ruby (without actually bothering to learn much Ruby outside of Stack Exchange driven development) is writing a bidirectional LIFX-MQTT bridge.

So I was playing around with trying to get Supervisor to run LIFX-HTTP. At some point I decided to upgrade my Ruby gems. Big mistake, this broke LIFX-HHTP and has lead me down a rabbit hole of Ruby gem version/dependancy management and the Ruby Version Manager (RVM).

Months ago when I was looking around to upgrade Ruby to version 2.0+ so i could run the LIFX gem I came across this page.

Ruby on Raspberry Pi

It seemed like an easy way to install Ruby on the Pi so I used that and it's worked well.

After upgrading my gems I discovered that lifx-http wasn't working. After reading through the Git Hub issues pages and trying a few things to no avail I decided that Rack version 1.6.0 was not playing well with lifx-http so the idea was to use RVM to move back to Rack 1.5.2

Once I started trying to use RVM to switch gemsets I started getting the apparently infamous "RVM is not a function" error.

With a bit of google I discovered that source ~/.rvm/scripts/rvm fixes the problem on the Raspberry Pi (raspbian). Put it it your .bashrc so it's loaded on every new shell.

To make a long story short, I created and new gemset, installed lifx-http, it automatically installed rack 1.6.0 so I uninstalled it and manually installed rack 1.5.2.

Cool lifx-http working again, back to supervisor.

RVM uses wrapper scripts to load the correct environment, as I'm very new to RVM the wrapper generation syntax was confusing me.

rvm wrapper ruby@gemset [scope] [binary-name]

so I found the cheats way.

rvm repair wrappers

This generates wrappers for all the installed gems.

With lifx-http working again and having generated the wrappers its just a matter of creating a config for supervisor. Here's what worked for me.


So now I have lifx-http working under supervisor which is a great improvement over running it in a screen session.

lifx-http                        RUNNING    pid 3660, uptime 1 day, 5:06:12
wemo                             RUNNING    pid 2080, uptime 1 day, 5:44:22

Categories ,


So by default when booted into X Windows the Raspberry Pi will blank its screen after 10 minutes of inactivity.

This isn’t so good for museum exhibition machines that need to show content all day.

If you google on the topic of raspberry pi screen blanking you get about half a dozen different suggestions to fix it with settings changes in a bunch of different files.

Only one thing worked for me.

The highest ranked answer here disable-screen-blanking-in-x-windows-on-raspbian

Involves editing /etc/X11/xinit/xinitrc

and adding three xset commands

xset s off         # don't activate screensaver
xset -dpms         # disable DPMS (Energy Star) features.
xset s noblank     # don't blank the video device

The trick here is that xset might not be installed.

Try an xset command on the command line to see if xset in installed.

If it’s not installed you can install it with.

sudo apt-get install x11-xserver-utils



My protoyping board for SparkCore that Ive been working on is now available on Tindie

Available on Tindie now

Comes with female headers so you can easily attach and remove you core from the protoboard.

  • Each SparkCore pin is connected to the hole on either side, so you have one spot for each pin inside the prototyping area and one on the outside of the core for connecting to external components.
  • There are additional connected pins for GND, VIN & 3V3
  • Clear labelling on both sides
  • Mounting holes

SparkCore in photos not included for illustrative purposes only


← Older Newer →