[OpenTRV-dev] Feedback Mechanisms.

[Jack Kelly]

Thomas wrote:

*The commercial systems can be divided into those that only control
> radiator valves and those that also control boilers and other heating
> system components. ..
> The second kind of system is very difficult to make and involves much
> higher risks since the system might either run the boiler with all
> radiator valves closed (which could damage the boiler if it hasn't
> been installed properly) or might fail to switch on the boiler during
> extreme cold (allowing plumbing to freeze).*
>

I think the system becomes relatively straight forward if we adopt some of
the simplifications that have been mentioned in discussions.  I've almost
certainly got this at least slightly wrong (!) but I think the rough system
design inferred from the discussions looks something like this:

*Boiler control*
The boiler simply responds to rooms calling for heat.  The boiler doesn't
have its own schedule.  The boiler is off if no rooms call for heat (hence
shouldn't damage itself if the heating engineer forgot to install a
bypass).  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)

*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).  Making the TRV responsible for deciding when to
call for heat also minimises the amount of time it needs to use its radio
(in comparison to a central controller taking responsibility for making
heating decisions: if a central hub queried each TRV for its temperature,
compared that temp to a central schedule and then commanded each TRV to
open/close then that would result in more RF usage (and hence battery
usage), I think)

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

MQTT is a prime candidate for the RF message format.

*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 - although people have suggested that convection currents mean
that the TRV's temperature sensor actually measured a remarkably accurate
room temperature)

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

Please, please shout if any of this is wrong.  Just trying to paint an
overall picture for Thomas (and myself!).

Thanks,
Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20130325/915047b2/attachment.html>