[OpenTRV-dev] Feedback Mechanisms.
EMAIL ADDRESS HIDDEN
Fri Mar 22 16:33:15 GMT 2013
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.
On 22 Mar 2013, at 13:44, Stuart Poulton wrote:
> Happy to hear about how other people are doing UI's
> On 22 Mar 2013, at 12:29, Damon Hart-Davis wrote:
>> 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.
>> 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 ?
>>> OpenTRV-dev mailing list
>>> EMAIL ADDRESS HIDDEN
>> OpenTRV-dev mailing list
>> EMAIL ADDRESS HIDDEN
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
More information about the OpenTRV-dev