[OpenTRV-dev] TRV control - my problem, and musings so far

[Damon Hart-Davis]

Hi,

Some initial quick points: yes, the "heating rooms you're not using" annoyance is exactly what drove me to start OpenTRV.  And I only have about 6 radiators for 4 people!  Until I started this project we turned the TRVs up and down manually as required adjust target temperatures throughout the day when needed.

You can already buy smart TRVs with schedules in them (such as the i30 / i35 http://www.earth.org.uk/note-on-i30-iTemp-terrier-programmable-TRV.html) and that can be manually overridden if need be.  I have one of these in my daughter's room to help ensure it is warm before bed-time, though it cannot call for heat centrally.

You can buy systems such as the Conrad FS20 system, from which we are currently using the FHT8V wireless valves) that can do this and talk to a central unit to call for heat from the boiler, but they aren't interoperable with other systems, probably overpriced partly as a result, and I couldn't find one with automatic response to occupancy.

Some systems will try to learn your typical usage patterns, which is useful if your house's response to heating is slow and anticipation is necessary for decent comfort.

OpenTRV currently does some limited occupancy sensing (and I want to improve/expand it, eg with PIR), central call for heat, and will have some simple scheduling soon at each TRV (maybe even today if I make an effort!).  One of the MSc students is interested in the learning/anticipation element so we might make some progress there this summer.

Given the size of your house you may wish to use a configuration where more of the control and timing is centralised at the boiler node or on a hub, maybe even accessible from laptop or smartphone.

So yes, we're trying to address your problem!

(Please excuse the royal "we" here: if anyone disagrees with these points, please pipe up!)

In a little more detail on some of your points:

1) Rather than bending a mechanical TRV to do something it isn't intended to, I suggest that the various existing electro-mechanical valves that don't need to keep consuming energy (and emitting carbon) to stay open or closed are a better idea.  We are using one such, the wireless FHT8V, but we want to do our own direct drive too.

2) It really shouldn't be hard to integrate TRV and PIR: it's been my goal since before starting this project.  (I may even have found a good Murata part for the job, not too expensive.)

3) This can be done either in a distributed way (if no TRV senses occupancy and isn't otherwise scheduled then there will simply be no call for heat), or a more centralised way, and the latter may better help decide whether to skip DHW too as you suggest.  (For me, with "instant" DHW, it's not an issue, which is why I hadn't considered it: thank you for bringing it up.)

4) There are clever schemes to coordinate between heat demands to get maximum efficiency from the boiler (AKA "optimum on" and "optimum off"), but my dead simple scheme seems to be working well (50% below expected heat demand this last week according to imeasure) which is that if any TRV demands any heat then the boiler provides it.  My boiler self-modulates by monitoring return temperature, but other boilers may well benefit from a smarter scheme.  I think it's important not to overthink the plumbing here though, avoiding the best becoming the enemy of the good.  We're after good robust schemes first I think, before tinkering too much.

There are definitely different ways to tackle this, but yours is exactly the sort of problem that I want OpenTRV to help with: the energy savings ought to be substantial and if done right the system should work more pleasantly and easily than now.

Rgds

Damon 


On 2 Apr 2013, at 10:53, Kevin Wood wrote:
> 
> 
> 1) Defeat unwanted zones on a time basis.
> 
> 2) Control zones using an in-room "smart" device
> 
> 3) Replacement programmer
> 
> 4) Integration and control strategy
>