Monthly Archives: September 2012

Fixes Released, v0.1 FINAL is out!

Tonight I released the final version 0.1 build.  I added a couple nice-to-have’s to this build, including:

  • Full support for the LWT portion of MQTT protocol.  (this is all configurable on the <mqtt:config /> tag). 
  • Change to get rid of the MuleMqttMessage object, and instead return the byte[] payload of a message, with relative information stored in the INBOUND property scope.  I also modified the publish method to appropriately set the OUTBOUND scope accordingly.
  • Fixes to a couple bugs, mainly with Mule application reloading, so that clients appropriately disconnect/reconnect with the MQTT broker. 

You’ll notice I stripped out my functional test cases, and this was due to improper coding of them on my part.  I’m going to re-introduce proper test cases in my upcoming version, 0.2, hopefully.  

Enjoy!

https://github.com/dmiller44/mule-module-mqtt


MQTT, Mosquitto, Apple and Java Issues

As I develop my Mule connector for MQTT, I ran into some issues that kept me from testing real-world scenarios from my Apple laptop and desktop.  Anytime I connect using the Eclipse Paho MqttClient class, and subscribe to a given topic, I will inevitably get a “Connection Lost” exception after two to four minutes of time.  I mitigate this in my Mule connector by auto-reconnecting to the MQTT broker, however, I was baffled at why this was happening.

I started by running the Sample class provided by the Eclipse Paho team.  I pointed this at my local instance of Mosquitto (installed via Homebrew), and subscribed to a topic.  I simply let the program run without publishing any messages to the broker.  After roughly two minutes, I would get disconnected.  Figuring my configuration of Mosquitto was to blame, I pointed this at the public test Mosquitto server, found at test.mosquitto.org.  Again, I repeated the same steps with the same results, an exception was generated minutes later for Connection Lost.

Finally, I pointed the Sample class at a different broker all together, which in this case was the dev.rabbitmq.com public broker.  Same topic subscription and M.O, I connected and subscribed, and waited.  Thirty minutes passed without a single “connection lost” exception.  To hopefully prove network issues, I re-pointed the program at test.mosquitto.org, and again found myself getting bounced in a couple minutes.

I’m at a loss for the cause of this issue, other then something with Mac’s implementation of Java and Mosquitto.  I even tested this using the Oracle Java7 version for Mac, and found the same issue.  Simply changing the broker implementation fixed it, though I can’t believe that’s the issue’s core.

Running this same code against any Mosquitto broker instance from an Ubuntu Server installation has absolutely no issue.  I’ve reproduced this issue only on Apple computers, currently an Apple iMac running Lion and an Apple MacBook Pro running Mountain Lion.

Please tell me that someone has had similar issues and knows how to fix them?  Or can give me something else to try?  I’ve posted the links to the code that I ran to test this below.

https://github.com/eclipse/paho.mqtt.java/blob/master/org.eclipse.paho.sample.mqttv3app/src/org/eclipse/paho/sample/mqttv3app/Sample.java


MQTT and Mule ESB – Connector v0.1 Release

As a man fascinated by home automation, I constantly am reading up on the latest technical news when it comes to data integration in my home.  MQTT recently was thrown into my radar, and I began researching it to see if it’s capabilities would work in my blooming home automation project.  The scenario I had was simple:  I have two young children, with two new rooms recently added to my home to accommodate them.  Does our current heating/cooling system keep their rooms at an ideal temperature for them to rest comfortably?  Or will I horrifically overheat or chill my children due to improper balancing of my HVAC system?  I created two small, wireless, Arduino-based XBEE sensors that could report to me the room’s humidity and temperature stats (amongst other things), but needed a system for these two sensors to report to.  Enter MQTT and the Mosquitto broker.

MQTT was a solid fit for what I was looking to accomplish.  Having experienced RabbitMQ/AMQP over the last three years, I’m a fan of topic-based pub/sub systems.  However, AMQP is a bit overkill for sending sensory data so simple as room temperature, and MQTT is perfect for taking over the job.  The issue I had was with integration into my other systems:  I use Mule ESB as my SOA hub for all my data storage and reporting systems in the house.  So, I was saddened to see that, while supporting a plethora of other protocols, MQTT was not yet supported natively or via MuleForge.  So I decided to change that, not just for myself, but for others looking to do similar projects as me.

Without further ado, I introduce the MQTT Mule Module v0.1.  Let me start by putting up the normal disclaimer:  Use this connector at your OWN RISK!  While I will do my best to keep it relevant and in solid working order, I’m doing this all on my personal time, which can be lacking when it comes to hobbies.  Second disclaimer:  I’m not yet well-versed in MQTT, or in the creation process of Mule Modules/Connectors.  So, these first couple releases are a learning experience for me, and I apologize if I have veered from good coding convention, or if a feature or two have been overlooked.  I’m simply trying to get this connector in the wild so it can begin getting pressure tested by folks like yourself.

So what does v0.1 have?  Pretty simply put, it has everything you need to subscribe and publish to a MQTTv3 broker.  I’ve tested against Mosquitto servers only, so your mileage may vary.  Currently, you can only subscribe to a single topic (no topic filters in this initial release).  Also, you can only publish java.lang.String messages to the broker.  Retention policies haven’t been exposed to you yet (I’m working on that) and LWT messages are not available.

Sounds pretty thin, doesn’t it?  Great news:  v0.2 is already in the works.  It will expose the abilities that I had left out in the interest of time (such as retain settings exposure and LWT), and will also have a couple added features like payload transformations and population of inbound scope properties during subscribe.  It will also contain any bugs found in the initial release, which I expect to be a few.

Documentation currently is being kept here:
http://dmiller44.github.com/mule-module-mqtt/

Source code is currently hosted here:
https://github.com/dmiller44/mule-module-mqtt

Issues can be tracked here:
https://github.com/dmiller44/mule-module-mqtt/issues?state=open

The module has been tested using the Mule ESB 3.3.0 Community Edition, but has been targeted to work *hopefully* on version 3.2.2.  I will continue to test this connector against the Mule instances I have running and update the documentation as I discover issues.

I encourage all of you to test this out and give me constructive feedback.  I can’t stress enough how excited I am to be releasing this, but how nerve racking it feels to release something without having a lot of exposure to the coding practices and standards of writing such a plugin.  It’s my hope that over the next many months, this module will stabilize and become a reliable connector for folks to use in their personal and professional endeavors.

Thanks for your interest!  Please leave comments below or at the Github site.

– Dan