[OpenTRV-dev] MQTT

[Damon Hart-Davis]

Forwarded to the list for a searchable record...

Begin forwarded message:

> From: Bruno Girin
> Date: 11 March 2013 09:42:05 GMT
> Subject: Re: MQTT [Was: Re: PCB builds of V0.09]
> 
> Completely agree. Then specify a binary/text mapping for the keys and
> provide a reference implementation to serialize/deserialize data over RF
> + a bridge to go from RF to MQTT/REST and back again.
> 
> Bruno
> 
> On 11/03/13 08:21, Damon Hart-Davis wrote:
>> Yes, that sounds plausible if the encoding and decoding is kept as simple as possible on the sensor side, eg fixed width and binary or mock-binary encodings for fields.
>> 
>> Rgds
>> 
>> Damon
>> 
>> On 11 Mar 2013, at 08:08, Mike Stirling wrote:
>> 
>>> I'm still keen on the idea of producing a properly specced RF protocol that could be used by all open source home automation projects, and that would wrap up all the security and authentication aspects that no one likes to think about.  For that I had in mind something like simple binary name/value pairs where the name tag would be globally assigned (for interoperability).
>>> 
>>> The bridge/router could then go to MQTT and straight onto Ethernet.
>>> 
>>> 
>>> Damon Hart-Davis wrote:
>>> 
>>>> Thanks!
>>>> 
>>>> Do you want to create a Wiki page or shall I?
>>>> 
>>>> I think that almost any generic text parsing is going to be beyond the abilities of (say) the PICAXE in terms of time and code space, but fixed-width fields that happen to be ASCII may be much easier to handle.
>>>> 
>>>> Rgds
>>>> 
>>>> Damon
>>>> 
>>>> On 10 Mar 2013, at 23:17, Bruno Girin wrote:
>>>> 
>>>>> 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!
>>>>>> 
>