[OpenTRV-dev] Feedback Mechanisms.

[Damon Hart-Davis]

Hi,

I think that what you says makes sense.

I'd like to repeat that though putting intelligence in the TRVs is my current preference for my situation, I am not of the opinion that it's the only good model in any way shape or form.  If we were to deploy this in a school or large house then secure remote control over tens or even hundreds of rads might be a much better bet for example.

I think that the spilt/unified TRV (ie whether the sensor is in the box on the valve) is very much a matter of taste and individual circs as is wired/unwired and battery/mains.  None of those particular alternatives should be very hard to accommodate, not to mix and match in one household.  I see the movement of brains of the TRV as harder, but not much with reliable and secure comms.  (Maybe we could signal acoustically through the pipes with ultrasound!)

Rgds

Damon


 
On 25 Mar 2013, at 13:49, Jack Kelly wrote:

> 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
> 
> 
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev