[OpenTRV-dev] Feedback Mechanisms.

[Damon Hart-Davis]

Here's a cut-n-paste from the .bas file:

;-----------------------------------------
; UI DESCRIPTION
; Button causes cycling through 'off'/'frost' target of 5C, 'warm' target of ~18C,
; and an optional 'bake' mode that raises the target temperature to up to ~24C
; for up to ~30 minutes or until the target is hit then reverts to 'warm' automatically.
; (Button may have to be held down for up to a few seconds to get the unit's attention.)
; Acknowledgement is medium/long/double flash in new mode
; (medium is frost, long is 'warm', long+medium is 'bake').

; Without the button pressed,
; the unit generates one to thre short flashes on a two-second cycle if in heat mode.
; A first flash indicates 'warm mode'.
; A second flash if present indicates "calling for heat".
; A third flash if present indicates 'bake mode' (which is automatically cancelled if the high target is hit).

; This may optionally support an interactive CLI over the serial connection,
; with reprogramming initiation permitted (instead of CLI) while the UI button is held down.

; If target is not being met then aim to turn TRV on/up and call for heat from the boiler too,
; else if target is being met then turn TRV off/down and stop calling for heat from the boiler.
; Has a small amount of hysteresis to reduce short-cycling of the boiler.
; Does some proportional TRV control as target temperature is neared to reduce overshoot.

; This can use a simple setback (drops the 'warm' target a little to save energy)
; eg using an LDR, ie reasonable ambient light, as a proxy for occupancy.


Rgds

Damon


On 22 Mar 2013, at 13:44, Stuart Poulton wrote:

> Happy to hear about how other people are doing UI's 
> 
> Cheers
> 
> Stuart
> 
> On 22 Mar 2013, at 12:29, Damon Hart-Davis wrote:
> 
>> Hi,
>> 
>> I seem to be getting enough local control with the single LED and single button interface that I have at the moment.  That gives local override and status.  I can describe the UI I have a little more if that is of interest.
>> 
>> I also hope to be able to double up the programming interface to provide a limited CLI that a c/o a GUI on a laptop should be able to provide a simple secure interface to set schedules and so on.
>> 
>> Rgds
>> 
>> Damon
>> 
>> 
>> On 22 Mar 2013, at 11:47, Stuart Poulton wrote:
>> 
>>> Dear All,
>>> 
>>> Again, I'd be interested in opinions.
>>> 
>>> Whats sort of feedback do users need at the TRV level ? All of our current TRV's provide an LCD, which is fine, but it increases the amount space required.
>>> If settings could be done wirelessly, and current state of the valve (position and battery voltage) reported back, does anything other than maybe a flashing LED need to be present ?
>>> 
>>> What about local control, how often is it actually used to override the current settings of the valve ?
>>> 
>>> Stuart
>>> _______________________________________________
>>> 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
>