[OpenTRV-dev] Feedback Mechanisms.

Damon Hart-Davis EMAIL ADDRESS HIDDEN
Sat Mar 23 15:54:57 GMT 2013


Hi,

On 23 Mar 2013, at 14:19, Thomas Hood wrote:

> Hi. It is important not to underestimate how much complexity it adds to allow things to be controlled via more than one interface. I was reminded of this while reading up on the existing commercial systems in user forums. Various radio-programmable TRV systems allow for central programming and local override and this leads to problems.
> 
> Problem #1. In some systems the fact that the target temperature has been overridden on a TRV is not visible on the central console. This gives rise to the situation where someone has fiddled with the TRV and this gets forgotten until a surprisingly costly energy bill arrives or until someone starts to wonder why the boiler keeps coming on.
> 
> Problem #2. Once the program is overridden via the interface on the TRV, how long does the override last? In some systems the override remains in force indefinitely, as just mentioned. In some systems the override ends at the end of the current "period" as defined in the schedule. In some systems the override ends at the end of the period if and only if the target temperature is different in the next period. This leads to user confusion.
> 
> If the TRV is to have any override controls, I'd initially think that a single "boost" button as described above would suffice.

I have certainly been considering some of the points you make, and my preferred option is to have a general override last only until the next timed set-point, and a boost for a relatively short time (I have currently 30m or the high set-point is reached, whichever comes first), except possibly for a 'holiday' mode keeping the target to only frost protection indefinitely.

In general, set up the interface so that any manual override is limited in duration and tends to use less rather than more energy if forgotten.

(For example on the current implementation I have a slew limit when opening the valve to reduce noise and overshoot, but the unit is always prepared to snap the valve fully closed at any time to conserve energy, ie asymmetrically biased towards conservation.)

Rgds

Damon


More information about the OpenTRV-dev mailing list