[OpenTRV-dev] Feedback Mechanisms.

[Thomas Hood]

On Fri, Mar 22, 2013 at 5:46 PM, Jack Kelly <EMAIL ADDRESS HIDDEN> wrote:

> Some specific local controls I'd propose (these are controls I wish my
> existing TRVs had):
>
>    - Increase / decrease current target temp (without changing the
>    schedule)
>    - Temporarily modify the local schedule:
>       - A local "boost" button to turn heat on in increments of X minutes
>       (e.g. one press turns on heat for 30 minutes.  Two presses for 60 minutes.
>       Three presses for 90 minutes etc...).  The target temperature defaults to a
>       user-definable "warm" temperature but this can be overridden using the
>       increase / decrease temp control.
>       - A local "advance" button to jump to the next scheduled mode (or
>       if we're currently in "boost" mode then pressing "advance" cancels the
>       "boost" mode)
>    - Child lock / unlock  (if locked and someone tries to use it then a
>    sentence of text should scroll across the screen explaining how to unlock:
>    this will help guests / relatives / forgetful adults.  If a kid is old
>    enough to read scrolling text they they're old enough to defeat any trivial
>    unlocking mechanism!)
>
> I'd propose that all "advanced" programming (setting daily schedules etc)
> can be done over a smart phone / web interface.
>


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.



> In terms of what to display... the 2 existing electronic TRVs that I've
> tested basically only display the current target temperature and current
> time.  This is useless.  I already *know* the target temperature (I
> programmed the damn thing!) and I have multiple devices telling me the time
> (my watch, my phone, my laptop etc...)  Instead I think it would be useful
> to display:
>
> * The current *actual* temp and target temp (if there isn't space to
> display both then switch between them every 10 seconds or something like
> that)
> * Time until the current mode is scheduled to change
>
> And a bunch of boolean flags:
> * Whether the radiator valve is opened or closed
> * Whether the TRV is calling for heat from the boiler.
> * Whether we're in an "override" mode (boost / advance)
> * Whether the battery is almost dead.
>
> A backlight would be ideal (I often have to tinker with the TRV in my
> daughter's room while she's asleep).
>


How much of this information has to be displayed on the TRV itself it it's
available on the central control unit's display or in the app?  Not all of
it, I'd say.

Standing next to a TRV equipped with a "boost" button and either feeling a
bit chilly or not, I'd like to know what the TRV thinks the current
temperature is, what its default target is, what its boosted target is, and
how long the remaining boost period is. And, yes, the battery level and
wireless signal strength.
-- 
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20130323/4fd5afdb/attachment.html>