[OpenTRV-dev] Feedback Mechanisms.

[Damon Hart-Davis]

Curiously I thought that that would be more important than it has been for my daughter's room, though when my 4 year old boy gets an OpenTRV in his room for next winter, that might seem more important again!

Rgds

Damon

On 22 Mar 2013, at 17:55, Mike Stirling wrote:

> Grrrr.  Another requirement for local control: child lock!
> 
> On 22/03/13 17:32, Stuart Poulton wrote:
>> (arggg. Another one marked as spam).
>> 
>> I have to agree that the hotter colder idea is good. I'm supposed to be on a trial of the Wattbox system that works on just this theory, but since they became part of alertme it's not progressed.
>> I think I'll be having it taken out.
>> 
>> 
>> 
>> On 22 Mar 2013, at 17:10, Damon Hart-Davis wrote:
>> 
>>> Hi,
>>> 
>>> Utterly agreed on at least some degree of local control being important for acceptance.
>>> 
>>> I like the detailed display on my i30 and share Jack's frustration about not being told current temperatures, only things that I already programmed in, etc.  On the other hand I was listening to the wide agreement at the DECC workshop that temperature is not necessarily the right thing to fixate on since human's aren't that precise as thermometers.  MacKay's contention that a "I'm too cold" button and no temperature display might be better is an idea I'm trying out with the current system, in part.
>>> 
>>> What I don't want in any unit that I use (so note, I'm not saying that this is wrong in general, just for my own purposes and having taken into account discussions at DECC, and with my family, and for my house!) is a UI so complex that it remains untouched like the 00:00 of horrific VCRs or that needs a long perusal of the manual which will not be to hand at the right moment.
>>> 
>>> I also happen to favour having most of the smarts in the TRV for control and security reasons (less to 'prank' over the air for example, and less information leakage too).  Again, this is just me and just one deployment.
>>> 
>>> So with my current efforts I'm seeing what I can achieve with a button or two and a(n) LED or two, with the option to plug into a laptop for smarter setup of schedules and so on.
>>> 
>>> Note that even my minimal current implementation does meet some of Jack's requirements, and I will stretch it enough for Bo to control his DHW on a schedule with it too.  (And my kids' bedrooms to get warmed up before they go to bed!)  I am trying to do this without excessive contortions!
>>> 
>>> So I think that we really should start writing up some use cases and showing where the smarts and the UIs are, wire-frames for the units and functional splits, etc, etc.
>>> 
>>> If we get this right we'll have a wonderfully flexible system (without over-generalising and having hundred-button handsets) and a Pentium *providing* the heat in every TRV!
>>> 
>>> Rgds
>>> 
>>> Damoin
>>> 
>>> 
>>> On 22 Mar 2013, at 16:46, Jack Kelly wrote:
>>> 
>>>> I would propose that feedback and control at the TRV is essential for wider acceptance by the rest of the family.
>>>> 
>>>> These suggestions might be best held back until a subsequent iteration of the design but here's my ideal UI... (and these really are just suggestions... I'm certainly not trying to write a specification or set of requirements!)
>>>> 
>>>> Buttons
>>>> 
>>>> 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.
>>>> 
>>>> Display
>>>> 
>>>> 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).
>>>> 
>>>> As I said, the above is just my "ideal" UI.  I completely accept that this stuff might not be relevant for the current design iteration (where the priority is to get stuff working with a bare minimum of features).
>>>> 
>>>> Thanks,
>>>> Jack _______________________________________________
>>>> OpenTRV-dev mailing list
>>>> EMAIL ADDRESS HIDDEN
>>>> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>>> _______________________________________________
>>> OpenTRV-dev mailing list
>>> EMAIL ADDRESS HIDDEN
>>> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>> _______________________________________________
>> OpenTRV-dev mailing list
>> EMAIL ADDRESS HIDDEN
>> http://lists.opentrv.org.uk/listinfo/opentrv-dev
> 
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>