Earth Notes: OpenTRV Archive Material and Sources
Updated 2024-11-14 14:53 GMT.By Damon Hart-Davis .
Project Update Archive
- 2024-10: Matt Sheen at Secure Meters reports on PSDS (Public Sector Decarbonisation Scheme):
... With over half a million Radbot devices already installed across UK homes and buildings, Radbot has proven itself as a reliable cost-effective energy-saving technology. It offers a smart and affordable way to improve heating efficiency, especially for public sector projects looking to optimize legacy wet central heating systems. ...
- 2022-09-14: Secure UK Ltd has announced the roll out of Radbot.
- 2022-08-02: Radbot patent granted [hart-davis2022thermostatic].
- 2021-10: Radbot IPR acquired by Secure Meters.
- 2021-06-04: Ofgem ECO3 guidance for Time and Temperature Zone Controls (TTZC) [PDF] such as Radbot.
- 2021-05-20: The climate is our business:
Meet the startups shaping our vision of The World in 2050
, featuring Radbot! (Also as a news item.) - 2021-03-25: Ofgem approves Radbot for ECO.
- 2020-12-17: [archive snapshot] Best smart thermostats 2020: Save on heating costs now, Radbot at #3:
Radbots are brilliant.
- 2020-12-09: 101 Market Leading Energy Efficiency Companies and Startups in the UK.
- 2020-11-26: Energy Institute Award for Innovative Technology for Radbot!
- 2020-11-14: EcoHome Lab meeting on smart radiator valves: Radbot.
- 2020-09-10: Radbot SAP/PCDB entry.
- 2020-06-27: Liebreich: Energy Efficiency Key To Covid Recovery: Vestemi namecheck.
- 2020-05-02: The Guardian: 'Hey Google, dim the lights': how smart home devices can save money: Radbot is mentioned!
- 2020-02-18: Radbot at London IOT meetup; see the slide deck.
- 2020-01-28: Best smart thermostats 2020.
- 2019-11: Radbot Seedrs campaign starts!
- 2019-09-29: Radbot won "Energy Efficiency Product of the Year 2019"!
- 2019-07-02: Radbot is on the 2019 UK Energy Innovation Awards shortlist! (Customer Focus)
- 2019-06: BUILD Magazine 2019 Design and Build Awards: Vestemi Limited awarded the title of “Most Innovative in Energy Saving Technology” for Radbot.
- 2019-04-30: How Artificial Intelligence can simplify our everyday lives.
- 2019-07-02: Radbot is on the 2019 UK Energy Innovation Awards shortlist! (Customer Focus)
- 2019-04-12:
It was great to catch-up with @RPDintl yesterday. Alongside the core team at Vestemi, they helped transform Radbot from concept to product in a short space of time. Some said it couldn't be done, but we did it! #saveenergy #smartheating #smarthome
. - 2019-03-22: Cut heating costs with Radbots on your radiators: "In my quest to cut our heating costs, I have a new love, and its name is Radbot. Never thought I'd get carried away by radiator valves, but these babies are clever."
- 2018-12-13: the consumer CE-stamped Radbot is now on sale through EDF Energy! (The Radbot name was conjured up by Rob Wirszycz, one of our advisors!)
- 2018-03-28: OpenTRV Limited is now Vestemi Limited. The open source project name remains as-is.
- 2018-01-23: an initial investment round and expanded management team is in place today.
- 2017-10-31: Pitching for Cleantech Venture Day; Are apps for energy management dying or irrelevant? @OpenTRV thinks so. Fit n Forget smart thermostat presented at @CleantechDay 10to 1 roi?.
- 2017-09-04: 12 UK internet of things startups to watch: in at number 6!
- 2017-05-31: sharp fall in battery voltage over 3 days for REV1 sensor "4o" (and going off-air) measuring exterior temperature. New but possibly damaged (from being allowed to run very low) NiMH cells fitted.
- 2017-05-25: There was an "Unexpected opportunity to pitch to @TheDukeOfYork @Imperial_INC today! Discussed Buckingham Palace heating refurb, as one does...
- 2017-04-29: Cleantech Innovate 2017 pitch.
- 2017-04-03: How many @EarthOrgUK followers have now turned their central heating off until autumn/winter?: 75% (n=12). 20170410: RadBot? 50% (n=22)!
- 2017-02-02: IoT Tech Expo Special podcast featuring an OpenTRV interview.
- 2017-01-17: Case Study: IoT and Security – Who Needs Either? "[OpenTRV's] method is consistent with the founding values of IoTSF and what we consider to be best practice at the highest level, namely; a security-first approach, right-sized for the application and resilient over its life-cycle."
- 2017-01-05: IRC session on facilities management and fault detection, and energy harvesting.
- 2016-12-21: example of correct occupancy detection in difficult conditions.
- 2016-12-10: TRV1.5 20161211-RC3b release, with enhanced setbacks to be able to hit 30% savings against real data.
- 2016-11-16: Scoping review of heating controls reveals amongst other things "zonal control reduced gas consumption by c12% compared to a Building Regulations compliant system".
- 2016-11-07: an example of why OpenTRV has a "local first" design: DDoS attack halts heating in Finland amidst winter.
- 2016-10-09: is it a bit hot in here (~130°C)? Cannot be radio data corruption, so smells like something wrong at the device (7h), and indeed seems to be flagging battery (<2.4V is ~1 week remaining life, last TC gasp at ~1.89V, though still weakly flashing LED every ~4s at 20161011T2050Z):
[ "2016-10-09T18:40:21Z", "", {"@":"A9B2F7C089EECD89","+":7,"T|C16":302,"H|%":66,"O":1} ] [ "2016-10-09T18:44:15Z", "", {"@":"A9B2F7C089EECD89","+":8,"L":49,"B|cV":192,"v|%":0} ] [ "2016-10-09T18:48:13Z", "", {"@":"A9B2F7C089EECD89","+":9,"tT|C":16,"T|C16":2061} ] [ "2016-10-09T18:51:17Z", "", {"@":"A9B2F7C089EECD89","+":10,"B|cV":189,"H|%":66,"O":1} ] [ "2016-10-09T18:52:13Z", "", {"@":"A9B2F7C089EECD89","+":11,"vac|h":0,"L":50,"v|%":0} ] [ "2016-10-09T18:56:15Z", "", {"@":"A9B2F7C089EECD89","+":12,"L":51,"tT|C":16} ] [ "2016-10-09T19:00:23Z", "", {"@":"A9B2F7C089EECD89","+":13,"vC|%":1792,"T|C16":2061} ]
- 2016-10-03: doing one of these simple solar PV energy harvesters (but with 1F cap and Sanyo AM-1454CA (RS 664-6762) PV 2.4V nominal 46uW at 200lx; a couple of mA in direct sunlight) to power 4o REV1 'secure' sensor node. Struggling to get cap >1.9V even in direct sun.
- 2016-09-30: data sample for improving auto-suppression of heating (eg to frost protection only) when windows are opened to air rooms, and in draughts: README, JSON (compressed), graph (penultimate day).
- 2016-09-16: our shiny crowdfunding intern is returning to Nigeria to spend more time with his wallet. His new job title? Money Drycleaner-in-chief it turns out!.
- 2016-09-12: 16WW gets to eat its own secure-transport dog-food (so no more binary-format FS20 traffic, nor are there any more undetected transmission errors expected):
[ "2016-09-12T16:12:34Z", "", {"@":"3015","+":5,"tT|C":6,"T|C16":387,"H|%":64,"O":1} ] [ "2016-09-12T16:12:38Z", "", {"@":"414a","+":0,"vac|h":4,"O":1,"L":98,"v|%":0} ] [ "2016-09-12T16:12:38Z", "", {"@":"414a","+":0,"vac|h":4,"O":1,"L":98,"v|%":0} ] [ "2016-09-12T16:12:44Z", "", {"@":"0d49","+":4,"L":229,"T|C16":379,"O":1,"vac|h":8} ] [ "2016-09-12T16:14:25Z", "", {"@":"FA97A8A7B7D2D3B6","+":4,"tT|C":16,"H|%":61,"O":3} ] [ "2016-09-12T16:15:14Z", "", {"@":"A9B2F7C089EECD89","+":10,"tT|C":17,"T|C16":363} ] [ "2016-09-12T16:15:21Z", "", {"@":"E091B7DC8FEDC7A9","+":2,"L":39,"tT|C":17,"T|C16":400} ] [ "2016-09-12T16:15:27Z", "", {"@":"819C99B4B9BD84BB","+":11,"L":230,"T|C16":354,"O":1} ]
- 2016-08-12: our My Radbot site crept into life in preparation for the crowdfunded TRV2.0.
- 2016-07-31: another bad data point got past the CRC at home:
2016/07/30 02:26:02Z 414A 107.8125 @414A;T107CD;P;L85;O1
- 2016-07-12: 3Cs pitch (won the vote on the night!).
- 2016-06-29: Key Amnesia review and fix.
- 2016-06-21: critical code-path review for boiler control and stats reporting.
- 2016-06-17: crowdfunding warm-up silliness: Interim title for our shiny new crowdfunding intern? at 44% (16 votes) "Interim Overlord".
- 2016-06-14: review of path from valve to boiler.
- 2016-05-24: OTWiki on GitHub.
- 2016-05-23: Indie Manufacturing (January) interview.
- 2016-04-14: EmonCMS and multiple OpenTRV nodes... wired together with Node-RED.
- 2016-04-03: another corrupt data point got past the CRC for a kitchen temperature of over 35°C at midnight.
- 2016-03-31: another corrupt data point got past the CRC for a living room temperature of over 90°C: summer is here?
- 2016-03-15: LoRa base stations installed by OpenTRV courtesy of
ttnmap
. - 2016-03-03: Sample of MQTT-routed OpenTRV data courtesy of Bruno!
- 2016-03-02: Basis of measuring energy savings.
- 2016-03-02: Another bad (binary stats) data point that got past the structural checks and CRC, cf COHEAT troubles on their very busy radio channels
2016/03/01 22:15:16Z F1C6 97.4375 @F1C6;T97C7;L85;O1
; note that there were no obvious glitches around the same time in the JSON stats so more likely a radio/comms issue than a sensor/code/MCU issue. - 2016-02-24: Buses and Radiators: An Update.
- 2016-02-18: Interoperability Hack Day with OEM and others courtesy of BCS in London, and also see collaboration repo at GitHub.
- 2016-02-18: London's First LoRa Base Station: "Peter Karney, Head of Product Innovation at the Digital Catapult, blogs about London's first LoRa base station being installed on the roof of the Digital Catapult Centre and what benefits it will offer for IoT innovation. Working in close partnership with OpenTRV (one of IoTUK's Showcase companies) the Digital Catapult has installed and made available to all, a LoRa base station in Central London. LoRa stands for Long Range Radio, and is one of the new radio technologies targeted for M2M and IoT networks."
- 2016-02-18: LoRa driving IoT projects from London base: "We at OpenTRV like to think of this as the missing link in the evolution of the Internet of Things," he said. "Low cost sensors, simplified deployment, cloud based analytics and now free connectivity have reached the point where the combination is so cost effective that the business case moves into the no-brainer category."
- 2016-01-02: The 10 hottest IoT start-ups to watch in 2016.
- 2016-02-14: first secure 'O' frames TXed/RXed,
20160214-secure-O-frame-RX-and-dump, eg:
{"@":"F9D9EDCEB98AF68F","+":7,"L":74,"T|C16":302,"O":1}
- 2016-02-04: OpenTRV and OTRadioLink
20160204-tenative-control-loop-freeze
. - 2016-02-02: notes from second shelter sensor deployment including first LoRa unit (and images/all).
- 2016-01-23: very simple infographic to get across one of the advantages of OpenTRV.
- 2016-01-22: Deniz E's testing notes for REV7, REV10, REV11.
- 2016-01-21: notes from first trial/temporary shelter sensor deployment (and images/all) and the first frames from it installed, as logged at the server:
2016-01-21 15:28:08.415496: ip:213.205.251.84, port:6583, msg:{"@":"8aad","+":2,"O":2,"T|C16":304,"vac|h":0} 2016-01-21 15:30:08.855109: ip:213.205.251.84, port:6583, msg:{"@":"8aad","+":3,"B|cV":266,"L":255,"av":1} 2016-01-21 15:32:08.943870: ip:213.205.251.84, port:6583, msg:{"@":"8aad","+":4,"av":0,"T|C16":278,"O":2,"vac|h":0}
- 2016-01-14: simple Java server/concentrator setup.
- 2016-01-13: effect of reducing scheduled-on pre-pre-warm set-back to 1°C then lengthening pre-warm to 90m of which 54m is pre-pre-warm is to help target temperatures be achieved on time, also here.
- 2016-01-12: suggestions for improvements needed for COHEAT radio model for higher density in-building use (see also other materials).
- 2016-01-11: first securable frame encryption on AVR (tag 20160111-secure-frame-enc-alpha (OpenTRV OTAESGCM OTRadioLink).
- 2015-12-29: Shenzhen sample DORM1/REV7 valve managing the 16WW hall radiator reasonably well given defective light sensor, PCB floating around in mid-air (unencased), and shaft encoder not yet coded! more and yet more...
- 2015-12-23: kitchen left on 'WARM' for more than a day shows sensible target and actual temperature profile and valve movement in spite of lots of comings and goings, heat from cooking and so on, not usual for a Monday as this is a school holiday. See just the target temperature for the first day.
- 2015-12-19: lightweight relay / half-concentrator (relaying stats from sensors over ISM onwards over UDP over GSM/cellular) is running on a REV10 coexisting with a boiler hub; all in AVR land, no RPi required.
- 2015-12-02: fired up LoRa network node on roof on Digital Catapult on 101 Euston Road in London as part of TheThingsNetwork (TTN).
- 2015-11-22: sample graph of living room target and actual temperature, vs valve open percentage and occupancy probability, over a day and bit with temperatures dropping to zero/freezing outside.
- 2015-11-20: interesting data corruption from SHT21 sensor as battery voltage fell below rated 2.1V minimum; temperatures of over 100°C and RH of 118%! Preserved in the data by changing 2d1a leaf ID to XX2d1a manually.
- 2015-11-17: data being reliably delivered over UDP over GSM on/just after code at
20151117-SIM900 tag:
2015-11-17 17:50:54.837150: start 2015-11-17 17:59:19.968823: {"@":"8aad","+":1,"T|C16":330,"O":1,"vac|h":0,"B|mV":0,"L":0} 2015-11-17 18:00:19.976979: {"@":"8aad","+":2,"T|C16":326,"O":1,"vac|h":0,"B|mV":0,"L":0} 2015-11-17 18:01:19.988737: {"@":"8aad","+":3,"T|C16":326,"O":1,"vac|h":0,"B|mV":0,"L":0} 2015-11-17 18:02:20.002612: {"@":"8aad","+":4,"T|C16":326,"O":1,"vac|h":0,"B|mV":0,"L":0} 2015-11-17 18:03:20.022988: {"@":"8aad","+":5,"T|C16":326,"O":1,"vac|h":0,"B|mV":0,"L":0} 2015-11-17 18:04:19.983533: {"@":"8aad","+":6,"T|C16":326,"O":1,"vac|h":0,"B|mV":0,"L":0} 2015-11-17 18:05:20.011172: {"@":"8aad","+":7,"T|C16":328,"O":1,"vac|h":0,"B|mV":0,"L":0}
- 2015-11-13: drafting ETV proposal.
- 2015-11-05: prototype DORM1 (dead-reckoning only) deployed to real radiator in live heating system, calling for heat from boiler.
- 2015-11-04: sent first raw JSON stats frames over GSM.
- 2015-10-31: analysis of relative humidity vs occupancy.
- 2015-10-16: short pitch to Ignite on our social goals at YouTube.
- 2015-10-02: apparent fourth bad (binary) temperature data frame/point to get past the (7-bit) CRC and other checks (
2015/10/02 17:22:50Z A45 105.3125 @A45;T105C5;P;L125;O1
). - 2015-09-30: Speaking at Wuthering Bytes about Health, wealth and buses: IoT and carbon.
- 2015-09-17: IoT Meetup presentation in Cambridge.
- 2015-09-17: Deployment notes: TRVs on 5G heat networks courtesy of Marko Cosic of COHEAT.
- 2015-09-01: brief notes from call with Telefonica about use of its network during the project (D21RM).
- 2015-08-27: Setting up OpenTRV Java comms bridge on Raspberry Pi courtesy of Bruno.
- 2015-08-27: snapshot of current dev position with view to offloading some tasks from DHD!
- 2015-08-24: Maker Monday interview.
- 2015-08-07: OpenTRV is happy to announce an initial tranche of angel funding to help get manufacturing underway this winter!
- 2015-08-06: refactored radio functionality released today including OTRadioLink V0.7 with interrupt-driven RX and OTProtocolCC V0.3 simple central-control 2-way protocol (CC1).
- 2015-08-05: ooooh, apparent third bad (binary) temperature data frame/point to get past the (7-bit) CRC and other checks (
2015/08/05 04:45:42Z D49 107.8125 @D49;T107CD;P;L85;O1
). - 2015-07-23: "Running a tight ship in the digital age" Guardian 'roundtable' discussion including OpenTRV.
- 2015-05-29: REV7 and REV8 breakout/programming boards.
- 2015-05-20: finalists for Interop London's Tech Startup 10!
- 2015-04-04: first OpenTRV unit transmitting stats died 'on-line' with battery measurements up to and including the final one:
[ "2015-04-04T00:38:11Z", "", {"@":"f1c6","+":4,"B|mV":1989,"v|%":100,"tT|C":18} ] ... [ "2015-04-04T18:54:12Z", "", {"@":"f1c6","+":5,"T|C16":239,"L":46,"B|mV":1904} ] [ "2015-04-04T19:54:13Z", "", {"@":"f1c6","+":4,"B|mV":1887,"v|%":100,"tT|C":18} ] [ "2015-04-04T20:14:13Z", "", {"@":"f1c6","+":6,"B|mV":1870,"v|%":100,"tT|C":18} ] [ "2015-04-04T20:22:13Z", "", {"@":"f1c6","+":0,"B|mV":1870,"v|%":100,"tT|C":18} ] [ "2015-04-04T20:30:13Z", "", {"@":"f1c6","+":2,"B|mV":1870,"v|%":100,"tT|C":18} ] [ "2015-04-04T20:38:13Z", "", {"@":"f1c6","+":4,"B|mV":1870,"v|%":100,"tT|C":18} ] [ "2015-04-04T21:54:13Z", "", {"@":"f1c6","+":4,"B|mV":1836,"T|C16":237,"L":39} ] [ "2015-04-04T22:10:13Z", "", {"@":"f1c6","+":5,"B|mV":1836,"v|%":100,"tT|C":18} ] [ "2015-04-04T22:54:13Z", "", {"@":"f1c6","+":1,"L":33,"B|mV":1785,"v|%":100} ]
(Replaced battery 2015-04-08 07:00 UTC,"B|mV":2635
.) - 2015-03-30: very strong winds (45mph gusting to 60mph) are forecast for overnight and the next day so I have taken the entire turbine down and moved the b39a unit to one group of off-grid solar panels to monitor their generation hours. Download the (small) full set of wind stats.
- 2015-03-27: RS DesignSpark piece from heating to buses via IoT!
- 2015-03-24: at the Shell Enterprise Conference today.
- 2015-03-23: CO2/RH/temperature samples from a primary school classroom; 9th March was an INSET day (ie staff training, no kids in).
- 2015-03-22: first fast-start energy-harvesting code (snapshot 20150321-r4359-V0p2-Arduino-REV1-as-wind-generation-monitor) on REV1 board for monitoring when a small wind turbine is operating; first TXes after connection wired in:
[ "2015-03-22T14:26:13Z", "", {"@":"b39a"} ] [ "2015-03-22T14:26:15Z", "", {"@":"b39a","B|mV":3247,"T|C16":430} ]
Powered via 1N4001 to TS2950CT33 (3V3, 30V max low power LDO reg) to 10uF electrolytic on 'wild'/crowbar side from turbine bridge rectifier output. 1N4001 to prevent reverse biasing the regulator, especially when crowbar operates. Note that initial ID-only frame sent ASAP after (fast) boot, then stats sent at randomised intervals exponentially increasing until ~64s+ apart to capture short periods of activity with reasonable precision but conserve bandwidth for longer runs. Will also test robustness of (REV1) board as temperatures rise (T|C16 is board temperature in °C*16).. - 2015-03-12: fabulous bit of inventive measurement by someone in the OpenTRV trial as we tried to track down the cause of some boiler short cycling: Results of Monitoring a Vaillant ecoMAX pro 18E Boiler.
- 2015-03-09: Frankenvalve STL posted at Github courtesy of Bruno.
- 2015-02-19: OSHUG38 — Scratching the itch: saving the planet, Damon Hart-Davis.
- 2015-02-19: Quantimetrica is going to Embedded World with one of our boards (PDF); we're really looking forward to further dev work with them and their clever voice tech!
- 2015-02-14: ooooh, apparent second bad (binary) data frame/point to get past the (7-bit) CRC and other checks; claimed room at ~99C at 16:45 for one data point in the binary stream only! Possibly this particular failure mode is common. Could still be bad high value from sensor or otherwise 'bad' before sending, correctly encoded to max allowed value before transmission.
- 2015-02-09: tweaked more to try to help the 'jittery' rad gives an independently-measured room temperature ~17.5°C on the far side of the room.
- 2015-02-08: updated the control algorithm a little to try to help the 'jittery' rad gives a significantly higher independently-measured room temperature (~17.5°C vs something below 16°C) for the same target of 18°C, even on the far side of the room.
- 2015-02-04: upon turning down the manual valve (~15:30) a little to provide better static balance to the 'jittery' rad a slightly smoother temperature curve is visible with the valve getting a little further open, and the room feels better; the system is not being 'balanced on the clutch' so aggressively. (For comparison a more normal rad.)
- 2015-01-30: first CO2 measurements (courtesy of JSH's logger, thanks!) at my desk (.CSV) and matching binary and JSON logs from the OpenTRV sensor (SHT21 et al) ~10cm away.
- 2015-01-29: a more complex target temperature pattern with room vacated (light turned off shortly after heat turned on), then system setting back further when room is usually vacant, then BAKE being used.
- 2015-01-16: ooooh, apparent first bad (binary) data frame/point to get past the (7-bit) CRC and other checks; claimed room at ~99C at 19:20 for one data point in the binary stream only! From at least 150k binary data frames received. I did check that the unit was not on fire.
- 2015-01-11: further small tweaks in snapshot 20150110-r4111 to reduce valve movement and make for a softer setback as the target drops, eg when lights are initially turned off eg in jittery room though only effect here probably wider deadband meaning no call for heat in the pre-warm phase; 174% total travel. See also here (150% total movement).
- 2015-01-05: first code snapshot uploaded onto very first REV7 board (README) along with correct complaint about RFM23B not being fitted causing panic() as designed.
- 2015-01-02: still on snapshot 20150102-r4071: small room movement use just over 200% (vs daily ~400% budget) valve never fully open, study movement exactly 200%, jittery room again two heating runs total movement slightly over 400% nominal budget and never 100% open, slow response room about 300% movement for 8h heating period (big overshoot from having four people in the room, boiler already off centrally by end, next day, within movement budget also, with setbacks and BAKE mode, accidentally left on overnight with the automatic setback providing some savings), final example with two programmed on sessions (room contains boiler thus excursion at end!).
- 2015-01-01: note an extreme slow case with sensor at far end of my largest, least well-insulated room with the least good radiator and a fairly chilly day outside 6+ hours to reach target from ~2°C below, and a ~2°C temperature gradient from rad to sensor!
- 2014-12-29: refactored code to reduce temperature overshoot and improve testabilty and some analysis of valve % vs actual and target temperatures, and another room with frost protection kicking in at 12°C because of highish relative humidity, and the toughest location (with possible significant direct radiative heating of the sensor) that shows that the algorithm still needs work to avoid too much valve movement and temperature wobble and slightly improved, and again with some effort to reduce valve movement (down to about 290% of travel in first ~3h heating run and 540% total over two heating runs vs a target daily budget of ~400%) and thus noise and also prolong battery life (snapshot). Tweaked again (TODO-453) for more careful close ~180% for one heating run with various automatic target temperature changes (snapshot).
- 2014-12-23: largely successful test of automated setbacks while we took a weekend break 20th--23rd though found some minor bugs/features.
- 2014-12-13: dealing with sensors close to radiators: see 1g red line get less spiky as adaptive algorithm put in place.
- 2014-12-11: round 3 of protocol and data format discussions.
- 2014-11-27: round 2 of protocol and data format discussions.
- 2014-11-23: V0.0.6 of server now logs JSON-format frames; these are sent CRC protected from leaf nodes.
- 2014-11-20: Mike's Tiny Home Area Network Stack!
- 2014-11-19: final pitch for IoT Launchpad to Innovate UK today.
- 2014-11-13: very useful protocol and data format discussions this evening; thanks to all who joined in!
- 2014-11-13: successful preliminary integration with Quantimetrica voice detector for an additional strand of occupancy sensing.
- 2014-10-27: Mark talking about Climate-KIC whose accelerator program we are in.
- 2014-10-06: busy week just gone including IoTboost in Liverpool (thanks to Paul G, Anjali R, Josh V, Hamid F, and Adrian McE for some excellent advice) and OggCamp14 (we're just off screen bottom right in this timelapse of Sunday).
- 2014-09-24: our pitch to the Cisco IoT Challenge today, by Mark.
- 2014-08-31: Initial video for our (successful) IoT Launchpad entry, with out-takes!
- 2014-08-19: WutheringBytes OpenTRV talk and video courtesy of 101blog.
- 2014-06-24: Register survey of some products in OpenTRV's area.
- 2014-06-23: Heat Genius user claims 43-46% savings with system similar to OpenTRV.
- 2014-06-21: Local Warming follows you: these infrared spotlights act like artificial 'suns' to keep you warm a higher-tech version of our idea of snapping on a wall-mounted electric radiant heater while radiators are warming up when a room is occupied unexpectedly.
- 2014-06-17: BBC is reporting up to 25%/£400 annual savings based on £1,385 average dual fuel bill with Hive/Tado/Honeywell systems, with zoning being emphasised.
- 2014-06-01: OpenTRV Green Challenge video and outtake.
- 2014-05-19: OpenTRV modules with or without a radiator to control can now be allowed to transmit stats information to be logged centrally such as for this plot of temperatures inside and outside (4o) DHD's house.
- 2014-05-19: Comparing REV2 LDR light sensor with REV3 RoHS-compliant phototransistor (note: 200k load resistor vs design 220k) response from two units next to one another on my desk over several days as graph (from data extract) suggests that REV3 sensing range will be better.
- 2014-04-25: Bruno presenting on OpenTRV at EC2014 in Leuven!
- 2014-03-27: OpenTRV doing its magic in Bruno's home.
- 2014-02-18: Have initial code to communicate between a laptop/PC/server and an OpenTRV CLI over serial (using the RXTX lib), to interact with the unit and to gather stats (eg see Linux script.
- 2014-02-02: OpenTRV talk at FOSDEM: slides .odp and other formats, 25m video silent for the first 3m:40 then low quality audio until 8m (smaller .ogv version), addressing OpenTRV [hart-davis2014opentrv].
- 2014-01-20: Before running a REV1 (V0.2) board from battery this jumper/clip must be removed else the regulator will be damaged and the battery will run down quickly.
- 2013-12-30: is OpenTRV customer-installable or might Part-P or GasSafe certification be needed?
- 2013-12-22: First boiler control unit install (at BG's house, also his photo).
- 2013-12-16: Did first (pre-trial) install today, and Mark H gave a talk at CleanWeb.
- 2013-12-13: TVRRUG printing boxes for us, and first installs for university trial may be Monday!
- 2013-12-12: First of batch of REV1 30 boards from PM Services correctly running and fitted into latest box revision today!
- 2013-12-02: video of Power-On-Self-Test LED sequence for V0.2 board (REV0/REV1) as of today.
- 2013-10-26: Bruno slaved over a 4-layer box design (OpenSCAD source); view and bottom three layers as printed with main REV1 board in place.
- 2013-09-26: OpenTRV is in the British Gas Connecting Homes competition (pitch event and showcase for 25 startups in the home energy sector); first attempt at a presentation.
- 2013-09-26: OpenTRV won third place at Connecting Homes; OpenTRV Connecting Homes Press Release; the British Gas Connecting Homes competition (pitch event and showcase for 25 startups in the home energy sector); my pitch/presentation.
- 2013-08-12: Arduino UNO minimal bootloader shield for V0.2 (1MHz internal-RC-driven clock) board in particular. See wiring required "(targeting an AVR on a breadboard)" and SparkFun Arduino ProtoShield Kit used.
- 2013-08-11: Initial attempt to gather some of the Eagle libraries together that Bo has developed for easy use by others.
- 2013-08-02: Velleman K8200 3D printer ordered from Maplin (assembled) with some PLA filament; will order ABS also in due course.
- 2013-07-22: District heating DHW controlled by OpenTRV V0.9 saves ~1/3rd of energy consumption (down from ~0.23GJ/fortnight to ~0.14GJ/fortnight) by reducing tank losses overnight (thus large temperature drops to as low as ~35°C when not needed: OpenTRV target/max is 53°C while old Danfoss analogue maintained ~47°C). Note that in this graph old analogue stat was refitted ~June 25th for fortnight repeat test, the first half is OpenTRV. See a typical daily temperature curve too; the tank is heated from ~8am--10am. If hot water is needed earlier Bo sets his alarm from an hour before and presses the WARM button to bring the system up to temperature early.
- 2013-07-02: First cut (revision 0) of V0.2-Arduino PCB ordered from iTEADStudio, get .ZIP snapshot bundle of Eagle and Gerber files.
- 2013-05-31: Listed at #1 in Carbon Brief's "Boring but brilliant: Four dull-yet-important energy solutions."
- 2013-05-28: Have attempted simple anticipatory pre-warming of cold room based on previous week's behaviour to improve user comfort.
- 2013-05-22: Have FHT8V TX working from V0.2-Arduino (see snapshot) with minimum/idle current still ~3uA@2.6V and a calculated mean of 23uA+ in 'frost' mode assuming 0.1% RFM22 duty cycle for TX, maybe double that in 'warm' mode with LEDs flashing and doubled TX for robustness; well within power budget for 1 (100uA) or 2 (50uA) year operation from NiMH AA hybrids I think.
- 2013-05-16: Useful IRC session about H-bridge direct motor drive, including outline schematic from Mike (only needs two digital lines to drive it) and notes about current monitoring and supply management.
- 2013-05-10: PICAXE code tagged at V0.1-operational.
- 2013-05-05: V0.2-Arduino hardware prototype on breadboard with all major components (ATmega328P+TMP102+RFM22B+LDR) has idle current draw of ~3uA in sleep, maintaining software RTC.
- 2013-04-30: Making decent progress with V0.2-Arduino extension of V0.1 PICAXE code. Latest fun: gathering entropy from clock jitter for possible crypto (authentication/encryption) support.
- 2013-04-16: Optiboot V5.0 bootloader for ATmega328P running at 1MHz from internal clock suitable for 2xAA power-efficient operation. (README boards.txt content for Arduino 1.0.3 IDE bootloader .hex example low-power blink sketch all as one ZIP file.) IDE 1.6.x boards.txt extension.
- 2013-04-14: V0.1 tag, code commissioned on V0.09 PCB for my study/desk.
- 2013-04-10: Five populated V0.09 PICAXE boards!
- 2013-04-09: Tentative V0.1 s/w tag, including support for simple schedule, learn button, initial time set, and periodic status report over serial.
- 2013-04-07: Updated diagnostic tests for the board including RFM TX, LDR and button.
- 2013-04-04: Mike populated (and tested) the first V0.09 board!
- 2013-03-29: Proposed timetable to Winter 2013 to support more test deployments.
- 2013-03-21: Automated Home piece.
- 2013-03-12: FHT8V sync implemented so TX duty cycle now ~0.1%, but 18M2+ code space very nearly full! (r862)
- 2013-03-11: Hurrah! First PCB design (600dpi PNG) shipped to fab (and components to populate 7 boards ordered). Mike and Bo have been labouring like slaves for this; many thanks! Simple diagnostic code (and README) to test a board for gross faults.
- 2013-03-03: Photo(s) of second board in case.
- 2013-03-03: Bo is preparing the first OpenTRV PCB layout in Eagle; thanks!
- 2013-03-01: OpenTRV.org.uk domain set up for the project.
- 2013-02-28: Combined TRV and boiler node working; now two soft zones at home!
- 2013-02-26: TRV node is controlling local TRV and boiler; soft-zoning ahoy!
- 2013-02-23: Managed to get one board (wannabe boiler node) to pick up transmissions to the TRV from another board (thermostat node). Not got as far as looking at the content yet!
- 2013-02-18: V0.09 circuit diagram taking shape with a view to being soldered up tomorrow, possibly omiting the RTC part for now. The hope is that this same schematic will do for thermostat and boiler nodes.
- 2013-02-14: Controlling boiler directly and TRV via radio for first soft zone prototype! (r327)
- 2013-02-12: Hurrah! Made radio contact with FHT8V TRV so can now (just) control rad and boiler...
- 2013-01-26: Can call for heat from boiler with SSR in lieu of 2-wire mechanical thermostat (240V).
- 2012-10-30: On Smart Heating For Small Buildings in the UK ... a Department of Energy and Climate Change (DECC) workshop that lead to OpenTRV development, and to Radbot.
2014-06-01: Green Challenge Video (Out-take!)
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
Date | Milestone |
---|---|
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.
Tag | End Date | Who | Description |
---|---|---|---|
V0.1 | 2013-05 | DHD / 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.) |
Sensing2 | 2013-05 | MS / SP / DHD | Improved temperature and other core sensing. |
BoilerCtl2 | 2013-05 | DHD / BG / PC / MF | At least one different boiler control different to DHD's (binary) 2-wire 240V mechanical thermostat replacement. |
OccupancySensing1.5 | 2013-05 | DHD / BH | PIR, voice and some other early prototyping. |
V0.2-Sec | 2013-06 | MS / DHD / SP | Progress on encryption and authentication in situations where required, and to facilitate more/alternate ergonomic functional splits safely/reliably. |
V0.2-Protocol | 2013-06 | MS / BG / PC / DHD / SP | Progress on over-the-air and over-the-Net protocol (eg MQTT/UDP[/VPN]). |
Radio2 | 2013-07 | MS / 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-AllInOneMech0 | 2013-07 | BG / 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. |
OccupancySensing2 | 2013-08 | JK / DHD | Improved occupancy sensing and algorithms. |
Learning1 | 2013-08 | JK / DHD | Learning (occupancy/usage/performance/etc) algorithms. |
V0.2-PICAXE | 2013-09 | DHD | 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-Arduino | 2013-09 | DHD / 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-MinCost | 2013-09 | DHD / 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-Hub | 2013-09 | MS / 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-Cloud | 2013-09 | BG / 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. |
MSc2013 | 2013-09 | JK / DHD | The MSc projects and any contributions to/from them. |
V0.2-AllInOneMech1 | 2013-09 | BG / 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-AllInOne | 2013-10 | DHD / 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.2 | 2013-10 | DHD | 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-Deploy | 2013-10 | DHD / 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] 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.[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.[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.
[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).[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.
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:
Colour | Signal | Comment |
---|---|---|
black | 0V | |
brown | CTS# | Input; should be tied to 0V. |
red | 5V | Supplied from USB bus; limit to <2.5mA ideally. |
orange | TXD | output |
yellow | RXD | input |
green | RTS# | 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.
- 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.
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 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-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? |
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
- [hart-davis2014opentrv] OpenTRV: resource-constained computing: less is more
- [hart-davis2022thermostatic] Radiator thermostatic control
(Count: 2)