Earth Notes: OpenTRV Archive Material and Sources

Updated 2024-04-09 07:33 GMT.
By Damon Hart-Davis.
Archival collection of OpenTRV history, events, links, discussion, and related material. #OpenTRV #heating #cutCarbon
OpenTRV prototype V0p09
Everything you wanted to know (and then some more) about the history of the OpenTRV open source project!

Project Update Archive

2014-06-01: Green Challenge Video (Out-take!)

44s "OpenTRV Green Challenge entry outtake [VIDEO]" (poster) Uploaded . Downloads:
  1. • audio-only lo-fi mono low-bandwidth audio/opus clip 85kB +
  2. • low-bandwidth MP4 video clip 1339kB ++
  3. • MP4 video clip 2665kB +++ (may not be available in data-saver/lite mode)
  4. • hi-fi/original MP4 video clip 3596kB +++++

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.

  • 2 x chronostat units (ie temperature-vs-time programmed profile) mechanical TRV head replacement (M30 std fitting), with a built-in profile of target temperature against time or updatable on USB thumb drive (or SD card at a pinch) which broadcasts periodically on one of the ISM/WiFi/bluetooth bands if the room is not achieving target temperature so that multiple receivers can be ORed together to call for heat from the boiler.
  • The boiler end end, ideally, should be a two-wire volt-free 240V switch that can be paralleled with an existing room thermostat to control an existing non-modulating combi, and that will call for heat when any of our TRVs do.
  • Security, power consumption and occupancy sensing are all optional for the first revision, as are ability to separate some of the sensors from the TRV body by wire or wireless, and run the TRV comms back to the boiler wired rather than wireless, and have the TRV (efficiently) mains powered to avoid battery changes, but all of these would be good to have in mind during early design rounds to avoid needlessly excluding or complicating them later.

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

DateMilestone
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 EnergyDeck.com. 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.

Discussion

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 think 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:

  • He's busy but his head is now full of reverse engineering the Current Cost protocol using Nanode + 433MHz RFM12B, so in the mindset for embedded stuff at the moment.
  • JeeNodes / Nanode RFs get his vote as good hardware with lots of support (and we should look at the JeeLib library).
  • Maybe ZigBee is overkill: RFM12B might be the wireless sweetspot for this.
  • Maybe remove the schedule (and RTC) from the TRVs to keep them simpler.
  • Maybe we can get a MSc student doing their project on OpenTRV from Imperial.
  • Look again at LightwaveRF.

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

  • Valve Body Actuator
    • Motor, Gear Train, actuator Pin
  • Motor Drive
    • H Bridge Circuit
    • Optical Rotational Sensor
    • Motor Current Measurement
  • User Interface
    • Push buttons
    • LCD Display
    • Rotary knob
    • LED Indicators
  • Power Supply
    • 2xAA Batteries (typically)
    • 5V USB (Optional)
  • Communication Interface
    • RF
    • Serial
    • USB
    • Ethernet
    • Xbee
    • ZWave
    • Wired connections such as RS232/RS423/1-Wire [DHD]
    • Others such as IR and ultrasound and PLT (eg X-10) [DHD]
  • Brains
    • Single Microprocessor

PICAXE Fun

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

Arduino

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 Arduino.app 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: 

atmega328bb2AA.name=ATmega328 on a breadboard (1MHz, internal clock), 2xAA supply 1.8V BOD

atmega328bb2AA.upload.protocol=stk500
atmega328bb2AA.upload.maximum_size=30720
atmega328bb2AA.upload.speed=57600

atmega328bb2AA.bootloader.low_fuses=0x62
atmega328bb2AA.bootloader.high_fuses=0xDA
atmega328bb2AA.bootloader.extended_fuses=0x06
atmega328bb2AA.bootloader.path=arduino:atmega
atmega328bb2AA.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb2AA.bootloader.unlock_bits=0x3F
atmega328bb2AA.bootloader.lock_bits=0x0F

atmega328bb2AA.build.mcu=atmega328p
atmega328bb2AA.build.f_cpu=1000000L
atmega328bb2AA.build.core=arduino
atmega328bb2AA.build.variant=standard

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:

ColourSignalComment
black0V
brownCTS#Input; should be tied to 0V.
red5VSupplied from USB bus; limit to <2.5mA ideally.
orangeTXDoutput
yellowRXDinput
greenRTS#output

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: 

atmega328bb.name=ATmega328 on a breadboard (8 MHz internal clock)
atmega328bb.upload.protocol=stk500
atmega328bb.upload.maximum_size=30720
atmega328bb.upload.speed=57600
atmega328bb.bootloader.low_fuses=0xE2
atmega328bb.bootloader.high_fuses=0xDA
atmega328bb.bootloader.extended_fuses=0x05
atmega328bb.bootloader.path=arduino:atmega
atmega328bb.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb.bootloader.unlock_bits=0x3F
atmega328bb.bootloader.lock_bits=0x0F
atmega328bb.build.mcu=atmega328p
atmega328bb.build.f_cpu=8000000L
atmega328bb.build.core=arduino
atmega328bb.build.variant=standard

(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): 

atmega328bb8f.name=ATmega328 on a breadboard (8 MHz internal clock, fast start,
2.7V BOD)
atmega328bb8f.upload.protocol=stk500
atmega328bb8f.upload.maximum_size=30720
atmega328bb8f.upload.speed=57600
atmega328bb8f.bootloader.low_fuses=0xC2
atmega328bb8f.bootloader.high_fuses=0xDA
atmega328bb8f.bootloader.extended_fuses=0x05
atmega328bb8f.bootloader.path=arduino:atmega
atmega328bb8f.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb8f.bootloader.unlock_bits=0x3F
atmega328bb8f.bootloader.lock_bits=0x0F
atmega328bb8f.build.mcu=atmega328p
atmega328bb8f.build.f_cpu=8000000L
atmega328bb8f.build.core=arduino
atmega328bb8f.build.variant=standard

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

Outline Plan through End 2014

There are twin primary aims for this year:

  • Produce a limited retail production run, called V1.0.
  • Continue an R&D strand which can be called V0.3 for now.
Some top goals to and through the end of 2014 as of 2014-04:
  • Crunch the numbers from the 2013-14 winter for efficacy.
  • CE-stamped RoHS-compliant retail product based on REV2 2014Q4.
  • Start new R&D branch (REV3?) with: security, two-way working, Internet gateway, DD support, ruggedised/simplified form for (say) schools and dorms and pubs (in general multiple physical forms round same electronics), optional radically-enhanced local UI version such as LCD or e-paper, RadFan-type integration.
  • Testing of RFM69 replacement for RFM22/23, interoperation with RFM12 and OpenEnergyMonitor/Jeelib.
  • Optional TX of stats (subject to security) of: low battery, temperature, target, mode, humidity, light, occupancy.
  • Design tweaks for heat pumps, district heating, and larger buildings.
  • Build in energy scavenging, ability to charge from 2-wire thermostat connection, use of 2xAAA hybrid (or 1xAA or 1xAAA with step-up circuitry) or integrated Li cell all possibly with built-in BMS to last at least a year with factory-gate price <£1, supercap to tide clock over battery changes (and/or finer granularity of clock save and/or last-gasp handling), low battery indication. (Eg see TODO- 229, 230, 231).
  • Carry forward from 2013's timetable: OccupancySensing2, V0.2-Protocol, Radio2, V0.2-AllInOneMech1, Learning1, V0.2-MinCost, V0.2-Hub, V0.2 Cloud.

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.

TagEnd DateWhoResearch Element / Description
V0.2-Numbers2014-06DHD / 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-Branch2014-05DHD / 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-Stds2014-05DHD / 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-BoilerRelay2014-05DHD / MH / BH Formalise and optimise thermostat/relay boiler control design.
V1.0-Radio2014-05MS / 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-PreProd2014-07DHD / 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-Prod2014-09DHD / MH Initial production run with items ready for retail sale.
V0.3-HeatPump2014-06BH / 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 constraints. 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-DS18B202014-16KW / 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-Sensing2014-11DHD / 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-DD2014-10BH / 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-BoilerCtl2014-11DHD / 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-Power2014-10DHD / 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-OccupancySensing2014-11DHD / 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-Sec2014-10MS / 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-Protocol2014-10MS / 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-OEMInterop2014-10DHD / 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-OtherInterop2014-10DHD / 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-Learning2014-10DHD / 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-Hub2014-09DHD / 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-AllInOneMech2014-09BG / 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-MinCost2014-09DHD 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-Cloud2014-09BG / 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-AllInOne2014-10DHD / 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-ARM2014-11DHD / MS / BG Explore other MCUs/CPUs such as Cortex M0+ ARM for OpenTRV designs.
V0.32014-10DHD 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-Deploy2014-10DHD / BH / BG / MF Test deployment to 10s of homes for testing.
EfficacyStdStart2014-10DHD / 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?

Collaboration

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.

Occupancy Sensing Methods

Voice Detection

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

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

(See Energy Harvesting Feasibility.)

Use of energy harvesting to avoid needing an explicit power supply for an OpenTRV unit seems plausible 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:

  • Ambient Indoor Lighting – 100 uW/cm^2 (approx lighting levels for office and better lit parts of home 400lux, dimly lit living areas of home 80lux)
  • Direct Sunlight – 100 mW/cm^2
  • Ambient Outdoor Wind – 1 mW/cm^2
  • Thermoelectric From Motors – 75 uW/cm^2
  • Vibration From Personal Movements – 5 uW/cm^2
  • Vibration From Motors – 750 uW/cm^2

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

References

(Count: 2)

~12492 words.