[OpenTRV-dev] Feedback Mechanisms.

[Thomas Hood]

On Sat, Mar 23, 2013 at 4:54 PM, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:
> 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.

If the target temperature can be set on a TRV "until the next timed
set point" then in order to make convenient use of the feature I need
to see on the TRV display what the time of the next set point is. If
the TRV's program has no set points (i.e., it is set to a static
temperature) then the override will last forever, and this should be
clear on the TRV display. And it would be nice to see the current time
so that I know that the valve's idea of the current time is correct.

Some other random questions arising from my reading in other fora...

* If something is overridden on the TRV, can the override be
overridden from the control panel?

* When a TRV temporarily loses connectivity and/or power, does it
reconnect automatically and download its program? Does temporary
losing connectivity or power cause an override to be canceled? Will a
TRV with flaky connectivity then be experienced as a TRV on which
"override only lasts a couple of minutes"?

* Is the TRV "smart"? Does it learn that it must shut off the radiator
early so as not to overshoot the target temperature? So that when it
is temporarily removed from the radiator it learns that it must never
turn on the valve at all, and is experienced thereafter as
non-functional?

One important lesson to be learned from existing systems is that all
TRV information should be available on the central control panel so
that the system can be debugged.
--
Thomas