[OpenTRV-dev] Fwd: Control Strategies

[Damon Hart-Davis]

For the record (email addresses zapped):

Begin forwarded message:

> From: Damon Hart-Davis
> Date: 15 March 2013 11:22:13 GMT
> 
> Subject: Re: Control Strategies 
> 
> Hi,
> 
> On 15 Mar 2013, at 10:54, Stuart Poulton wrote:
> 
>> Hi All,
>> 
>> I'm interested what people are thinking about control strategies, and have a couple of observations.
>> 
>> - What decides the when the room has reached a setpoint ?  I'm wary of using any temperature sensor within the TRV itself, as it's not representative of the room temperature, purely the temperature at the TRV which is likely to be warmer than the room as a whole
> 
> Apparently, stron convection currents around the radiator make the temperature at the TRV more representative than you might imagine.
> 
> But of course, if we are wirelessly controlling the TRV the sensor can be (with the rest of the circuit) anywhere, which is the situation that I have now.
> 
> Also, we have provision to have a remote wired sensor that could be placed a small distance from the TRV unit.
> 
> At the moment mechanical TRVs with the sensor near the rad seem to work reasonably well, so you might be overthinking the plumbing.
> 
>> 
>> - Do any of the TRVs being discussed (not hacked ones) report they're local temperature, and battery state, the later being key to a high WAF, I want to know when I need to replace the battery.
> 
> I can't tell if the i30 does/can, but I hope it might.
> 
> Note that OpenTRV valves should be powerable by mains (small and efficient USB phone chargers) where there is a socket nearby, eliminating the battery issue entirely in that case.
> 
> Announcing battery state seems like a good idea.
> 
>> 
>> - 2 approaches
>> 	a - Send the TRV a setpoint, this then uses a PID loop to control valve position and temperature.
>>       b - Send the TRV a valve position from a central controller. Feedback provided by room sensors that can be sensibly located.
> 
> I'd like semi-autonomous (Open)TRVs to be possible in the scheme, either with the simple 'warm' or 'frost' local control as now, or a simple local temp/time schedule, in each case with the ability to demand heat from the central heating system.  (I already implement valve slew limiting and seem to get <0.5C temperature wobble, BTW.)  At worst if they can't call for heat for some reason they gracefully degrade to be an i30-alike.
> 
> Thus the (Open)TRV version that I am describing is not sent either a setpoint or a position, but just calls for heat when not meeting target from its internal setpoint(s).  To be clear: the (Open)TRV that I have in mind can itself either be one unit or split, with the sensor(s) and UI potentially separated from the valve head, but I'd like to see at least one unit combining both for minimum domestic clutter.
> 
> Both the suggestions that you make are also viable, clearly, and many other ways of moving the smarts around and integrating with home automation, remote control over the Net, etc, remain possible and interesting.
> 
>> - Need to consider boiler control, typically replacing the thermostat 'call for heat' input. 
> 
> And I'm not attempting any sort of modulation a la OpenTherm yet.  We should.
> 
>> Have to admit PID's loops in HVAC are well fun. You have to account for things like surges of hot / cold water round the system.
> 
> My current simplistic slew limiting and so on seems to work fairly well, though I'm sure it can be improved.
> 
> Again, and I'm very happy to be proved wrong, to avoid overthinking the plumbing I think that it has to be accepted that system controllability is not going to be perfect and the primary issues to consider are the thermal response time of the heating system room (eg to minimise overshoot) and weather compensation (to keep up with increased heat loss more smoothly on cold days).  One further possible idea discussed in a number of places including the DECC workshop was the idea of some supplementary instant radiant heat (eg electric resistance heating, yes even given my normal reservations) while a room is warming up more generally to improve perceived temperature and comfort.
> 
>> Anyhow, food for thought let me know if you've got anything to add.
>> 
> 
> Again, we should be having this conversation in public where it can be seen.
> 
> Can we possibly agree on a shadow GitHub discussion project or something ASAP, or move it to the SF discussion area (though I think that it may be poorly spidered and I may not be able to back it up easily)?
> 
> Rgds
> 
> Damon