Earth Notes: OpenTRV Archive

Older OpenTRV material

Project Update Archive

Minimum Initial Specification @ 2013/01

After discussion with a number of people, including one friend who had to suspend his plans to automate his heating in just this kind of manner due lack of suitable equipment, I suggested a following minimum spec that we might get implemented in time for the trailing months od the 2012/2013 winter that he and/or I could test deploy at home.

I can supply an initial temperature vs time profile to be built in, if need be.

These initial units only have to work for two months, and mains power would be entirely acceptable for my initial two deployments, and might continue to be a desirable option (if, say, battery or supercap backed to ride through short power cuts, and <0.1W draw) for some units to avoid periodic battery replacement or recharging (and failure at bad moments if forgotten). If the unit could accept Micro-USB-B 5V input then any EU-standard mobile phone charger (UCS/CCS) could be used as supply and should have ≤0.15W standby.

All diagrams, etc, would go in the public domain or be BSD/Apache etc, ie free for commercial use as well and non-commercial.

Further work might allow better integration with a variety of home-automation systems, and Web and smartphone interfaces, plus gathering of sensor status from the TRVs or their connected sensors (temperature clearly, but possibly also occupancy, light level, humidity, CO2 concentrations and other environmental inputs), and the ability to force TRV behaviour remotely, eg summer/holiday shutdown, or nearly-back-from-holiday boost.

Especially once occupancy sensing and remote TRV operation are possible, security will become more of an issue.

Initial Proposed Timeline

2013/01/11 OpenTRV project start
2013/01/18 JK: possible student project spec outline
2013/01/19 DHD/W/PC/B/BG: V0.1 technology selection (primary+alternative) done/published (V0.09 PICAXE impl working 2013/02/26.)
2013/01/31 V0.1 TRV and boiler control prototype h/w and s/w ready/published
2013/02/04 V0.1 TRV and boiler control prototype deployed and testing starts in at least 16WW
2013/02/04 V0.2 dev round starts; fixes and improvements
2013/03/01 Initial results/feedback of V0.1+ test deployment published
2013/04/01 Further results/feedback of V0.1+ test; UK heating season ends
2013/06 JK: Possible university student project starts
2013/09 JK: Possible university student project ends
2013/10 Test/deploy V0.9 [called V0.2 as of 2013/03] at several houses; UK heating season starts

Specification for 2013 Winter

Although the intention is for OpenTRV to extend to and interact with local home automation, and even have a gateway onto the Internet (eg to allow heating to be monitored and turned on/off from outside the house), the initial aim remains simple: a simple-to-operate autonomous system within one house allowing each radiator to call for heat individually, acting as its own heating zone and with occupancy sensing, and using normal TRV (Thermostatic Radiator Valve) fittings as already present in a large number of centrally-heated UK homes.

(See the initial specificiation.)

Proposed Timeline To 2013 Winter Season

This is an outline timetable and wishlist to get us through summer 2013 to be ready for winter starting in October 2013 with one or more updated designs ready to be tested, eg possibly by DECC.

In particular I'd hope to extend our own testing/deployment to several sites, including but not limited to the homes of DHD, BG, BH, MF.

Tasks in green are key, tasks in yellow are the minimum from where we are now to all-in-one unit suitable for wider testing in multiple homes.

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.

TagEnd DateWhoDescription
V0.12013/05DHD / BH Extension of V0.09 s/w on V0.09 PICAXE h/w to complete V0.1 target with implementation of simple schedule, to support DHD and BH (DHW) use cases. (Complete ~2013/05/09 with some tweaking to slew rates and addition of supercap support.)
Sensing22013/05MS / SP / DHD Improved temperature and other core sensing.
BoilerCtl22013/05DHD / BG / PC / MF At least one different boiler control different to DHD's (binary) 2-wire 240V mechanical thermostat replacement.
OccupancySensing1.52013/05DHD / BH PIR, voice and some other early prototyping.
V0.2-Sec2013/06MS / DHD / SP Progress on encryption and authentication in situations where required, and to facilitate more/alternate ergonomic functional splits safely/reliably.
V0.2-Protocol2013/06MS / BG / PC / DHD / SP Progress on over-the-air and over-the-Net protocol (eg MQTT/UDP[/VPN]).
Radio22013/07MS / SP / DHD Select replacement for RFM22/RFM23 radio for battery power (and FHT8V control), possibly for V0.2 h/w and s/w, else for later revisions.
V0.2-AllInOneMech02013/07BG / PC / DHD Initial prototype all-in-one TRV housing and mechanics including valve-driver using V0.2 h/w, and assuming common UK vertical M30x1.5 fitting.
OccupancySensing22013/08JK / DHD Improved occupancy sensing and algorithms.
Learning12013/08JK / DHD Learning (occupancy/usage/performance/etc) algorithms.
V0.2-PICAXE2013/09DHD Updated PICAXE (valve/boiler) unit with better power and cost engineering, eg for 2xAA NiMH hybrid battery operation for 1 year. Include 'learn' button.
V0.2-Arduino2013/09DHD / MS / BH Arduino-compatible (ie end-user-reflashable) ATmega (or ARM) implementation (valve/boiler unit), interoperable with V0.09/V0.1/V0.2 PICAXE, probably using same peripherals, and capable of 5V (wired) or 2xAA NiMH operation.
V0.2-MinCost2013/09DHD / MS Minimum cost stripped-down reference design (valve/boiler unit) for third-party manufacturers as basis of retail product, interoperable with dev-friendly V0.2 designs, probably using same peripherals and code base, capable of 5V (wired) or 2xAA NiMH operation.
V0.2-Hub2013/09MS / SP / PC / DHD / BH Progress on design of hub/bridge (beyond V0.09 dumb boiler node) to interoperate with V0.2 (h/w and s/w) nodes, using V0.2-Protocol.
V0.2-Cloud2013/09BG / MS / PC / DHD / SP / BH Ability to push readings, etc, to cloud and monitoring sites such as Includes protocols and server-side spec.
MSc20132013/09JK / DHD The MSc projects and any contributions to/from them.
V0.2-AllInOneMech12013/09BG / PC / DHD Robust (good for one heating season) all-in-one TRV housing and mechanics including valve-driver using V0.2 h/w, and assuming common UK vertical M30x1.5 fitting.
V0.2-AllInOne2013/10DHD / MS / BG / PC Robust (good for one heating season) all-in-one TRV based on V0.2 h/w and s/w stack and mechanics/box.
V0.22013/10DHD Umbrella task for initial V0.2 implementations including Arduino and/or PICAXE h/w and s/w, and split and/or all-in-one TRV unit with valve driver mechanics, good enough to trial in (tame) end-users' houses.
V0.2-Deploy2013/10DHD / BH / BG / MF Test deployment to at least several team-members' homes.


There were various fragmented discussions over email and in the pub (please see our mail archives for more from March 2013 onward), and over an extended period of time, but here is an illustrative snippet (lightly edited for typos, etc) with Wookey to 2013/01/11, starting with him:

[W] What's wrong with using an HR20+zigbee module for this? (you do know how much power wifi takes (or even bluetooth unless it's the new low-power spec)). This is exactly what zigbee (or enocean) was designed for.
[D] My friend's conclusion seemed to be that this stuff didn't work very well at a number of levels, and certainly things I picked up off that thread you pointed me at suggested that if you're going to void warranties, upload firmware and fabricate boards it might be worth just building an unencumbered unit from the ground up.
[W] Well perhaps it's my software/electronics tendencies, but I'd assumed that the mechanical part of this was tricky. I suppose reproducing the mechanism in an HR20 isn't that hard if you have access to injection-moulding kit or fancy 3D printers, but my understanding is that this of sort thing requires large volumes to be cost-effective. Perhaps not any more? That why we have existing hardware normally, anyway.
[D] The folks who could build the physical TRV and do the electronics are interested: they need to check if they have the time available to do this quickly!
[W] Well if you have someone with the skills to hand then yes our own design would be great.
[D] I'm pretty technology agnostic if it works, and I have nothing against Zigbee or whatever. The point is for our software and hardware design to be all our IP to give away freely and control easily.
[W] Zigbee is an open standard so is good from that POV although you can't use the official logo name if you didn't join the club. Same for USB I thnk and no-one bothers with that at the hacker end. Problem is it never got quite popular enough to be really cheap.

If we're doing this I want a powered/wired interface too. Wireless is all right but I don't want to change batteries in my rads every 6 months. 1-wire or RS485/modbus would be sensible. I prefer 1-wire. Easy to include if this thing has a PIC in it. We have the code already.

[D] Note: yes I would like to use the built-in thermometer as a remote sensor, add PIR on the device or separately, etc, etc, but given the limited amount of this winter left I just thought that the min spec was better than adding a gratuitous unicorn here and there.
[W] You are quite right. A case design with a hole in it for future PIR sensor would be clever (if case revision is expensive).

There was also a very comprehensive comment from Jack Kelly about OpenTRV 2013/01/14. Executive summary:

Modified TRV Hardware or Wireless or Our Own?

In a discussion 2013/03/13 we had about what we should do one the hardware side (excerpted), I had said:


I'd rather that we had at least one reference solution chain that goes from valve pin to boiler interface which is entirely our mechanics and electronics where no one part is critical (ie we should have alternative CPUs such as PICAXE/ATMEGA and radios etc available).

Hardware hacking is never going to be acceptable for more than experimentation and hobbyist IMHO. At least what we're currently doing with the FHT8V over wireless could be part of a consumer grade solution even if not ideal in all other respects. If what you're proposing to do can provide another partial reference solution for OpenTRV, great!


To which Stuart P replied:


I was using OpenHR more as a useful example where the operation of the valve has been replicated, so an understanding of PID loops, and pin control. Rather than as something to re-use.


And Mike S added:

I like the idea of using existing hardware in the short-term so that development can focus on firmware, RF interoperability and algorithms. This £16 Eurotronic/Sparmatic Comet I am waiting for is apparently ATMEGA169 based, which Stuart feels has a limited amount of code space at 16K, but as a starting point it should be adequate. One particularly interesting feature it has is the fake USB socket, which, from what I have gleaned, is actually the SPI bus. It therefore might be feasible to produce an add-on dongle that can both reprogram the AVR and provide the RFM23B, without requiring the valve to be disassembled. I will feed back on this when it arrives.

Options for working around the flash limitation would be to offload some of the more complex control features to a central unit, or, if volumes looked promising enough, to approach the OEM to do a version with a different CPU. The ATMEGA169 has 329 and 649 cousins, for example.

With regards to using other manufacturer's RF protocols, I would particularly like to get away from this as none of them is the least bit secure. I would very much like to work towards a fully specified open protocol that all of the various open HA projects could be encouraged to adopt. A minimum requirement for this would be support for RFM12 (SiLabs EzRadio) and RFM22/23 (EzRadioPro) as the two most common radios being used in these projects, and privacy and authentication built-in.

Anatomy of a TRV

2013/03/27 Stuart P said (with a small addition from me) "thought it would be well worth covering just exactly what a TRV actuator is, and its parts. I'm hoping to turn this into a graphical representation in the future. Consider it a brain dump, not all TRVs need all parts."


(See the wiki.)

To get myself back in the mode of embedded coding (it's a while since I did anything very low-level such as Z80 assembler) I have 2013/01/13 ordered a couple of small PICAXE development kits:

and downloaded the free AXEPad IDE for my Mac.

It's fairly unlikely that we'll build any of the actual OpenTRV kit with this, but not impossible, and I may get to use it for other things, or turn it over to my kids to learn some programming. (I just bought my 7-year-old daughter an electronics kit that she's enjoying.)

I see that the PICAXE store sports sensors for temperature and light and even humidity (no PIR though)! The DS18B20 1-Wire temperature sensor seems the device of choice for PICAXE, with a standby current of 1µA or less.

2013/01/15: having seen PICAXE and X-10 RF transmission goodness I've ordered from Maplin (for under a tenner, free delivery, ordered in store) an A58JN 433MHz transmitter to see if I can talk to my existing X-10/wireless bridge, and an A63JN 868MHz transceiver to see if I can contrive some way to talk to RFM12B stuff on JeeNodes, or even the i30 which operates on that frequency, from the PICAXE hardware.

I've just dug out the (horribly inefficient) mechanism I used to use to "boost" my boiler at my previous house: a mains relay to "call for heat" driven by an X-10 appliance socket. I have also dug out my TM12 X-10 RF transceiver which, with luck, I should be able to control over RF from a PICAXE as above... When everyone stops laughing, this can be replaced by something elegant.

(Some PICAXE+RFM22 chat.)

2013/01/17: received the PICAXE starter kits today and tested out some very simple programming and I/O of the type we may well need, including temperature sensing.

2013/01/23: some simple experiments indicate that the 08M2+ part (at 4MHz) consumes about 20µA when in 'sleep' with 'disablebod', plus another 20--100µA if all pins are not tied (via resistors) to a supply rail. Using 'pause' as is necessary at least in the 18M2+ part to allow clocks to continue to run and in particular accurate(ish) elapsed-time tracking ('time') consumes about 600µA which may be a very good reason to put in an RTC for that even if wall-clock time need not be maintained. A total 1mA circuit drain would be ~100d (ie 3 months) operation from a set of 2 or 3 AA 2500mAh NiMH cells, which is marginal; aiming for a year between charges (eg once just before the heating season) using ~2000mAh hybrids with ~50% self-discharge in a year (ie effective 1000mAh) implies a target average current including any I/O of ~100µA, which would need extensive use of 'sleep' or 'nap' or 'doze' to achieve.

2013/01/26: first minimal boiler control running using 08M2+ PICAXE, minimal program attempting to keep room (with rad on full) at 19°C, with direct (mains SSR) control of the boiler on 2-wire thermostat input. See breadboard pics.

2013/01/29: managed to "bit-bang" SPI protocol to a DS1306 RTC, in preparation for SPI to the RFM22B radio. (The DS1306 operates from 2V--5V, ie potentially from 2xAA NiMH like the 18M2+, and because it talks SPI I can share some I/O lines with 1 or more RFM22s.)

To connect up the RFM22 radio I had to breakout the SMD package to 0.1" pitch.

BH20130304: Bo H has prepared an Eagle library pinout for the 18M2+.

TRV Hardware Fun Round 1

Because of the tight initial deadline imposed by winter, where possible it may be useful to follow up a couple of lines of attack concurrently.

2013/01/15: I had a long chat to Mike S this evening about the Conrad FHT8V TRV which is fairly dumb---it is wirelessly sent a "set valve to nn% open" command and has no temperature sensor or schedule internally---but in other ways is reasonably smart because it controls the TRV pin and self-calibrates, etc, etc. The FHT8V is receive only,

Mike has successfully decoded what is send to the FHT8V (eg by a FHT80B), but has not yet commanded the FHT8V TRV himself remotely, which he will now try to do over the next few days. The aim is to be able to talk to it (868MHz OOK, 400us on then 400us off for a 1, 600us on then off for a zero, preamble 12x0 + 1, data 5 or 6 msbit-first bytes including the C1 C2 addressing, and half a trailing 0 postamble) using a cheap RFM12B or similar. Mike will see if he can talk to the FHT8V and command it with some slightly smarter radios that he has to hand, and I will see if I can find a way to see if the Maplin units I bought today can be driven OOK (and they may actually be RFM12B inside in one case); I have no RF equipment but maybe I can look for break-in on an audio device! The next step is to use one of those Maplin/RFM12B radios to command the TRV. If so then if we add an RTC (eg a DS1307) and a temperature sensor and an X-10 RF output we might have V0.001 of a system to bootstrap from! PICAXE may be too slow to generate the command for the FHT8V, but PIC or the JeeNode should be plenty fast enough.

Midnight update from Mike:

Thought you might be interested to know that I have already had some success talking to the Conrad TRV. I have used a neat hack which converts the 400us/600us pulses to a variable-length stream of 200us bits. This can then be generated by the RFM23 by itself, so you could easily do this from a PICAXE as the timing is handled by the radio, and its FIFO is large enough to queue up the entire transmission before you hit the go button.

One important piece of information I neglected to mention on the phone is that the FHT8V is only listening for 1 second in every 2 minutes (to save battery). This does mean that the valves can only be updated at that glacial rate, and it also requires the transmitter to be synchronised with the valves. I will need to do some work in this area before I will have a completely viable solution, but the process is relatively straightforward and uses the same protocol.

2013/01/16: I asked Mike if the RFM12 might be able to to the same trick, and if we might apply his eventual low-duty-cycle-radio-to-save-juice solution more widely and he said:

Most modern transceiver chips support carrier sense and preamble detection, so pulsing the receiver is not a big problem. The transmit protocol then needs a fairly long preamble - longer than the receiver wakeup interval - and this is a basic trade off between latency, channel efficiency and receiver power efficiency.

First glance at the RFM12 datasheet doesn't look like it supports OOK, so it may not be suitable. The RFM23 is certainly a much more flexible module.

See this note on JeeNode, RFM23B and FS20.

Maybe it's time for me to order some RFM22 or RFM23 kit from SparkFun or RS or whoever...

As to RFM22B vs RFM23B, Mike says:

The RFM23B is based on the silicon labs Si4431 and the 22B on the Si4432. The latter has a higher output power and is slightly more expensive, but is otherwise compatible. The module datasheet does imply that you have to supply t/r switching signals, not required with the 23B, but these can be looped back into the radio and generated automatically given some suitable register settings. AFAIK this would be the only software change.

(And note that the Dorji-DRF4431F13 may be interchangeable with the RFM22.)

I have ordered a FHT8V+FHT80BTF (SKU 646463-89) from Conrad for experimentation.

2013/02/15: I can now talk to the FTH8V reliably from the PICAXE, albeit with pre-canned "valve open" and "valve closed" bit sequences. Today I am working on being able to generate them on the fly to be able to run the initial sync protocol between transmitter and FHT8V to vastly reduce TX power consumption and bandwidth use, and to select intermediate valve positions for less noise and less TRV power drain on its batteries.

I think that more-or-less the next step, if I can do it, because it would avoid having ANY extra explicit inter-node protocol for now (and might work with existing FS20 thermostats eventually) is receiving FS20 packets with the RFM22, in packet mode for efficiency if possible, with or without an extra leading 0xAAAA... sync header.

Mike S suggests that with the RFM22 I'll have to use FIFO mode (that I won't be able to use packet mode) and that "I'm pretty sure you are going to need some leading AA AA bytes, probably 4, then you should be able to use CC CC CC CC as a sync word. Make sure the packet handler is turned off (ENPACRX unset). This will start filling the FIFO with bytes starting from the one after the last sync byte. You don't get any indication when the packet is finished in this mode - the easiest way to deal with this is going to be to read the maximum possible number of bytes (i.e. all 1s)." Also: "There is a spreadsheet that you need to use to calculate the settings for the receive registers. I have only used this for FSK modes, which worked fine, but it does have a section for OOK, so I would configure this assuming the same basic parameters used for the transmitter."


2013/02/02: I'm starting to look at building an Arduino stack, because I will be able to get closer to the hardware than PICAXE and thus possibly do things better that require tight timing constraints, and/or make better use of memory, for example. (Note, however PICAXE & Arduino (code size comparisons - just for fun).)

A candidate initial board is the Arduino UNO ATMEGA328P R3 Mainboard as sold by Maplin.

There may be problems further down the line such as operational voltage range and so on that make Arduino less good than say the PICAXE for battery-powered solutions, but it will be good to provide two easy-to-start-from reference stacks that don't require lots of expensive dedicated programmers, etc. (See this hack to to convert UNO to run at 3.3V.)

2013/02/04: popped into Maplin, bought the UNO, and had the demo Blink program up and running in five minutes with the free running on my Mac, and the Arduino board powered via the USB cable: very good.

2013/02/21: Mike S has released sample FHT code for the Arduino.

2013/03/17: OpenTRV has been lent/given an Arduino Leonardo to play with, and separately, Bruno G has an Arduino MQTT client running, talking to "mosquito" on the Raspberry Pi.

2013/04/14: getting a bootloader into a blank ATmega328P is a non-trivial undertaking, even using an UNO as the programmer, and at least with IDE 1.0.3 is best helped by adding this to the IDE's boards.txt file: on a breadboard (1MHz, internal clock), 2xAA supply 1.8V BOD


to set the AVR to run at 1MHz internally and with brown-out detection at 1.8V.

Having got a bootloader in it's then necessary to use a different board or rewire, and use something like the FTDI TTL-232R-3V3 (which provides a 5V supply from the USB, but accepts 3V3 input levels and indeed should even work down to 1.8V with a logic Vhigh in of 1.5V max). See the TTL-232R datasheet. (RS stock number 429-307.) The cable's 6-way header maps as follows from wire colour:

brownCTS#Input; should be tied to 0V.
red5VSupplied from USB bus; limit to <2.5mA ideally.

Also I tied nRESET (pin 1) to Vcc with a 10k resistor, and to #RTS with a 100nF capacitor as here. TXD (orange) on the cable goes to RX (pin 2) on the ATmega, and RXD (yellow) to TX (pin 3), each via a 10k resistor for protection since in future the ATmega may be running at well below 3V3 logic levels.

2013/04/16: I was unable to upload new code via the FDTI USB cable to my 1MHz ATmega, so I tried adding a variant of the original 8MHz (undivided) breadboard def to boards.txt: on a breadboard (8 MHz internal clock)
(note the split into core and variants at the end to avoid compilation errors) and it worked: I could bootload the basic blink sketch and tweaks to it. That implies by USB connection and auto-reset are fine.

(Note that later I expect to fit a 32768Hz crystal between pins 9 and 10 to allow an accurate time base for a software RTC, and to allow timer/interrupt wakeups from low-power sleep states.)

2013/04/16: while working on minimising power consumption for a nominal 1Hz control loop it seemed worth trying to reduce the start-up setting delay from sleep from the default 65ms to one determined by the BOD system (which I then also adjusted to the correct 2.7V for 8MHz): on a breadboard (8 MHz internal clock, fast start,
2.7V BOD)

2015/01/01: Getting to grips with the adafruit USBtinyISP (PDF) programmer for bootloading our SMD (ie not-socketed) REV7/REV8 designs.


Bruno suggested that we use github to share source, documents, etc.

My Mac is a little old to run the latest stuff that GitHub points me at (and I'm sure that my ARMv5 Ubuntu 9.04 Linux SheevaPlug server is unlikely to be supported by the latest and greatest either), so I'm trying SmartGit though it needs a git binary to be installed first.

For the moment I have revived my SourceForge account and created a new "OpenTRV" project, apparently backed by both SVN and git repositories.

2013/02/02: I encountered Codebender at FOSDEM: "Create a new sketch, upload your existing code or just clone an existing project and modify it to your needs." Should be worth a look for Arduino.

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

Energy Harvesting

Use of energy harvesting to avoid needing an explicit power supply for an OpenTRV unit seems plausable since a basic REV0/REV1 AVR running real-time clock uses ~1.5uA @2V or ~3uW and running a radio to control an FHT8V wireless valve (eg RFM23B at 0.1% duty cycle is ~40uW), and ambient tappable sources include:

which implies that at (say) 10% efficiency, 10cm^2 of amorphous PV might be able to run an OpenTRV unit inside if not jammed too far down behind furniture. In any case such harvesting in conjunction with a low-self-discharge battery might be able to prolong life almost indefinitely (eg hybrid NiMH AA or AAAs). See for example nominal 66mW (3V@22mA) Powerfilm SP3-37 06004IT01, 3.7cm by 6.4cm.

See also Ambient RF Energy Harvesting in Urban and Semi-Urban Environments: a 1000cm^2 antenna might power a typical OpenTRV unit in London.

Note extant AVR-based projects such as Mosquino.

See also WISP5: "The WISP is a battery-free platform with a software-defined implementation of a UHF RFID tag, and conforms to a subset of the EPC Class 1 Generation 2 (EPC C1G2) standard for UHF RFID tags. The WISP can communicate with commercial-off-the-shelf RFID readers, and is powered by the carrier signal emitted by the reader. The operating range of the WISP 5 in free space is at least 8 meters away from a reader emitting 30dBm (maximum power allowed by the FCC) into a 9dBic circularly polarized antenna (a typical antenna type used in RFID systems)."


  • Average EU building heat load for HVAC equipment (2014): lots of info about setbacks in the heating season, typically 3°C for within first 48h of vacancy, and back to a 'frost' temperature of ~7°C after that. Also typical usage patterns of homes (day living rooms ~16h/d, others ~5h/d). 18°C is a typical home temperature in the heating season across the EU.
  • How people use thermostats in homes: A review (2011), "User complaints culled from the literature include misconceptions about energy use and how thermostats work, lengthy and obtuse operating manuals, and social and practical barriers to using programmable thermostats. The user misconceptions are particularly important since they may encourage incorrect usage that cannot be easily overcome by better interfaces. When users complained about the thermostats themselves, they noted in particular their complexity, small size of buttons and text, confusing terms and symbols, and the number of steps needed to program the devices. Several studies indicated disparate attitudes towards thermo- stats. Some users preferred never to adjust their thermostats to the point of being afraid of touching them; some believe that changes in thermostat settings consume more energy. Others tinkered with their thermostat several times per day, and prefer the control of manual adjustment to a set program. These groups will have different priorities for top-level features. Our recommendations for improved usability include access through a web portal and use of audible commands and even voice recognition. The literature revealed some functions that would be desirable to some users but are not available in U.S. models, such as a 'boost' feature that would provide an extra hour of operation (similar to the 'plus one minute' feature on a microwave oven). One study found that users liked a feature that would indicate how long it would take to achieve the desired temperature."
  • UK Ofcom IR 2030 - UK Interface Requirements 2030 Licence Exempt Short Range Devices: FHT8V use at 868.35MHz is covered on p21 IR2030/1/16 (ref EN 300 220 2013/752/EU Band No.48) 868.0 - 868.6 MHz [max] 25 mW e.r.p. Techniques to access spectrum and mitigate interference that provide at least equivalent performance to the techniques described in harmonised standards adopted under Directive 1999/5/EC must be used. Alternatively a duty cycle limit of 1 % may be used.
  • Designing connected products: "Amazon starts new product development by writing the press-release first, then the FAQs".
  • DECC 2012: Smarter heating controls research program.
  • HAH: Home Automation Hub including such delights as the roomNode kit "a wireless temperature sensor and light level sensor. If wired into an Airwick enclosure this also adds motion detection."
  • MyJoulo logger design which contains several functional blocks potentially useful to OpenTRV. It uses the AT90USB162 AVR/microcontroller, and TMP275 temperature sensor.
  • Stuart P's OpenTRV blog.
  • How-to: Program PICs using Linux.
  • Native Assembler Programming on Arduino.
  • A Brief History of Nanode from Ken Boak: "Combines Ethernet and low power 433MHz or 868MHz wireless connectivity on an Arduino compatible platform. ... Used in the Air Quality Egg and Open Energy Monitor Projects."
  • OpenHR20 project at SourceForge and discussion.
  • (Translated) SPARmatic heating thermostats hacking!
  • RFM12B Wireless Transceiver on 434MHz.
  • Funky as remote temperature sensing node with DS18B20 at Martin Harizanov's blog.
  • JeeLabs Shop: (everything open source) ... computing stuff tied to the physical world ... wireless comms, sensors, lights, switches, motors, energy harvesting ... such as the USB-connected JeeLink (v3) which contains Atmel's ATmega328p AVR microprocessor and HopeRF's RFM12B wireless radio module, and DC Motor Plug using an I2C I/O expander. See the JeeNode Comparison Matrix.
  • Article on having power-starved nodes manage to talk to one another given how much juice the receiver takes, eg by coordinating times to talk/listen.
  • SparkFun development tools including PIC and PICAXE and AVR and Arduino...
  • PICAXE site/shop and forum and some simple examples with LEDs and sensors and motors.
  • Some PICAXE and X-10 RF transmission goodness (PICAXE 08M and a 433.92Mhz transmitter, maybe such as the Maplin VY48C or A58JN).
  • 2013/01/11: thread on OpenTRV.
  • 2011/10/08: A better central heating control system: smart heating wish list for London Victorian house with UFH and radiators and TRVs and good insulation; also Existing central heating control systems.
  • Mike Stirling's blog.
  • 2014/10/27: Heat Genius review: £799 inc VAT as installed.
  • Lightstat's Light-Sensing Setback Thermostats reduce temperature when the lights are off or low, as an alternative to (say) PIR motion sensing.
  • i-temp PRC claiming 30% saving over normal TRVs in a field trial and suggestion that i30 is rebranded ELV - ETH comfort200 and data sheet with schematics.
  • Chalmor eTRV and other products including occupancy-sensing thermostats and a user review.
  • Prefect controls/sensors (UK).
  • LightwaveRF wireless radiator TRVs and boiler controls (UK).
  • AlertMe/BG (UK).
  • PassivSystems (UK).
  • Nest (US).
  • Honeywell CM.
  • Conrad FS20 and reverse-engineered protocol.
  • FHT8V/FS20 pair command is 0x2f, so full pairing packet is hc1 hc2 valvenr 2f 00. After pairing you have to proceed with sync.
  • Occupancy-sensing heating system manager (Dutch).
  • MQTT spec and
  • Avoid PC-Layout "Gotchas" in ISM-RF Products.
  • EU Housing Statistics with such gems as: “As such, seven out of every 10 (70.0 %) persons in the EU-28 lived in owner-occupied dwellings, while 19.0 % were tenants with a market price rent, and 11.0 % tenants in reduced-rent or free accommodation.“
  • Mold Growth Prediction by Computational Simulation.
  • Research integrity: Don't let transparency damage science.
  • archived wiki/etc pages such as one on V0p2 and Arduino downloaded from SourceForge Wiki Arduino page.
  • EEPROM corruption vs supply voltage?
  • Arduino programming, including IDE disassembler plugin for IDE 1.0.X.
  • All about headless Arduino builds which may at least allow the basic CI (Continuous Integration) test that successful compilation of all primary targets is possible.
  • 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.
    Please read our privacy policy.
    Mobile site
    Copyright © Damon Hart-Davis 2007-2016.