Earth Notes: Open-Source Thermostatic Radiator Valve (OpenTRV)

Retrofit completely-open reference mechanical/hardware/software design for zoned heating control...
TRV

Executive Summary

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.

Design Principles

Here are some key design principles behind OpenTRV:

  • OpenTRV's primary target is UK housing stock already standing, with poor thermal efficiency, and gas-fired central heating with radiators, for which it aims to cut space-heating carbon footprint by 50%, and in many cases repay its cost in a single heating season.
  • Basic OpenTRV systems should be cheap (quick payback, 10+ year life) and simple to retrofit by end-users.
  • OpenTRV should not require the Internet or smartphones to operate; it should be possible to do basic operations with a simple UI physically at the radiator or its associated control unit.
  • OpenTRV systems should gracefully degrade.
  • OpenTRV intends to produce permissively-licensed free open reference designs suitable for large manufacturers to produce at low cost.
  • OpenTRV intends to keep some or all of its designs suitable for computer / electronics / DIY enthusiasts to tinker with and extend.
  • OpenTRV aims to minimise end-user costs by promoting WiFi levels of compatibility, allowing mix-and-match systems to be assembled and upgraded.
  • OpenTRV aims to interoperate with such existing systems as OpenEnergyMonitor, X-10/HomeEasy/etc, and to interconnect with home automation systems and give users easy access to sensor data (etc) if they want it, while keeping an eye to privacy and security.

Project Calendar

Scratching That Itch

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.

News and Project Updates

See also the OpenTRV project update archive.

Basic Operation (V0.09, V0.1, V0.2, V1.x)

The V0.2 design (as the V0.09 design also) works as follows:

  • Each radiator is fitted by the user with a Conrad FHT8V wireless radiator valve in place of the existing TRV head (eg hand unscrew old TRV head, screw FHT8V on, no plumbing required)
  • The OpenTRV unit containing temperature sensor and user controls sits somewhere near the radiator in the room and controls the FHT8V over wireless (868MHz ISM band) to regulate the room/zone temperature as desired.
  • An OpenTRV unit near the boiler listens out for the other OpenTRV units opening their local wireless valves, and if any are open, turns on the boiler, thus providing full soft zoning, ie without plumbing changes. (This OpenTRV unit can also control a local radiator for cost efficiency in a small system.)

The V1.x all-in-one design replaces the valve head, contains the controls and temperature sensor, and can transmit (securely) to the boiler controller and Internet gateway.

Collaboration

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.

Non-Core Uses

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

General Cheap/Open Sensor and IoT Platform

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.

Glossary

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.

(TRV) valve (base/body)
Plumbed into a radiator's flow or return pipework to allow automatic regulation of flow of water through the radiator and thus heat into the room. For UK installations the control pin is typically vertical. See two freestanding valve bases.
(TRV) valve head
Part that screws on to (usually vertical in UK) TRV valve base to drive the pin and regulate the flow of water and thus heat. In this simplest case this is a purely mechanical component using a wax that expands/contracts in response to room air temperature to regulate room temperature. This part can be replaced by the end user, eg with a wireless radiator valve to make a 'smarter' zoned heating system. See two valve heads.

Standards

OpenTRV and associated/halo projects are all about interoperability and to that end we will use or create 'standards' where necessary.

PCB

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.

Licence

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:

  • All code (including the generation scripts for 3D shapes): Apache licence.
  • Schematics: Solderpad licence (eg paste the text into the schematic like we already have with V0.09 and the Apache licence).
  • PCB: Solderpad licence by putting short text eg "Solderpad licence [URL]" linking to the licence text on the PCB legend.
  • Generated 3D files (ie output of scripts): disclaim rights, eg add something to the output to the effect "we believe we retain no rights in this, but you may choose to regard this as licensed under Solderpad/Apache if you wish".