[OpenTRV-dev] Fwd: Control Strategies

[Damon Hart-Davis]

For the record from yesterday...

Begin forwarded message:

> From: Philip Canavan
> Date: 15 March 2013 13:38:56 GMT
> Subject: Re: Control Strategies
> 
> I largely agree with the idea that we shouldn't be prescriptive, but I do think we need to consider the constraints of the scenarios we want to support. I see the whole battery\powered argument as largely a vendor issue, but since battery puts design constraints on power we should design for battery. Similarly wireless\wired and bandwidth\connectivity. There will be other examples we'll come across.
> 
> I want to add 2 things to the vision discussion. Firstly, modulating boilers will adjust power to retain either a feed or return temperature, but that misses efficiencies. I'd like to always have one valve fully open, and drop the feed temperature to achieve that. I'd also like to ramp output temp (gradually) when the water cylinder is heating (possibly above any temp constraint for heating demand). I think both will improve boiler efficiency (and pump power draw, slightly), and would be a USP of an integrated system.
> 
> Secondly, if we are prepared to assume a powered hub whenever the 'modules' aren't stand-alone then a lot of the timing issues go away & we can always have clients initiate the comms. I too would like to see valve broadcast local temp (if available), valve position, battery status and setpoint (if relevant). If the valve supports setpoint then the hub could reply with an updated setpoint and the 'official' room temp; both sides can then do temp sensor calibration if they want. If the valve doesn't support setpoints (ie is dumb) then the hub can just reply with a valve position. Either way, if the valve loses connection it can just keep doing what it was told. I guess if the initial sync declared capabilities on every node then you could support schedules similarly. It would probably imply a block-based message.
> 
> Simplicity? I've heard of it.
> 
> 
> Damon Hart-Davis wrote:
> Yes, indeed, I think you have it right.
> 
> There are many good ways to slot this stuff together, for normal human being house owners and us geeky tinkererererers.  It isn't rocket science (unless you block up the emergency pressure-release valve.)
> 
> I have selfishly concentrated on my own house for the initial design because it is a real concrete deployment to use/evaluate, and scratching my own itch works for me!
> 
> I think that the key will be something like having a bunch of interchangeable functional elements in the chain from rad/UFR to boiler (and networked to HA, etc, as appropriate) with a number of alternatives for each element (eg PICAXE or ATmega boards, reference or commercial h/w, reference or open protocols, etc) and wired or wireless connections.  With the small CPU/energy budgets likely to make sense, we have to get the abstractions right and keep them simple,
> but it should be possible.
> 
> (I've just effectively re-engineered the concept of libraries back into the PICAXE for example!)
> 
> DECC is interested in OpenTRV and we may get into its next round of technology evaluation; it has at least asked me to help with the coming review.  And one big TRV supplier would like to be our friend and agrees with my view that getting this right is not a threat to them but expands the market instead.  We're doing some things right.
> 
> Note that we have a Case Studies page for deployments: this may be one place to outline the "working examples" you describe, with simple pictures, etc.
> 
> Rgds
> 
> Damon
> 
> PS. I'm working on the item for Automated Home that's been in the offing for a while.  I hope to get it done, or nearly so, today.  If anyone would like sight of it, please say.
> 
> 
> 
> On 15 Mar 2013, at 12:04, Stuart Poulton wrote:
> 
> > Ok.
> > 
> > Whats becoming
> clear here is that we all have pre-concieved ideas of how something like this should work. In my mind they are all perfectly valid. The key to creating a bigger community is to amass knowledge, and have working examples, for example
> > 
> > FHT 8V controlled by a RF unit
> > PICAXE boiler controller
> > 
> > i30 with standalone operation and RF re-programming
> > 
> > AVR & RPi based solutions, temperature and window / door sensors.
> > 
> > Lets build a toolkit of hardware and software, and allow people to use these to build a solution. It worked for arduino, it worked for RaspberryPi, it WILL work here.
> > 
> > Stuart
> > 
> > 
> > On 15 Mar 2013, at 11:51, Damon Hart-Davis wrote:
> > 
> >> Just a note on the wires:
> >> 
> >> One solution will not suit every situation: wired power but wireless almost-everything-else would suit me best for example, but
> Wookey's entire house is wired already and having batteries run out has been a nuisance for their household.
> >> 
> >> So the aim should be to allow a mixture of wired and wireless without bumping up cost or complexity.
> >> 
> >> The current V0.09V hardware 'boiler control' can be wired back to the boiler (or drive a local valve by wire) easily, by design, for example.  I had Wookey in mind.
> >> 
> >> My boiler does indeed modulate one return temperature which is why on/off control works fine for me, but OpenTherm allows a little more finesse in theory.
> >> 
> >> Rgds
> >> 
> >> Damon
> >> 
> >> 
> >> On 15 Mar 2013, at 11:40, Mike Stirling wrote:
> >> 
> >>> See below...
> >>> 
> >>> ----------------original message-----------------
> >>> From: "Damon Hart-Davis" 
> >>> Date: Fri, 15 Mar 2013 11:22:13 +0000
> >>>
> 
> >>> 
> >>> 
> >>>> 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.
> >>> 
> >>> Any wires at all would have a very low WAF in my experience. Of course with the current design there is nothing preventing the valve from talking to a remote sensor - that was my original architecture
> anyway.
> >>> 
> >>>> 
> >>>> 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.
> >>> 
> >>> Again, wires = low WAF.
> >>>
> 
> >>>> 
> >>>> Announcing battery state seems like a good idea.
> >>> 
> >>> The ELV one does announce battery state by beeping on low-battery when it receives a transmission with a particular flag bit set. This bit is set in messages from the thermostat but only at certain times of day, preventing it from beeping in the middle of the night.
> >>> 
> >>>> 
> >>>>> 
> >>>>> - 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.
> >>> 
> >>> Taking the Comet/i30 model as a basis, I'd like something that does that but with a remote override capability. The central controller should be able to:
> >>> 
> >>> a) Poll for current temperature/valve position/battery voltage
> >>> b) Push out a schedule
> >>> c) Force a particular target temperature
> >>> d) (maybe) perform remote firmware updates
> >>> 
> >>> If a remote sensor is in use then it would be nice if the valve could act on this directly, although protocol crypto issues (which I have been thinking about) may necessitate the use of a central
> controller if you want anything other than a bog standard digital TRV. I don't see this being a big limitation as the typical use-cases are likely to be either a simple "dumb" installation or a full one with HA integration and remote control, the latter requiring the central unit anyway.
> >>> 
> >>>> 
> >>>>> - 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.
> >>> 
> >>> Don't most modern boilers modulate based on the return temperature, which would be directly related to the total demand anyway?
> >>> 
> >>>> 
> >>>>> 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
> >>> 
> >>> --
> >>> 
> >>> 
> >>> 
> >> 
> > 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20130316/ecb949ca/attachment.html>