[OpenTRV-dev] Feedback Mechanisms.

[Thomas Hood]

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.

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.


> 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.

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".

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.
-- 
Thomas