Retrofit completely-open reference mechanical/hardware/software design for zoned heating control...
OpenTRV sets out to make it easy to save lots of energy by only heating rooms that you're using, and by no longer trying to use a single thermostat to get your whole house comfortable.
Heating accounts for around 60% of UK domestic energy use and 60% of people admit to heating unoccupied rooms. [p2 DECC 2012 2323, p33 DECC 2012 6918]
OpenTRV also allows a simple schedule to be set (no complex displays though!) and tries to anticipate when you'll need heating to improve comfort while boosting efficiency.
OpenTRV is designed to be simple to (retro-)fit to existing UK housing stock with radiator central heating.
Here are some key design principles behind OpenTRV:
Open source projects are said to work best when they really scratch an itch, ie fullfil a requirement or deal with an irritation, that nothing else works for.
As of the start of 2013 I had been trying to put together some electronic/programmable thermostatic radiator values/controls (TRV/PRC) that can follow a temperature programme against time (chronostat), individually call for heat (ie fire up) the central heating boiler when not meeting targets, and that have an occupancy sensor that can drop the target temperature a couple of degrees when a room is (unexpectedly) not occupied (or at least has no active awake human in it).
Why? At the October 2012 DECC smart heating workshop that I presented at there was wide agreement that the ability to retrofit soft heating zones to existing radiator central heating systems would likely be a good thing with a lot of potential to save heating un occupied spaces, and set appropriate heating levels in occupied areas too, with the potential for a lot of energy savings for little physical upheaval. That implies thermostats per heating zone, possibly even per room, controlling local TRVs to regulate temperature and able to bring on the boiler ("call for heat" or "boiler interlock" are common terms) if any zone needs heat to meet target. Modern building regs in England require at least two zones; this proposal is finer-grained.
In any case, this seemed hard to do, especially the occupancy sensing, and even a couple of major well known manufacturers that I've been talking to that that offered to lend me kit to test or tell me their hardware protocols, have not yet managed to do so.
There seems to be little that operates satisfactorily with fully-open protocols (sometimes a subset of functionality is available, but not enough, or not reliably) so that, for example, I could couple the system with a home automation system or my server or whatever.
The primary aim of the OpenTRV project is to have an unencumbered open design from boiler to rad of which pieces can be substituted at will, eg if cheaper. Licensing is permissive so that existing manufacturers can use our designs, and also so that "makers"/DIYers can use the tech easily.
And all of this is to try to make it easy and cheap and pleasant for everyone to save carbon emissions from heating: I think most people in the UK could halve theirs without hardship, and the UK has crappy housing stock and will for many years to come.
As of autumn 2013 we had working PICAXE and Arduino/AVR implementations, with REV1 and REV2 boxed instances of the AVR solutions deployed in multiple households for testing over winter 2013--2014.
There are twin primary aims for this year:
Tasks in green are key, tasks in yellow are intermediate.
Initials in bold are for participants who have expressed an interest in helping with the given task, others are merely my suggestions! The first initials indicate the suggested task lead.
Bolded end dates indicate completion.
|Tag||End Date||Who||Research Element / Description|
|V0.2-Numbers||2014/06||DHD / BG / 1xStudent||Gather and analyise results from V0.2 trial to assess OpenTRV efficacy. Research questions: does OpenTRV work and how well if so, OpenTRV vs mechanical efficacy (is the extra complexity worthwhile over a blob of wax), OpenTRV vs simpler control system user experience?|
|V0.2-Branch||2014/05||DHD / MH / 3xStudent||Initial branch of V0.3 and V1.0 designs from V0.2 with aim to be able to share code (eg libraries), have good automated unit and integration suites with maybe automated hardware lab for V0.1 PICAXE, V0.2 (REV1, REV2), V0.3 and V1.0 lines, eg testbed / oven / etc. Research questions: how much testing can be automated in software and hardware, can this be turned into a Continuous Integration system for s/w and h/w, (how) can PICAXE/Arduino environment be pushed this way, can it be done cheaply, can it be made avaiable to all team members, eg hosted centrally?|
|V1.0-Stds||2014/05||DHD / MH / BH / 1xStudent||Initial pass to make sure that V1.0 design is RoHS and CE ready (and doesn't violate any USB specs), and adjust.|
|V1.0-BoilerRelay||2014/05||DHD / MH / BH||Formalise and optimise thermostat/relay boiler control design.|
|V1.0-Radio||2014/05||MS / DHD / 2xStudent||Select replacement (RFM69?) for RFM22/RFM23 radio for battery power (and FHT8V control), may be needed for V1.0 as well as V0.3. Develop code for replacement and check interopt with existing code and other interesting systems such as OpenEnergyMonitor/RFM12. Research questions: is substitute available/suitable (eg battery powered), is interop with RFM22/23 and FHT8V possible, is interop with third-parties (eg OEM) easily possible, should other ISM frequencies be considered, what legislative constraints in UK and wider EU need to be met for CE?|
|V1.0-PreProd||2014/07||DHD / MH||Minimum cost stripped-down production design (valve/boiler units), taken through initial CE testing and production, and marketing channels/brand/co-brand, etc established.|
|V1.0-Prod||2014/09||DHD / MH||Initial production run with items ready for retail sale.|
|V0.3-HeatPump||2014/06||BH / DHD / 1xStudent||Use BH's PIXACE DHW and AVR rad system as test-bed for heat-pump and district heating systems with slower time-constants (eg higher thermal mass, and significant short-cycling limits) and stricter flow contraints. In particular minimise BH's bills! Research questions: can OpenTRV be easily extended to cover district heating and heat-pumps easily and what changes are they, are the same changes needed for both, can we see savings in cost AND energy after changes?|
|V0.3-DS18B20||2014/16||KW / DHD / 1xStudent / BH||Support DS18B20 on AVR with Apache 2.0 code. Research questions: what problems are there if any (voltage, power, conversion time), how might DS18B20 be fitted into V0.2/V0.3 system design, what benefits are there of DB18B20 over TMP112?|
|V0.3-Sensing||2014/11||DHD / BH / MS / 1xStudent||Other improved temperature and other core sensing, including other temperature sensors such as DS620. Research questions: what (non-occupancy) parameters should we be sensing (incl temp), what low-power cheap devices would work with V0.3/AVR, what devices might work better with other MCUs (eg M0+) such as voice, what devices can we easily code up support for?|
|V0.3-DD||2014/10||BH / DHD / 3xStudent||Dynamic demand sensors and boiler-hub integration, from plug-in and clamp-on sensors to simple optical devices to observe flashes from import and generation meters or similar. Limit: peak flow, demand when grid freq drops, demand when importing. Have DD plug-in unit inject (say) X-10 like marks at voltage zero-crossing and have inductively-powered current clamp time those wrt to current flow and thus compute and TX power flow direction/size, plus also maybe low-frequency alert. Research questions: can simple cheap practical accurate-enough DD sensors be made (eg import/export for typical UK single-phase import + PV gen meters, with no socket near the consumer unit) to actually help the grid including mains frequency monitors, what's the patent landscape like, what's the estimated 'virtual generation' from each DD-equiped heating system (gas combi or electric heat-pump or other)?|
|V0.3-BoilerCtl||2014/11||DHD / BH||At least one different boiler control different to DHD's (binary) 2-wire 240V SSR and 240V/24V relay-based mechanical thermostat replacement.|
|V0.3-Power||2014/10||DHD / BH / 2xStudent||Various options for powering OpenTRV leaf and hub and bridge nodes, from energy scavenging eg solar PV or boiler 2-wire stat sense current or thermal gradients, inductively-powered current clamp (eg for DD), to built-in battery charging, 1 or 2 or 3 A NiMH or Li or supercap, micro USB phone charger, mechanical (eg from shaking a unit), last-gasp handling, making these interchangeable and economical. Research questions: what are the options, what is in the published research and what's in use in the real world, what is the patent landscape?|
|V0.3-OccupancySensing||2014/11||DHD / BH / 2xStudent||PIR, voice, microwave doppler, mobile-phone signal proximity, etc.] Research questions: what occupancy parameters should we be sensing, what low-power cheap devices would work with V0.3/AVR, what devices might work better with other MCUs (eg M0+) such as voice, what devices can we easily code up support for?|
|V0.3-Sec||2014/10||MS / DHD / 1xStudent||Progress on encryption and authentication in situations where required, and to facilitate more/alternate ergonomic functional splits safely/reliably. Research questions: where are appropriate functional splits to support OpenTRV enineering constraints such as low power and graceful degredation and autonomy and lack of need for Internet while meeting auth/privacy goals, what's out there, how can we use our MCU (AVR?) and radio modules to best effect, how can we keep our results portable to new hardware and problems?|
|V0.3-Protocol||2014/10||MS / BG / DHD / 2xStudent||Progress on over-the-air and over-the-Net protocol (eg MQTT/UDP[/VPN]) including two-way working (eg control from hub/Internet) and conveying other stats for energy monitoring / home automation, and gatewaying to Internet, and ability to interop with other protocols systems (eg OEM). Research questions: where are appropriate functional splits to support OpenTRV enineering constraints such as low power and graceful degredation and autonomy and lack of need for Internet while meeting auth/privacy goals, what's out there and how to they compare to Mike's protocols, how can we use our MCU (AVR?) and radio modules to best effect, how can we keep our results portable to new hardware and problems?|
|V0.3-OEMInterop||2014/10||DHD / KW / BH / 1xStudent||Basic interop with OpenEnergyMonitor radio/protocol/systems with a view to avoiding duplication of effort, and easily combining energy reduction with monitoring. Research questions: what are the elements that would be most useful to combine, can it be done effectively in constraints of V0.2/V0.3 system, what changes should OpenTRV make to improve the outcome?|
|V0.3-OtherInterop||2014/10||DHD / 1xStudent||Basic interop with other protocols/media such as HomeEasy, X-10, EnOcean, hand-held IR remotes, to make use of existing peripherals and controllers, and to plug into home-automation gateways. Research questions: what are the elements that would be most useful to combine, can it be done effectively in constraints of V0.2/V0.3 system, what changes should OpenTRV make to improve the outcome?|
|V0.3-Learning||2014/10||DHD / 1xStudent||Learning (occupancy/usage/performance/etc) algorithms to maximise comfort and minimise energy use, to 'delight' the user while cutting their footprint. Research questions: what can we adapt from research and current practice, what's the patent minefield like, what evidence is there to support what maximises results above, what stats would we need to gather, what can be coded up for AVR in V0.3 simply?|
|V0.3-Hub||2014/09||DHD / BH||Progress on design of hub/bridge (beyond V0.09/V0.1/V0.2 dumb boiler node) to interoperate with V0.3 (h/w and s/w) nodes, using V0.3-Protocol.|
|V0.3-AllInOneMech||2014/09||BG / PC / DHD||Robust (good for one heating season) all-in-one TRV housing and mechanics including valve-driver using V0.3 h/w, and assuming common UK vertical M30x1.5 fitting.|
|V0.3-MinCost||2014/09||DHD||Minimum cost stripped-down reference design (valve/boiler units and hub/bridge ansd Web app) for third-party manufacturers as basis of retail product, interoperable with dev-friendly V0.3 designs, probably using same peripherals and code base, capable of 5V (wired) or battery or energy-scavenging operation.|
|V0.3-Cloud||2014/09||BG / MS / DHD / BH||Ability to push readings, etc, to cloud and monitoring sites such as EnergyDeck.com. Includes protocols and server-side spec.|
|V0.3-AllInOne||2014/10||DHD / BG / PC||Robust (good for one heating season) all-in-one TRV based on V0.3 h/w and s/w stack and mechanics/box.|
|V0.3-ARM||2014/11||DHD / MS / BG||Explore other MCUs/CPUs such as Cortex M0+ ARM for OpenTRV designs.|
|V0.3||2014/10||DHD||Umbrella task for initial V0.3 implementations h/w and s/w, and split and/or all-in-one TRV unit with valve driver mechanics, plus hub/bridge, good enough to trial in end-users' houses.|
|V0.3-Deploy||2014/10||DHD / BH / BG / MF||Test deployment to 10s of homes for testing.|
|EfficacyStdStart||2014/10||DHD / 3xStudent||Get underway development of FOSS standard consisting of computer model and physical model for testing and rating UK home heating energy-saving controls, eg vs new-build building-regs-mandated controls and typical real housing stock, for a mix of typical usage patterns and behaviours. Ultimate aim is to be able to provide A--E energy sticker to help consumers choose best product for themselves. Research questions: what existing research can we lean on, what types of UK housing stock should be modelled, what occupancy/usage patterns should be modelled (eg from young family though teens to careful elderly), how could computer model be made useful and accessable to help initial development eg by smaller firms, how would physical model be constructed and used (eg for different typical UK house types), what parameters should be measured, how should results be measured/validated, how should results be presented for engineers end end users?|
The V0.2 design (as the V0.09 design also) works as follows:
OpenTRV will work better if it can interoperate easily with other open and proprietary systems in the heating and monitoring area, eg Open Energy Monitor and various home-automation (HA) systems.
OpenTRV was conceived for the typical UK combination of gas boiler plus radiators plus limited heating controls.
Bo H as of 2013/05 is using (PICAXE V0.1) OpenTRV to control his domestic hot water (DHW), and hopes to control his radiators too, that get their heat from the local district heating system, which is partly why he joined in with such gusto getting our first PCB layout together! (With the TRV slew rate turned right down, it seems to be working well for him at V0.1-operational tag with tweaks, saving ~33% but not keeping water hot pointlessly overnight.)
If we have this right then we can save people a lot of work redeveloping their own easy-to-program low-power reliable sensor platform.
Voice detection for occupancy sensing seems like a nice thing to do. Most of the energy in human voice is in the range of 100Hz--2kHz (100Hz fundamental for adult males to 200Hz for women and children, plus 1kHz major format/resonance). (Thanks to Dan Stowell for this and other help!)
If the system autocalibrates general background levels over time (the V0p2 code is able to keep exponentially-decaying averages by hour of day) for minimum and maximum, then this may become quite practical. The cadence of the sound may also help with rejection of false positives.
We can do more subtle things such as reduce OpenTRV motor movements at quiet moments.
We can consider a sample of Radio 4 to be an almost perfect proxy for normal speech that we would want to regard as indicative of occupancy, TV and talk radio and music and pets as less so because of significant audio processing or different energy/frequency bands for example.
A cheap and nasty piezo transducer may do for input and may conceivably allow energy harvesting from the same signal. (Intensity = 10^-12W/m^2 * 10^(dB/10); conversational speech has a sound level of 65 dB, implies ~3x10^-6W/m^2 which is within the bounds of possibility.)
This is an attempt to define some commonly-used terms in OpenTRV to avoid confusion: please send in corrections as needed!
A wiki superset is also available.
OpenTRV and associated/halo projects are all about interoperability and to that end we will use or create 'standards' where necessary.
From REV1 of the V0.2 OpenTRV PCB (and REV0 of DD1), we have settled on a main PCB size of 50mm by 50mm with 3mm (M3) mounting holes inset 1mm from each edge at the corners. Standard PCB thickness is 1.6mm. This is in part at least to enable a standard box/enclosure design to be adopted across all units. See for example this from the SVN repository.
All OpenTRV software and hardware designs are licensed permissively, specifically to encourage manufacturers to incorporate elements they find useful to encourage wide adoption, along with research and hobby/DIY use.
As of March 2013 everything was covered by an Apache 2.0 licence. All new hardware design elements thereafter will be under the Solderpad licence which better addresses some of the non-code IP issues. Note that Solderpad-licenced elements can be treated as if licensed under Apache 2.0 if preferred, as the latter is OSI approved.
DHD2013/04/17: broad licensing policy after discussion with Andrew Katz, a lawyer involved with the creation of the Solderpad (0.51) licence, a variant of Apache 2.0 that deals with some of the legal/IP issues beyond copyright and patents that Apache addresses:
The machine that serves this site is powered by local off-grid solar and wind renewable energy as far as possible, backed up by on-grid renewables including as of 2008/03 a substantial grid-tie solar PV system, and 100% renewable grid power (mainly wind) from Ecotricity; power draw is ~1.5W.
Please email corrections, comments and suggestions.
Copyright © Damon Hart-Davis 2007-2014.