[OpenTRV-dev] XAP

Thu Apr 4 10:27:21 BST 2013

----------------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.




More information about the OpenTRV-dev mailing list