[OpenTRV-dev] Feedback Mechanisms.

[Mike Stirling]

Hi all,

I haven't had time to read thoroughly, but there are a couple of points 
I wanted to throw in:

- Anywhere there is more than one possible UI they MUST be in sync at 
all times.  There is no technical reason why this can't happen.  If the 
central controller decides it has lost comms with the TRV then both ends 
of the link will know this and can make it clear to the user.  If the 
TRV is falling back to local operation in this situation then the 
central controller should disable remote control of that node altogether 
(and flag it as an error).

- The radio protocol needs to be secure from the outset, as 
feature-creep is inevitable.  With crypto/authentication you either 
engineer it properly or you don't bother.  Too many proprietary sub-GHz 
protocols don't even get the addressing right, e.g. there are plenty of 
wireless doorbells on the market where you can select from 32 different 
tunes but only 1 address!

Mike


On 24/03/13 11:27, Damon Hart-Davis wrote:
> Hi,
>
> I think it is important to realise that there is probably no one correct configuration, and each household and user will have different wants and needs.
>
> My partner is utterly against controlling the heating by computer, even her tablet, even from just in the house.  A sociology professor tells me she is completely hooked on the idea of being able to turn on the heating before she leaves work.
>
> So I must necessarily disagree with some of your assertions below, ie given the assumption that there must be a control panel that things might be debugged from.  I don't disagree with the virtues of being able to debug from such a panel, but such a panel is not appropriate in every household IMHO.
>
> Indeed would I not want the TRVs in my house necessarily leaking/broadcasting anything other that a minimal call for (central) heat or downloading code other than from a local hardwired connection to finesse most of the security issues that Mike rightly brings up.  In situations where we have decent auth/enc that may be less of an issue.
>
> I *do* agree that some or all of the things that you describe would be nice to have in some circumstances, and that we should strive to make them possible.
>
> On 24 Mar 2013, at 11:06, Thomas Hood wrote:
>
>> 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.
> In the current prototype frost/warm modes last indefinitely just as if you had adjusted a local mechanical TRV, but my boost/bake mode is time-limited.  There is no schedule at the moment.
>
>> 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?
> In my current prototype there is no control panel (one node does double-duty as boiler controller), so the issue does not arise.
>
>> * 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"?
> No downloading.  The current prototype can have new code (containing a new schedule) downloaded into it via a local (USB) connection.  Work is in hand on being able to set a schedule and the time via that same connection.
>
>> * 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 of the reasons for keeping things simple is to avoid that sort of second-order problem.  By slew-rate limiting I am avoiding significant overshoot anyway, and temperature is regulated to within a band of ~0.4C for the instances that I currently have deployed, which seems acceptable to the occupants.
>
>> 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.
> Only for deployments where a central control panel is appropriate.  The almost completely distributed model that I am currently using seems one worth continuing to support IMHO.
>
> FWIW, the UK's appliance manufacturers' association is split down the middle as to whether homes should have a central energy management console in the home.  I think that OpenTRV should be agnostic on this issue and support models with and without.  I can see pros and cons on both sides.
>
> Rgds
>
> Damon
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev