OpenTRV: thermostatic radiator valves and remote boiler control

D

DamonHD

Senior Member
Hi,

I just got this working from end-to-end today, and it's still very crude, but demonstrates the concept.

This uses an 18M2+ PICAXE+DS18B20 to sense temperature* and control a wireless thermostatic radio valve (via an RFM22B) to regulate room temperature with a very simple 1-button / 1-LED UI to select between "warm" (~18C) and "frost protect" (~5C) modes.

This system also has an identical boiler-control board eavesdropping on the radio transmissions to the TRVs and if any of them is set to anything other than fully closed, the boiler is switched on (via an SSR on the two-wire thermostat connection).

The net result is the ability to control temperature room-by-room, getting heat just where you need it (providing you keep doors closed!) not for the whole house. Energy (and thus money and CO2) savings could be substantial.

There is already commercial kits to do this, though all proprietary and arguably overpriced, and not easy to integrate with other stuff.

But OpenTRV already has a the ability to set back room temperature when no one is in the room.

*This design senses ambient light levels; if it's too dark for anyone to be awake and active, the target temperature is set back (lowered) by 1C, nominally enough to save 8% of heating demand in the UK.

See a snapshot of hardware and software here:

http://www.earth.org.uk/OpenTRV/snapshots/20130226-r594/TestFHT8VBoilerNode.bas
http://www.earth.org.uk/OpenTRV/snapshots/20130226-r594/teststub.out.bas
http://www.earth.org.uk/OpenTRV/snapshots/20130226-r594/DHD201302L0.out.bas
http://www.earth.org.uk/OpenTRV/snapshots/DHD201302L0-r429.pdf

(Or nominally here https://sourceforge.net/p/opentrv/code-0/598/tree/trunk/PICAXE/DHD201302L0/snapshots/20130226-r594/ but I can't see what I expect to there at the moment.)

With a photo or two here:

http://gallery.hd.org/_c/energy-matters/_more2013/_more02/OpenTRV-prototype-20130220-V0p09-PICAXE-18M2-microcontroller-DS18B20-temperature-sensor-DS1306-RTC-RFM22B-radio-LDR-USB-powered-on-stripboard-closeup-4-DHD.jpg.html

Rgds

Damon
 
Last edited:
B

BeanieBots

Moderator
Probably just me having a senior moment but I spent several minutes on both links and never got to see any code or schematics so I gave up:mad:
 
D

DamonHD

Senior Member
It's me or SourceForge having that senior moment, not you: I can see stuff in the SVN tree but not in that Web view, for reasons not entirely clear to me though I can guess at.

Anyhow, I've now put replacement links up which I hope will work instead.

Rgds

Damon
 
B

BeanieBots

Moderator
Working now.
Thanks for sharing.
Where can I get the valves? The only ones I've found so far are 433MHz and use a protocol which may well be beyond PICAXEable.
 
D

DamonHD

Senior Member
The protocol which this project currently talks is for the Conrad FHT8V wireless TRVs. Conrad has a local UK site which is efficient. Tell me if you want a link to the right item in their on-line shop.

Until I get the sync protocol with the valve worked out this is technically breaking the ISM rules by having over a 1% transmission duty cycle, but I expect that to be sorted in a few days and I'll post a software update.

If you do want to try it out I would be very happy to try and help get you sorted out.

Also, the latest version of the circuit diagram has a lot more decoupling in it, and the next layout will take on board some of the excellent suggestions elsewhere in this forum!

Rgds

Damon
 
B

BeanieBots

Moderator
Found it on the Conrad site, thanks. (had to be the dearest didn't it!)
Home automation is a little down on my priority list at the moment (still waiting to proportionally automate spare PV to immersion heater) but thanks for the offer of help.
I'll take you up on it when I get around to trying to send and receive the bit-bang stuff.
Maybe US radiators differ from UK one's. All of mine have the inlet/outlet at the bottom which would result in all of those valves having the display upside down:(
 
D

DamonHD

Senior Member
We are intending to direct-drive the valves ourselves as an alternative, but first we have some 3D printing and fun with thingiverse.com over the summer.

We will we designing for the standard(ish) European M30 TRV fitting; do you know what yours are?

Rgds

Damon

PS. All my rads have inlets/outlets at the bottom, but with the valve vertical where the FHT8V expects horizontal. Never mind!
 
Last edited:
D

DamonHD

Senior Member
And today I extended the boiler node to also control a local TRV in the kitchen (where the boiler is), so now I have two soft zones (kitchen and rad next to my desk).

I'll build up another board and do the living room and possibly one more for our youngest's bedroom, with a 'learn' mode to warm the room at the say time every night automatically.

I'm up to about 90% of available code space on the 18M2+. (Gosub chaining saves 4 or so bytes each time, BTW.)

Rgds

Damon
 
B

BeanieBots

Moderator
All my valves are manual at the moment.
After a lot of browsing I found some Honeywell versions that look hopeful (as far as fitment is concerned) but they are 433Mhz and almost certainly a different protocol.
I've just taken delivery of my latest Rev-Ed order which included their RF modules so hope to rig up a 'sniffer' and see what some of the remotes put out with an aim to replicate their codes.
All my lights are on RF (an assortment of versions) so these will be my first priority.
Also treated myself to the Sheild base and some extra boards because I'm getting lazy and wanted to speed up prototyping for the solar power converter which I've been promising myself to do for over six months now.
The fireplace (complete with log burner) is complete now so I'm hoping SHE will give me some time off for electronic projects!
 
D

DamonHD

Senior Member
There is an OpenHR20 project http://openhr20.svn.sourceforge.net/ that may help with talking to those valves.

OpenTRV is aiming to be vendor-neutral, which implies being able to talk other protocols than the FHT8V too, so if you happen to do manage to get your PICAXE to talk to your Honeywell kit then OpenTRV would be interested in a code contribution if you are feeling kind!

(We have some X10 and HomeEasy code fragments already.)

Rgds

Damon
 
D

DamonHD

Senior Member
I built another node today, taking on board as much of the layout and decoupling advice as I could.

It's currently in use / being tested, but I will test to see if the changes avoid the TX and clock speed problems that I saw before or if something else is going on too.

Rgds

Damon
 
D

DamonHD

Senior Member
B

BeanieBots

Moderator
I had go using the published code but only at 16Mhz on a 28X2. (adjusted timing accordingly).
Even after quite a bit of fiddling, I could only get unreliable results so 32Mhz really is needed and it really is near the edge of what PICAXE can do.
I'm still playing with alternative methods that are more reliable at lower clock speeds but will end up very specific to a controller type.
I'll post when it's worthwile.
 
D

DamonHD

Senior Member
What was unreliable exactly, just so I can understand? The TX section? You may well be doing my debugging work for me (in which case, thank you in advance)! B^>

Rgds

Damon
 
S

srnet

Senior Member
The SPI interface on the RFM22 is rated for 10Mhz clock speed.

To get that clock speed on the hardware SPI you need to run the PICAXE at 40Mhz.

The SPI actually works, and seems to be reliable, at SPI clock speed of 16Mhz (PICAXE at 64Mhz)
 
D

DamonHD

Senior Member
Is this when using pulsout with a unit of 1?

I actually bumped that up a bit to try to avoid any timing issues anyway.

Rgds

Damon

PS. Our new PCBs (off to fab today, I hope) have reasonably sensible power/decoupling/layout, so I may be able to try cranking TX at full speed on them and see if it all works properly.
 
S

srnet

Senior Member
No thats using the hardware SPI interface on the PICAXE. It will drive the SPI to the RFM22 much faster than bit banging, but the RFM22 copes very well, on a decent layout.

Pulseout @ 32Mhz with a unit of 1 is a clock pulse of 1.25us, but then there will be the gap for shifting the data between pulseouts, so the actual data clock to the RFM22, might only be in the 100khz region, maybe less.

That your having problems at such a slow interface speed does suggest a fundamental issue and I would want to specifically identify it. It may well appear to run OK at a slower 18M2 clock speed, but the fundamental problem remains, which is not good for a device that is required to be long term reliable.
 
D

DamonHD

Senior Member
Indeed, yes.

This is the first attempt anyway, done to a tight deadline.

Any significant PICAXE revision is quite likely to go to 20X2 now (though the reduced RAM may be an issue) and use hardware SPI.

But I am having other issues too, which may share an underlying cause, so thanks for the continuing analysis.

Rgds

Damon
 
B

BeanieBots

Moderator
When I said running at 16Mhz I meant "m16".
The unreliability I was having was with the decode which had frequent miss-reads.
I've now fitted a 16Mhz resonator so now I can run at 64Mhz which has made massive improvements to my own attempts but I've not had a chance to test your code at that speed. This is mainly for selfish reasons because my modules are a different protocol.

I have a JSJS Designs module (aka LightwaveRF) which I think is the same protocol as HomeEasy so I'll have a play with that when I get a chance.
 
D

DamonHD

Senior Member
Decoding RFM22B register values read in over SPI?

I can read/write at m32 normally at the rest of the time, but maybe with too much RF noise and the supply rails bucking around it's just too difficult during TX. I think I did try waiting until the TX should have finished before polling with no improvement, but I could try again...

I could possibly switch the code to look for TX buffer empty as a status/level rather than a one-shot interrupt.

Rgds

Damon
 
S

srnet

Senior Member
I have run the code for sending packets a lot, it works just fine checking for the packet sent flag, reg $03, bit 2. Works very reliably at 100mW for the RFM22 and indeed 1W for the RFM23.

I can tell if it fails because I have the TX packet routine set to send the same packet 3 times, so if the packet sent flag is missed the timeout comes into action and the extra delay between packets can be clearly heard.

If it were power supply noise then reducing the power to 1mW should stop it happening.
 
D

DamonHD

Senior Member
(1W for the RFM23? I believe its max output power (7) to be 25mW or else I'm misunderstanding something else horribly!)

So you're saying it looks like my TX code is OK, so likely the layout/decoupling is the villain?

Rgds

Damon

PS. I am now running at considerably reduced output power, and I am now legal (25mW), which should also help.
 
S

srnet

Senior Member
RFM22B is 20dBm (100mW), RFM23BP is 30dBm (1W).

You have not given a full description of what you mean by unreliable, exactly what is happening, which would help.
 
D

DamonHD

Senior Member
Interesting: I was not aware of the 'BP' part, just the 'B' part:

Output power range
␣␣+20 dBm Max (RFM22B)
␣␣+13 dBm Max (RFM23B)

The problem that I encountered with TX was the TRV apparently not receiving the transmission and/or my not being able to detect the TX buffer empty event reliably.

On RX, which I'm still coming back to, while I can reliably sync to the packet header I seem rarely able to read the packet content at the moment, though I have worked round actually needing to for the moment.

Rgds

Damon
 
D

DamonHD

Senior Member
BTW, do you read both status registers while polling for TX to finish, or just register 3.

Rgds

Damon
 
S

srnet

Senior Member
On the RX side, setup so that the packet received flag is only activated when a fully valid, and CRC checked packet is received. Then if you cannot 'read' the packet content, it has to be a software issue.

On the TX side, does the packet actually go out, you should be able to hear it on a suitable radio.

If the TX routine hits a timeout (packet sent flag not detected) has the RFM22 reset its register set to default ?

For TX complete I just read reg $03, why would you want to read reg $04 ?
 
D

DamonHD

Senior Member
Hi,

1) I'm using FIFO mode since I am constructing the entire bitstream including preamble, etc, so there is no CRC for the RFM22 to check. (Similar code works with ATMEGA/RFM23 BTW, so I'm not just punting!)

2) When I was experiencing this I had not suitable radio to listen with. I do now have other RFM devices and I have a couple of dumb AM 868 MHz devices which I bought to attempt to do this, but have not yet tried.

3) Which register?

4) Because it's not clear to me if both status registers should be read together. If your experience says not that is useful, thanks!

Rgds

Damon
 
S

srnet

Senior Member
I would set up some test routines using the packet handler for both TX and RX it will be a lot easier to work out what going on. With the packet handler in charge and CRC enabled, you will know for sure if what you send is what is actually being received.

3) Which register?
Click to expand...
register set , i.e all of them. No need to check them all though, just see if the 3 main frequency setting registers have gone back to the default value.

Here is my TX packet code, it better be reliable, its due to go into earth orbit;

Code: 
gosub TXon
		
		waittime = 0
		
		do 
			pause 20
			inc waittime
			low NSEL 				
			HSPIOUT($03)
			HSPIIN(RFMDATA)
			high NSEL
			RFMDATA = RFMDATA AND %00000100 	'test if packet sent
		loop until RFMDATA > 0 OR waittime > 250 	'use a counter, just in case the TX sent flag is missed ....
		
		gosub TXoff
 
D

DamonHD

Senior Member
OK, interesting idea.

I think that that might require enough changes that the problem might be masked (and it might take a while to set up!) but it's definitely worth a shot if I'm not getting anywhere otherwise.

I will be trying to *avoid* firing my rads or controller into space!

Rgds

Damon

PS. Just modded TX code to only read status register 1 and that small tweak at least is fine, thank you. My still-Earth-bound TRV is responding.
 
S

srnet

Senior Member
DamonHD said:
I think that that might require enough changes that the problem might be masked
Click to expand...
Indeed it might, that is the point.

You could then show that the hardware was operating reliably, at high speed and using max RF power..........
 
D

DamonHD

Senior Member
Well, this may be premature, but the 'unreliable' TX at high PICAXE clock speed *may* now have been fixed. (I have to keep observing for a while longer to be sure.)

The difference is that now I am terminating the wait-for-TX-to-finish loop on seeing ipksent ONLY, not just any non-zero status value. I suspect that I just got away with my looser test by luck at lower clock speeds.

I may have been terminating early before on 'TX FIFO almost empty' status (itxffaem) which (at least now) seems to show up as well.

Anyhow, more observation required to be sure, but looks very promising so far.

Rgds

Damon
 
S

srnet

Senior Member
In which case you could be terminating the transmit before the packet was sent.

I did try to read the code ..........
 
D

DamonHD

Senior Member
Yes, I could have been, amongst many other crimes your honour.

Though I also had some lock-ups (ie missing the ipktsent or it not happening), and when this was happening I was far less confident around the whole RFM22.

I do have at least one independent receiver now, on the RFM22 on my boiler unit. So now I can listen out for both my TRV opening up and my boiler firing to check that TX has or hasn't worked!

So, my entire central heating system is now relegated to the status of "test equipment" with audio feedback I think.

Rgds

Damon
 
S

srnet

Senior Member
When I was range testing my RFM22 setup, one of the diagnostics I introduced was to send a sequence number appended to the end of each packet.

Then I wrote software for a receiver, see the 'Groundstation' in projects section, that recorded to the serial terminal a count of received packets, plus the received packet sequence number, so you could tell from a log if packets were being lost.

I then used this combination to run long term tests (over several days and weeks) to test for packet reception reliability, I was also then able to tweak program and RFM22 settings to see the effect on reliability.

The revised and now tested routines were then incorporated into real programs and I could be fairly confident that the base routines were reliable.

One additional thing you ought to consider, as this is a device that you need to operate 24\7 reliably, there ought to be some fail safe there in case the software gets 'confused', the programmers motto is after all 'there is always one more bug'.
 
D

DamonHD

Senior Member
This is an early prototype and thus is allowed to be a little flaky for the time being, but I do design and implement defensively, so there is already a "panic" routine that can be called if something is seriously out of whack, etc, etc.

I like the sequence number idea... I'll keep that on the back burner for when I've resolved some of the fundamental problems (such as not being able to read the packet content at all!).

Rgds

Damon
 
D

DamonHD

Senior Member
Hurrah!

Got the FHT8V radio sync protocol running so TX duty cycle down to 0.1% from an illegal 7% before, but have almost filled the 18M2+'s little brain and lots left I'd like to do, which suggests upgrade to 20X2 and/or ATMEGA. B^>

http://www.earth.org.uk/OpenTRV/snapshots/20130312-r862/DHD201302L0.out.bas

What is the actual effective increase in code space (lines of code that will fit) of the 20X2 over the 18M2+

The reduced RAM space should be OK for my purposes.

I remain really impressed with the PICAXE for what it is!

Rgds

Damon
 
D

DamonHD

Senior Member
hippy

hippy

Technical Support
Staff member
DamonHD said:
What is the actual effective increase in code space (lines of code that will fit) of the 20X2 over the 18M2+
Click to expand...
It's effectively "double", but there will be some increased overhead in addressing the extra memory space. It of course depends on what each line of code does, what those lines are and how complex.

The best way to get a realistic feel is to simply note the memory usage, change to 20X2 and see what memory usage that has. That will also show up porting issues with moving to a 20X2, such as no NAP or READINTERNALTEMPERATURE commands, no 'time' variable, having to change a couple of 'input' pins.
 
You must log in or register to reply here.
Top