[OpenTRV-dev] Feedback Mechanisms.

[Damon Hart-Davis]

Hi,

See some comments below.

On 25 Mar 2013, at 15:04, Thomas Hood wrote:

> On Mon, Mar 25, 2013 at 2:49 PM, Jack Kelly <EMAIL ADDRESS HIDDEN> wrote:
>> Boiler control
>> The boiler simply responds to rooms calling for heat.
>> [...] The boiler is on if one or more rooms call for heat.
>> (For future iterations: there are lots of optimisations to this model:
>> minimising return temps to keep the boiler condensing for as long as
>> possible, modulating the boiler using OpenTherm etc etc)
> 
> The boiler controller will need information for this purpose. I saw a
> report (unknown reliability) that Honeywell Evohome regulates the
> boiler based on how far open the most open valve is. It seems that
> TRVs should at least report how far open their valves are.

I have no objection to doing that (and the information would be available the way that I am currently doing it) but my boiler control is binary (thermostat calls for heat or not as originally set up) and the boiler internally modulates depending on the return temperature IIRC, ie to keep a constant flow temperature without cycling.

> 
> As additional efficiency can be achieved by modulating the circulation
> pump, information could also be provided that would allow that to be
> optimized. TRVs could report their temperature programs, current
> temperature and radiator characteristics.

Again, with my ageing system, there is no separate control over the pump (it is inside the boiler) and the boiler manages over-run etc.


>> Room TRVs
>> Damon is keen to keep the temperature decision making in the TRV.
>> TRVs will store a basic temperature schedule and have a temperature sensor,
>> a basic display (perhaps just some LEDs) and a small number of buttons.  If
>> the room is colder than the target set point then the TRV opens its local
>> valve and calls for heat from the boiler (subject to hysteresis / slew rate
>> limiting / PID control).
> 
> Undoubtedly temperature control should be done by the TRV. If there is
> any kind of central control module, it shouldn't be in the control
> feedback loop. The system should remain fully operational if the
> central control module is absent or offline. The central control
> module is there for programming and for monitoring the TRVs. (By
> 'programming', here I mean: setting the temperature targets and
> times.)
> 
> TRVs should keep logs of their actions, so that if the central control
> module is offline for a while then log information isn't lost.

Again, I say not in all cases.  Why wear out an EEPROM for cases where people aren't going to care?  B^>

I suspect that lots of OpenTRV systems might be fairly dumb upgrades to the existing mechanical TRVs, with the main benefits of:

 1) central call for heat.

 2) a *very* simple schedule operable with a single button (eg cancel the program or repeat on for an hour from *now* every 24h).

No central unit (other than a boiler control which may also double as a TRV as in my case), no Internet bridge, no HA!  My in-laws don't even have Internet connectivity for example, but might conceivably be happy to take the simplest OpenTRV.

> Another issue is coordination. Suppose for example someone wants to
> implement a "turboboost" feature which works as follows. I press the
> Turboboost button in the bathroom; the bathroom TRV sets the
> temperature to the "turbo-comfort temperature" and opens its valve
> fully; the boiler is run at maximum power; other TRVs close partially
> in order to give the bathroom more heating water. The details of this
> example don't matter. The important thing is that this feature
> requires coordination of the various components. How should this
> coordination be achieved? Presumably the components should handle this
> themselves and not rely upon a central control module to coordinate
> things. TRVs et al should be "agents".

A situation that does already arise, eg in systems such as Honeywells' I believe, is to coordinate the TRVs going on and off to maximise boiler efficiency.

But I suspect that may of these are second-order issues that should not worry us unduly until we have the first-order issues sorted.

> Another case where coordination might be needed is where a room has
> multiple radiators. The expected temperature increase depends not only
> on a TRV's own valve but also on the setting of the other TRV's valve.
> Such TRVs could use each other's temperature readings and perhaps
> average them.
> 
> There would be a stronger sort of interdependency in a heating system
> with serial radiator strings. When one valve opens it causes the feed
> temperature for another radiator to decrease. Presumably TRVs on such
> radiators should coordinate.
> 
> 
>> If another device wants to get / set the state and schedule for the TRV then
>> it can poll the TRV [although this implies that the TRV's radio is always
>> ready to RX, which may use too much power???].  But the TRV's schedule is
>> the authoritative one (this is a simple way of avoiding any problems with
>> synchronising UIs: just store the schedule in one place only!  (perhaps with
>> a cache / backup kept somewhere else)).
> 
> Well, each TRV will have a target-temperature program and that is
> authoritative by virtue of its being the one that will actually be
> followed. :)
> 
>> Room thermostats (optional)
>> I think some people are eager to have separate "thermostat" / controller
>> units in each room (at least partially because the temperature sensors on
>> the TRVs may not sense the correct temperature because they're so close to
>> the radiator
> 
> Another reason is that the TRVs are not always very accessible; room
> thermostats serve as local remote controls for TRVs.
> 
>> "IP Bridge" (optional)
>> For those folks who want such a thing, there could be a separate device
>> which connects the heating RF network to an IP network, hence enabling
>> control over the web / mobile phone / tablet etc etc etc.
> 
> Ideally this bridge would be the same thing as the central control
> unit we have been talking about. There are many reasons for wanting a
> central control unit to be accessible via the LAN. I guess the problem
> is that there is not always an Ethernet port and/or good Wi-Fi
> reception and a power outlet at the location where the homeowner would
> most like to have the control panel.

I think that there will be occasions where a central controller is required, but no Internet bridge, eg I may not want any remote control, or I might want to hook into my HA system but no further or the HA system may do the bridging.

Rgds

Damon