[OpenTRV-dev] XAP

[Kevin Wood]

Yes, even linking in string manipulation libraries takes a substantial
chunk of memory on an AVR. Processing strings is also obviously much more
CPU intensive than exchanging small binary packets, and that impacts
battery life.

Interworking with devices supporting these protocols is a good aim, but
are we planning for this this to be maintained right down to the TRV
itself or  to have a gateway device that provides a bridge between an
efficient binary wireless protocol at the TRV and open protocols over
other interfaces to the outside world? A gateway could, of course,
implemented on a more capable platform, or, at least, on a microcontroller
that has less tight power, memory and cost constraints than a TRV node.

Kevin

> Except that anything beyond a simple binary format will likely tax a uC
> beyond endurance, especially for parsing.
>
> A trivial CLI on the PICAXE that I'm working on right now has taken 25% of
> my available code space and makes MS-DOS 1.x look a little over-friendly!
>
> Rgds
>
> Damon
>
> On 3 Apr 2013, at 14:39, Bruno Girin wrote:
>
>> MQTT doesn't specify a message format so you could very well use the XAP
>> message format over MQTT.
>>
>> Which reminds me, I need to add the PoC code I came up with to the
>> source tree.
>>
>> Bruno
>>
>> On Tue, 2 Apr, 2013 at 4:26 PM, Thomas Hood <EMAIL ADDRESS HIDDEN> wrote:
>>> On Tue, Apr 2, 2013 at 5:16 PM, Mike Stirling <EMAIL ADDRESS HIDDEN>
>>> wrote:
>>>
>>>  I never really understand the logic behind projects that say they are
>>>  targetting low-end embedded and then go on to develop a protocol in
>>>  human-readable ASCII, or worse, XML!
>>>
>>>
>>> At
>>> http://www.xapautomation.org/index.php?title=Protocol_definition
>>>  I
>>> found some explanation for this. I quote with a little editing for
>>> readability:
>>>
>>> Each name-value pair within the message block is defined by a keyword,
>>> a delimiter, a value and a terminator. [...] The delimiter determines
>>> the method of value encoding.
>>>
>>> '=' (equals sign, ASCII character 61 decimal) indicates that a value
>>> is encoded as an ASCII string. This is the preferred encoding format.
>>>
>>> '!' (pling, ASCII character 33 decimal) determines that a value is
>>> encoded as an ASCII hex representation. This allows the broadcast of
>>> raw binary data. Whilst unavoidable under certain circumstances, its
>>> use is discouraged because of the issues with portability (numeric
>>> representations differ across processor types).
>>>
>>>
>>> --
>>>
>>> Thomas
>>> _______________________________________________
>>> OpenTRV-dev mailing list
>>> EMAIL ADDRESS HIDDEN
>>>
>>> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>> _______________________________________________
>> OpenTRV-dev mailing list
>> EMAIL ADDRESS HIDDEN
>> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>