[OpenTRV-interest] First impressions and questions

[Damon Hart-Davis]

> On 25 Jan 2017, at 19:42, Jason Pearce <jason at pearce.org.uk> wrote:
> 
> I wasn't explicit enough - remote sensor - something like a stats hub being used wirelessly in sensor mode to send data to a (or more than one) local trvs in a room - stats hub at a convenient height/location - the box you sent with my stats hub is discreet enough - the trv in my bedroom was measuring around 22 celcius - it wasn't actually that hot in the room, so the trv sensor is being affected by the radiator.

The TRV code applies some low pass filtering to get a better idea of the real room temperature, but yes.


> 
> Something else I pondered earlier - I like my bedroom to be warm when I wake up to get dressed for work - but if the occupancy sensor thinks I'm out cause it's dark, it won't have preheated the room to a nice cosy temperature.

Depending which version of the code you load, the system does in general try to predict occupancy so that you don’t walk into a freezing room, BUT unless the signals are very strong is reluctant to start warming rooms in the morning (read: after several hours of continuous darkness) for fear of waking the occupants/dead/neighbours with clanking pipes etc.  I don’t yet have a good simple resolution to that dilemma.

> 
> And finally - my eq3 trvs do a weekly "exercise" to ensure the pin on the trv base doesn't stick - thats something I would consider a useful function to have.
> 

At the moment in the heating season this just won’t be an issue.

There is API to support it.

It isn’t yet done, and there are a number of ways it could be done.

Anyone who’d like to volunteer to work with me on a nice robust solution, would be welcome.

Note that for the current TRV1.x driver, recalibration would be perfectly decent for decalcination, and could for example be triggered weekly if no significant valve movement in the interim, AND if it is not dark.

Rgds

Damon