Thomas wrote:<br><br><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><i>The commercial systems can be divided into those that only control<br>
radiator valves and those that also control boilers and other heating<br>
system components. ..<br>
The second kind of system is very difficult to make and involves much<br>
higher risks since the system might either run the boiler with all<br>
radiator valves closed (which could damage the boiler if it hasn't<br>
been installed properly) or might fail to switch on the boiler during<br>
extreme cold (allowing plumbing to freeze).</i><br></blockquote><br>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:<br>


<br><b>Boiler control</b><br>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.<br>


<br>(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)<br><br><b>Room TRVs</b><br>

Damon is keen to keep the temperature decision making in the TRV.<br><br>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)<br>


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

<br>MQTT is a prime candidate for the RF message format.<br>
<br><b>Room thermostats</b> (optional)<br>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)<br>


<br><b>"IP Bridge" </b>(optional)<br>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.<br>

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