A new wiki has been created, devoted to MQTT. If you want to share what you're doing with MQTT and how to do it, or want to find any of that out, head over to http://mqtt.org/wiki.

If you want to use MQTT for push in Android apps, you'll probably want to head over to Anton L's blog post How to Implement Push Notifications for Android. He has a sample Android app that uses the IBM Java library to implement push notifications using MQTT, as well as a web page solution to demo pushing notifications to your phone.

Thanks to help from Chris Procter, there are now rpm packages available for Fedora Linux. As these are the first rpm packages, there may be problems so please report back if you find any.

There are details on where to get the packages on the download page.

Users of other rpm based distributions are currently out of luck - the versions of sqlite that they provide are typically either too old or else don't have support for some required features compiled in.

Thanks to everybody else who got in touch about rpms as well!

This fixes an important bug that didn't get caught for 0.6 that can prevent old database versions being upgraded.

From 0.7 onwards, mosquitto will be using release candidates to ensure this kind of problem doesn't occur in the future.

This is a new features release. It offers quite a bit of change over the previous version. More details of the new features can be found in the man pages.

The substantial changes are:

• Basic support for connecting multiple MQTT brokers together (bridging).
• mosquitto_sub can now subscribe to multiple topics (limited to a global QoS).
• mosquitto_pub can now send a file as a message.
• mosquitto_pub can now read all of stdin and send it as a message.
• mosquitto_pub can now read stdin and send each line as a message.
• Implement a more efficient database design, so that only one copy of each message is held in the database, rather than one per subscribed client.
• Add support for automatic upgrading of the mosquitto DB from v1 to v2.
• If a retained message is received with a zero length payload, the retained message for that topic is deleted.
• Implement the max_inflight_messages and max_queued_messages features in the broker.

The less visible features and bug fixes are as follows:

• Add support for disabling clean session for the sub client.
• mosquitto will now correctly run VACUUM on the persistent database on exit.
• Add the store_cleanup_interval config option for dealing with the internal message store.
• Add persistence_file config option to allow changing the filename of the persistence database. This allows multiple mosquitto DBs to be stored in the same location whilst keeping persistence_location compatible with rsmb.
• Don't store QoS=0 messages for disconnected clients. Fixes bug #572608. This wasn't correctly fixed in version 0.5.
• Don't disconnect clients if they send a PUBLISH with zero length payload (bug #573610).
• Send through zero length messages.
• Produce a warning on unsupported rsmb options instead of quitting.
• Describe clean session flag in the mqtt man page.

Get it from the download page. Windows and Ubuntu binaries will follow along shortly.

I'm currently working on the finishing touches of mosquitto 0.6 and will hopefully be releasing it some time this week in time for oggcamp. Mosquitto is pretty usable now so I'm keen on making it as easy as possible for people to get and use. The ultimate goal is of course to get it into the major Linux distros so it appears in the normal package repositories. Until then, other solutions are possible. I can provide Windows executables and have a PPA to support Ubuntu Linux users, but don't have anything for rpm based distros.

Can you help? I'm quite happy using the opensuse build service to build and host the final packages, but the creation of the rpm build script isn't something I know how to do at the moment. Given the amount of time I've spent on the Debian style packaging, I thought I'd ask for help with rpms! :)

If you've got familiarity with rpm and would like to help, please get in touch. If you aren't familiar with creating rpms but want a reason to learn, that would suit me fine as well.

Thanks in advance!

I'm going to be at oggcamp this coming weekend. If you're there, try and find me and say hello! I'm planning a talk on mosquitto/mqtt with Andy Stanford-Clark, so should be relatively easy to find.

If you're in the UK, you may be interested in watching the Wednesday 21st April episode of "Bang Goes the Theory". IBM employees Nicholas O'Leary and Kevin Brown will be in one of the segments, on controlling remote control cars with their minds - all with MQTT under the covers!

• BBC programme link

A popular use for mqtt brokers seems to be coupling them with a CurrentCost (or similar) energy monitor to then log energy data and produce pretty (and useful!) graphs.

Google recently opened up their PowerMeter API which looks to provide very nice graphing of energy data. They are working with utility companies directly with in home monitors, but it's also possible to use it as an individual.

Toby Evans got to the bottom of registering a device (see his explanatory blog post) which just leaves getting data to Google.

If you're already logging energy data to an MQTT broker, it's as simple as adding another subscriber to send the data to Google. You could use the mosquitto_sub client and a script I wrote for posting to google, google_powermeter_update_mqtt.pl like so:

mosquitto_sub -t sensors/cc128/ch1 | google_powermeter_update_mqtt.pl

This assumes that the data appearing on the sensors/cc128/ch1 topic is in the format <unix timestamp> <power reading in Watts>.

If you're not logging your energy data to a broker, you should probably consider doing so :) There is another script google_powermeter_update.pl which may be more suitable and can be used as:

google_powermeter_update.pl <unix timestamp> <power in Watts>

Both of the scripts need your user details adding and should be easy to modify to match your own particular need. They also assume you're using a single cumulative variable with your device and will need modifying if you're using more than one variable or aren't using cumulative variables.

For reference, I use the script cc128.pl to read data from my CurrentCost CC128 (Envi).

Update:

Google has a limit of 6 API requests per hour, so the above description will only work for a short while (the 6 request limit doesn't appear to be a hard limit when you first exceed it, but becomes increasingly stricter). I'm now logging my CC128 data to a mysql database and sending batch updates every 15 minutes with google_powermeter_update_mysql.pl.

This is a bugfix release.

• Fix memory allocation in mqtt3_fix_sub_topic() (bug #531861).
• Remove accidental limit of 100 client connections.
• Fix mosquitto_pub handling of messages with QoS>0 (bug #537061).