[OpenTRV-dev] Two-way working for OpenTRV

[Bo Herrmannsen]

sorry for not responding before now, was watching the latest hobbit movie

nothing new from OEM, but i gave them links to both rev1 and rev2, both 
eagle files and code for both rev's

but since its a sunday i did not expect an answer

but exciting anyways

-----Oprindelig meddelelse----- 
From: Damon Hart-Davis
Sent: Sunday, April 13, 2014 5:48 PM
To: Closed list for developer discussions
Subject: Re: [OpenTRV-dev] Two-way working for OpenTRV

Indeed, yes.

On 13 Apr 2014, at 16:25, Bruno Girin <EMAIL ADDRESS HIDDEN> wrote:

> Brilliant! A second use of (2) is to notice when the hub or a leaf is no 
> longer responding. This seems to happen to me occasionally at which point 
> I have to restart the device.
>
>
> On 13 April 2014 15:46, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:
> Hi,
>
> FWIW, in the light of all sorts of comments from various of you, I’m going 
> to establish the viability of:
>
>  1) Piggybacking some info onto the end of an FS20 frame (eg, subject to 
> security concerns, mode, temperature, target temperature, occupancy, light 
> levels, etc).  The idea with this is to only require a few ms of extra 
> radio run-time to get the info to a central point, not a whole extra radio 
> and frame setup.
>
>  2) Two-way working, eg the hub sending an ACK plus possibly a queued 
> command back to the leaf nodes in immediate response to an incoming frame, 
> again using the FS20 carrier and basic frame to minimise complications and 
> new work and maximise ease of switching between TX and RX.
>
> Obviously in the light of (a) Mike’s work and (b) possible OEM interop the 
> channel in either direction might have different carriers and bit 
> patterns, but I’ll try to abstract that a little inside so I don’t care 
> what the carrier is, (and more than one could be used in parallel) though 
> it will care whether the channel is secure or not.
>
> If I get (1) running I’ll use it to centrally monitor temperatures around 
> my house, etc.  If I can use Mike’s stuff to make this an MQTT frame with 
> optional security all the better.  For now this is all just testing the 
> waters.
>
> One use of (2) is to help simplify pairing and key exchange between a leaf 
> and the hub as well as allow control from the central hub.
>
> Rgds
>
> Damon
>
>
> _______________________________________________
> 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