[OpenTRV-interest] OpenTRV board as 868MHz transceiver

[Damon Hart-Davis]

Hi,

Yes Marko, what we have done for the COHEAT deployment is closer to what Alasdair is after.

Alasdair: I expect my kids to need looking after in a few minutes so picking a couple of points at random (Alasdair, my son has materialised and I haven’t finished reading your email yet!).

1) Controlling more than one FHT8V from a single OpenTRV unit would be very difficult unless the FHT8V units have the same house codes because of the complexity of the timing that would result and the radiio TX timings.  As Marko says the transmitter is basically on every second for a substantial time during sync, and then the sync cycle time depends on the house code.  I have broken the FHT8V logic out into a separate class to make it *possible* to have multiple instances, but I don’t recommend it.

2) Because of security considerations the OpenTRV valve-controller units have been transmit-only up to now, with the glorious exception of the COHEAT variant where they act as dumb-ish relays of the COHEAT-central-control valve open percentage.  Our intention very soon (I am working on the security code right now) is to allow to you to tell each OpenTRV unit what temperature you want to be at, overriding its internal logic.  (It would revert to that internal logic if/while it lost the radio link.)  We could also override a COHEAT-style override of the percentage open for the valve, but then you would have to close the temperature control loop in real time.  Not impossible, but not recommended unless your day job is developing control algorithms (as is COHEAT’s!).  That control loop is tricky and you risk eating up bandwidth and batteries if you keep that loop tight enough; you might even break the legal duty cycle limits for the radio band we’re using!

So, the upshot is that two-way control is on its way, but we don’t want to do it until we can do so securely.

Rgds

Damon


> On 10 Jan 2016, at 07:39, Marko Cosic <marko at coheat.co.uk> wrote:
> 
> On 10 January 2016 at 02:49, Alasdair Macdonald <alasdairgmacdonald at gmail.com> wrote:
> What I want to do
> is use fhem to make decisions about whether to open or close my Conrad
> TRV, but what's happening is that the board that is paired with the
> valve is making all the decisions.
> 
> This sounds a lot like the COHEAT code variant Damon. 
> 
> (PC makes decisions, sends these to an OpenTRV board using a REV2 board, the OpenTRV board relays the decisions to the Conrad valve (ELV FHT8V) and spits back some room sensing data)
> 
> 
> When a non-Hub board pairs with a Conrad Valve, the valve knows that
> it is paired. I don't know if there is an ongoing, occasional dialogue
> between paired devices, but in this relationship the OpenTRV board is
> still a transmitter, and the Conrad Valve a receiver. I don't know if
> the Conrad Valve actually transmits any information, perhaps someone
> here can put me straight on this.
> 
> There's an ongoing one-way transmission to FHT8V valves
> 
> 
> * Have an OpenTRV board that can send data to multiple TRVs, on an
> ad-hoc basis. I don't know enough about pairing (and I only have one
> Conrad TRV) to know if I can pair with multiple TRVs.
> 
> One OpenTRV board one FHT8V is easier
> 
> 
>  I don't know is at all sensible (in the case of multiple
> radiators / TRVs) to change House Code (and re-sync?) whenever I want
> to control any individual radiator.
> 
> Normal one-way transmissions to the FHT8V valves is a signal every 2 minutes.
> 
> Re-sync is 2 minutes of almost continuous broadcasting. You wouldn't want to do this every time you change a valve position and it would not make the FT8B receive it any faster.
> 
>  
> * Set a mode and target temperature such that the board will send a
> command to open or close its paired TRV. (And I'm not sure what
> strategy to use here, given that essentially I want to "trick" the
> OpenTRV board into sending its own command to the TRV).
> 
> There's a lot of art in what OpenTRV have coded in TRV control.