Getting Really Small Message Broker running in Azure

by Mike Linnen 1. June 2012 23:34

In my previous post I talked about changing my home automation messaging infrastructure over to MQTT.  One of my goals was to also be able to remotely control devices in my house from my phone while I am not in my home.  The good news is that this is easily done by setting up a bridge between two brokers.  My on-premise broker is configured to connect to the off-premise broker as a bridge.  This allows me to publish and subscribe to topics on the off-premise broker which in turn get relayed to the on-premise broker. Well we need to host the off-premise broker somewhere and that somewhere can be an Azure worker role.

Really Small Message Broker (RSMB)  for windows is simply a console application that can be launched in a Worker Role.  In this blog post I will be showing you how to do just that.  One thing to note here is make sure you read the License agreement of RSMB before you use this application for your purposes.

Of course to actually publish this to Azure you will need to have an Azure account but this will also run under the emulator.  If you don’t have the tools to build windows azure applications head on over to the Windows Azure Developer portal  and check out the .Net section to get the SDK bits.  Also the following instructions assume you have downloaded RSMB and installed it onto your windows machine.

Create a new Cloud Windows Azure Project


Once you press the Ok button you will be asked what types of roles you want in the new project.  Just select a Worker Role and add it to the solution.


To make things easier rename the role as I have done below.


After selecting the Ok button you need to set up an endpoint for the worker role that will be exposed through the load balancer for clients to connect to.  Select the worker role and view the properties of the role.  Select the Endpoints tab and add a new endpoint with the following settings:

  • Name: WorkerIn
  • Type:
  • Protocol: tcp
  • Public Port: 1883


Add a new folder under the RSMBWorkerRole project called rsmb


Copy the following RSMB files to the new folder and add them to the RSMBWorkerRole project with Copy to Output Directory set to Copy Always

  • rsmb_1.2.0\windows\broker.exe
  • rsmb_1.2.0\windows\mqttv3c.dll
  • rsmb_1.2.0\windows\mqttv3c.lib
  • rsmb_1.2.0\messages\Messages.1.2.0


Add a class level declaration as follows:

Process _program = new Process();

Make sure you have a using statement for at the top of the class.

using System.IO;

Add code to the OnStart Method as follows:

public override bool OnStart()
    // Set the maximum number of concurrent connections
    ServicePointManager.DefaultConnectionLimit = 12;

    string rsbroot = Path.Combine(Environment.GetEnvironmentVariable("RoleRoot") + @"\\", @"approot\\rsmb");
    int port = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["WorkerIn"].IPEndpoint.Port;

    ProcessStartInfo pInfo = new ProcessStartInfo(Path.Combine(rsbroot, @"broker.exe"))
        UseShellExecute = false,
        WorkingDirectory = rsbroot,
        ErrorDialog = false,
        CreateNoWindow = true,
    _program.StartInfo = pInfo;

    return true;

You should be able to launch the project under the Azure emulator and then use an MQTT client to connect to a topic like $SYS/# and the client should connect without error and start receiving notifications for the published messages.  If you need to setup some additional broker configurations such as the broker.cfg then just add it to the project under the rsmb folder and make sure it is set to copy to the output directory always.  You might want to enhance the code in the OnStart method to redirect output of the RSMB console to the azure diagnostics to make troubleshooting issues easier.  You also need to setup the on-premise broker to connect to the remote broker as a bridge.  The instructions to set up the local broker as a bridge can be found in the README.htm where you installed RSMB.

Switching out my home automation messaging infrastructure for MQTT

by Mike Linnen 1. June 2012 21:09

I am re-vamping my home automation strategy from a home grown publish/subscribe messaging system to use MQTT instead.  I was using Azure Service Bus to connect remote devices such as my phone with devices in my home such as my lawn irrigation system.  This worked well as a messaging infrastructure for remote devices but I wanted to have a more standard messaging infrastructure that could work in my home network without connectivity to the outside world. 

A few reasons why I switched to MQTT:

  • Light weight
  • Many Clients already exist for many platforms and languages
  • Support for on-premise message broker
  • Support for off-premise message broker
  • Support for bridging brokers (on-premise to off-premise)
  • Fast
  • Used by companies like COSM (was Pachube) and Github
  • Simple topic subscription model that is also powerful
  • I don’t want to write a message broker

For the most part I am moving toward having devices in the home that are relatively dumb and having services running on a home server that add the smarts behind the devices.  This will give me the flexibility to change the behavior of the system a lot quicker without the hassle of tearing apart a device to upgrade the software on it.  This means I needed to have my services available all the time.  Placing these services in the cloud for mission critical things would mean I am left with devices in the home that cannot function while my internet connectivity is down.  This was the biggest reason I moved to an off the self pub/sub infrastructure like MQTT.

Like most messaging protocols, MQTT works on the notion of a topic and a message.  The topic is just a unique way of addressing a message.  I struggled a lot and I probably will continue to struggle on what my topic structure for my home automation should look like.  One thing I wanted to do is try to make the topics readable so that troubleshooting message problems would be easier.  Hear are a few standards I am trying to settle on:

  • When a device or service changes state and wishes to notify interested parties the topic will end with /event 
  • When a device or service wants to know the status of another device or service the topic will end with /getstatus
  • When a device or service receives a topic /getstatus the response topic it generates will end with /status
  • When a device or service needs to set the state of another device or service the topic will end with /set

Here are a few examples of topics and messages for my irrigation system:

Description Topic Message
Zone 1 turned on irrigation/zone/event z1 On
Request the current schedule from the irrigation service. The service will respond to this request by publishing various status topics irrigation/schedule/getstatus  
Set the time that the irrigation service should start watering irrigation/schedule/starttime/set 09:00 AM
Status of the schedule start time in response to the getstatus request irrigation/schedule/starttime/status 09:00 AM
Set the days of the week that the irrigation system will water irrigation/schedule/days/set MON WED FRI
Status of the scheduled days of the week in response to the getstatus request irrigation/schedule/days/status MON WED FRI
Set the zones that the irrigation system will run and how long irrigation/schedule/zones/set z1 10 z2 8 z3 10
Status of the scheduled zones in response to the getstatus request irrigation/schedule/zones/status z1 10 z2 8 z3 10
Sets the zones to run on the irrigation device and how long irrigation/zones/run z1 10 z2 8 z3 10

MQTT does have a concept of publishing messages with a retain bit. This just tells the broker to hang onto the last message for a topic and when a new subscription arrives the client will receive the last message.  I could have used this concept instead of the /getstatus standard that I have show above.  I might change over to using the retain bit but for now the /getstatus works for me. I am also making my messages a little verbose as they tend to contain multiple values that could have been broken down into more granular topics.

Overall I really like how simple MQTT is and it is very easy to get a device like the Netduino to understand MQTT messages.  I am sure I will make modifications on how I actually define my topics and message body over time as I develop more and more devices and services that do useful stuf in my home.    

About the author

Mike Linnen

Software Engineer specializing in Microsoft Technologies

Month List