[OpenTRV-dev] XAP

[Paul Smith]

Hi Guys,


I found this also, http://www.homeautomationhub.com/content/nanode-gateway

RF to Xap in a Nanode.

Regards

Paul


Paul Smith

Your Local Computer Specialist, Supporting Your Business When You Need It
Most

We also now do Portable Appliance Testing, if you would like to know more
please drop us a line.

Tel:-  0845 009 6226

This email and any attachments may be confidential and/or privileged.
Everything is intended for use of the addressee only. If you receive this
message in error then you must not print it or pass it on to anyone else or
use the information it contains.  Please inform Phoenix Technology UK  of
the error by email or by telephoning (+44)(0)845 009 6226.  Please then
delete all copies from your system.
If you are not the intended recipient then you must not use the information
in the message or attachments or allow anyone else to do so.


On 4 April 2013 10:27, Mike Stirling <EMAIL ADDRESS HIDDEN> wrote:

>
>
> ----------------original message-----------------
> From: "Damon Hart-Davis" EMAIL ADDRESS HIDDEN
> To: "Closed list for developer discussions"
> EMAIL ADDRESS HIDDEN
> Date: Thu, 4 Apr 2013 10:05:54 +0100
> -------------------------------------------------
>
>
> >>
> >> 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.
> >
> > I'd hope that we'd allow some simple cases where (say) a MQTT binary
> frame
> > composed at an OpenTRV component (eg temperature measurement) could be
> wrapped
> > in UDP (eg by the Arduino IP stack) to travel across a LAN, and possibly
> then pass
> > over a VPN tunnel to a remote monitoring service (such as Bruno's),
> untouched by a
> > 'gateway'. A user's current Internet modem/router would quietly do much
> of the
> > heavy lifting in this case.
> >
> > In other cases I'd expect a gateway to interpret and transform any
> incoming
> > lightweight (MQTT or raw) frames from OpenTRV components and provide any
> > application-level transformations needed.
> >
> > Basically I'd like the simplest-possible system to remain very simple
> (but
> > reasonably intrinsically secure) so that more capable uCs might just
> about be
> > able to handle smarter comms, but less capable uCs are not excluded from
> the
> > playground...
> >
> > Rgds
> >
> > Damon
>
> In this example, what is the Arduino if not a gateway? Translating a
> binary protocol into MQTT/xAP would pale into insignificance compared with
> the IP stack, DHCP client, ARP, etc. etc. that would be the minimum
> required on the LAN side, so why not do a translation?
>
> Note that I am not advocating a closed RF protocol here, but possibly a
> binary extension to something like xAP that would map easily onto the
> full-blown text version. The transmitter draws between 20 and 30 mA, so
> every bit counts for battery life. Also, the less time spent on-air, the
> less likely we are to run up against regulatory duty cycle restrictions or
> network performance issues.
>
> Mike
>
> --
>
>
>
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20130404/a6655a62/attachment.html>