[OpenTRV-dev] MQTT

[Damon Hart-Davis]

Forwarded to the list for a searchable record...

Begin forwarded message:

> From: Bruno Girin 
> Date: 10 March 2013 23:17:37 GMT
> To: 
> Subject: MQTT [Was: Re: PCB builds of V0.09]
> 
> Hi all,
> 
> I had a play with MQTT over the weekend. It is indeed very easy to setup and use. If you want to give it a go on Linux, install the mosquitto server: it's running on my Raspberry Pi with very little impact on the processor [1].
> 
> [2] is where Eclipse Paho is hosted, which provides C and Java clients. Mosquitto provides a C library, python and JavaScript clients. You have clients for Arduino [3] and Nanode [4] as well. Full list: [5]. Also note that more heavy-weight MQ brokers like RabbitMQ and Apache Apollo (aka ActiveMQ) have MQTT plugins.
> 
> In terms of usage, both the Java and python libraries are dead easy to use.
> 
> When it comes to real life, MQTT makes it easy to send generic payloads to a given topic on a given broker. In this respect, it is not unlike REST services: where MQTT has a topic and a payload, REST has a URL and a payload (and an HTTP verb, let's assume POST). In both cases, there is no particular specification for the format of the payload so we would need to define one. We could probably use JSON as a payload format as it's simple to parse and all languages that support MQTT have JSON parsers.
> 
> MQTT topics are slash separated paths so we could make both MQTT and REST work in very similar ways:
> 
> MQTT: broker = my.server.com; topic = my/topic; payload = { key: value }
> REST: URL = http://my.server.com/prefix/my/topic; verb = POST; payload = { key: value }
> 
> That way, you could use MQTT on an intranet and REST when going over the internet with no change in the topic name or message format. You could then have a home automation hub that speaks MQTT and has a simple forwarder that subscribes to the right topics and forwards to a data gathering server on the net.
> 
> In addition to all this, we would probably want to devise a simplified format for the payload that would be suitable for the PICAXE implementations although JSON might even be lightweight enough for the PICAXE.
> 
> Sorry for the rambling nature of this email, I just wanted to dump what I had on my mind so that you could comment on it.
> 
> Cheers,
> 
> Bruno
> 
> [1] http://mosquitto.org/
> [2] http://m2m.eclipse.org/
> [3] http://knolleary.net/arduino-client-for-mqtt/
> [4] https://github.com/njh/NanodeMQTT/
> [5] http://mqtt.org/software
> 
> On 07/03/13 07:38, Philip Canavan wrote:
>> When I spoke to Hekkers about the OpenTherm gateway, he was pretty upbeat about MQTT ("MQTT is great, I love it"), reckoning "It has been proven to be very stable and easy to install (I'm using it on Linux & Windows)". Given the momentum and the design parameters I think it might be a good fit on the sensor side. I also think a suitably secured REST interface would make sense on the control\status side of things (in my mind I'm assuming a hub-and-spoke approach with sensors and clients hanging off a central controller vs a pure fabric of sensors).
>> 
>> 
>> PS: Sorry for being all menu ideas and no cooking so far, but after this long I'm putting the renovations first until I've got a working house!
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20130317/18db1f55/attachment.html>