Monitoring and controlling MVHR with a Raspberry Pi

[MJNewton]

A few months back I promised (to @SteamyTea I think) to share further details about a side-project involving monitoring and controlling our MVHR unit with a Raspberry Pi. I was hoping to mature it to beyond beta stage before presenting it but, frankly, it'll probably always be in some unfinished state of development as between my extension and nearly-3yr old daughter I don't find much time for 'playing around' (as my wife calls this sort of thing). So, I thought I'd just share what I've got now in case it's of interest of use to others.

 

As background, our MVHR unit is a Titon HRV 1.25Q HMB Plus Eco which I believe is towards the lower end of the range but I got it cheap (£350) on eBay (an interesting story involving a development of 50-odd houses all fitted with the wrong model MVHR!). As a seemingly basic model it comes with potentiometer-controlled fans speeds and boost timer, absolute humidity detection for boost, automatic summer bypass and provision for switched boost inputs. It uses a Recair heat exchanger which, being their party, could well be common with a lot of other manufacturer's units. There's no fancy screen or controls, although Titon do make such a device but I'm not sure it works with our model. Furthermore, it's something like £150 and my Northern genes made me think I could do better with a Raspberry Pi for a lot less than that!

 

I'd like to show a detailed schematic showing all the component parts but as I don't have one I'll just list them:

 

- Raspberry Pi Zero W (a cut-down, low power, version of the Pi with WiFi) running Raspbian as the OS with lighttpd (web server), rrdtool (stats gathering and graph creation), a couple of 3rd party tools installed for reading the sensors and a couple of scripts (attached) pulling it all together

- Shelly 1 smart relay connected to the MVHR boost input (the Pi could handle this but the Shelly has been in for a while, hardwired to boost switches in the kitchen and outside the bathrooms, and has been left in for now as it works without issue) (Incidentally, the MVHR unit itself is powered through a Shelly 1PM smart relay which is connected to my smoke alarms such that if there's a fire the MVHR is switched off and I am sent an SMS to alert me of the fact, but all that is separate to this Pi stuff described here)

- Four DS18B20 1-wire temperature sensors taped inside the MVHR ports to measure supply, extract, intake and exhaust. A fifth is dangling in the loft space as, being outside the thermal envelope, I've always been curious what the temperatures are actually like up there

- One AM2302 humidity sensor (unfortunately not 1-wire and so requires different software to read and its own connection to the Pi's I/O port)

 

As things currently stand, the attached script (capturetemps.sh) reads all the sensors every 5 minutes (trigger by cron) and records their values, and various calculated ones too, to an RRD round-robin database using rrdtool. I've always been a fan of graphs - not entirely sure why - and so via creategraphs.sh (and rrdtool again) it also produces some charts for whatever time periods are required, examples of which are shown below. Speaking of time periods, it currently stores - and produces graphs from - readings at 5 minute intervals for 3 months, 30 minute averages for 6 months and hourly averages for 5 years in a 12MB database.

 

First off, system temperatures are recorded for all the ports which has been very reassuring in terms of the actually knowing this MVHR malarky actually does what it purports to do in terms of providing a supply of air at a temperature near to that being extracted (sometimes higher!) despite what's going on outside:

 

 

These temperature readings are also used to calculate the efficiency of the heat exchanger which again appear to show it broadly working as advertised:

 

 

The two calculation methods are as described by Paul Heat Recovery, the second of which (Method B) aims to factor in heat losses (or indeed gain) through the unit itself and hence be more accurate.

 

I also measure and graph instantaneous power consumption (figures obtained from the Shelly 1PM 'smoke alarm' relay I mentioned that the MVHR is powered through):

 

 

The system isn't yet fully installed (10 vents out of 12 done), balanced or properly configured and so the trickle (~8W) and boost (~42W) figures shouldn't be taken as necessarily relevant although that said we've been pleased with the performance at the current settings and so wouldn't be surprised if they don't change too much. This graph (not this actual one as it hasn't happened for a few days) also reveals when the summer bypass kicks in as it jumps the line up by ~5W.

 

There's also the loft temperature graph which doesn't serve much purpose other than curiosity, and use up the fifth-of-a-pack-of-five sensors I bought:

 

 

Speaking of curiosity, the novelty of looking at graphs will wear off one day I'm sure but one important reading I am logging is the humidity in the extract duct:

 

 

This one has been particularly interesting, and indeed useful, given that the large 'spikes' correspond with taking showers and so are easy for the script to detect (it currently looks for a >5% rise in any five minute period) and request a 30-min boost via the Shelly smart relay. It hasn't missed a shower yet, and I am confident it'll work well for cooking as previous experiments show it being quite easy to pick up simmering pans. The script also looks out for an absolute value also being breached but it's only been running for a few weeks and so I really need to see a full four seasons, particularly when windows are closed in winter with washing drying indoors, to determine what sort of value would be suitable for that. Given the freedom and flexibility of the script it could even self-adjust over the year if need be?

 

That's pretty much it! It's been good fun, a worthwhile learning curve and I think it'll have some utility too. My next step is for the Pi to take control of the summer bypass as the thresholds for operation cannot be adjusted on my unit - confirmed by Titon as being active when the extract temperature (dirty room air) is >22°C and intake (fresh outside air) >15°C, but not if the intake air temperature is greater than the extract as the heat exchanger serves to cool the incoming air slightly in such a situation. I think I'd like it to kick in sooner as 22°C is a bit warm for my liking on still summer nights where even the thought of 'cool' air being pumped in could have psychological benefits even if it won't actually cool the house down much given the volumes involved. Longer term I might even use the Pi to control the fan speeds too (reading the datasheets for them show they accept a 0-10v speed control input) but that might be overkill as I'm sure in time I'll be more than happy with just having fixed speed trickle and boost modes.

 

If I can expand on anything I'd be more than happy to do so. And if there's any 'real programmers in the house please forgive my scripts as whilst I'm aware there's something called 'programming style' I'm not following anything other than what works for me as an untrained tinkerer!

capturetemps.sh.txt creategraphs.sh.txt

Edited April 20, 2020 by MJNewton

[SteamyTea]

I shall get back to you when I am more awake as I would like to know how an RRD works, I have never managed to get one going.

 

But while I think about it, how easy is it to group data by say RH at different temperatures and times.

So something like:

Between 00h an 01h

Temp Range between 00 hours and 01 hours

0 to 1, mean RH

1 to 2, mean RH

2 to 3, mean RH

and so forth, and maybe putting a count in to get a temperature distribution.

[MJNewton]

This introduction might help explain how they work, although truth be told with things like this I tend to find someone else's example that's not a million miles off and work out what differences I need for my case. I'm usually too eager to get the end result, although inevitably I do end up learning something along the way.

 

As for your question, well, given my strategy above I am probably not best placed to answer! Or I might've just not understood the question properly and it is sounding more complicated at first glance than it really is.

[Savage87]

great stuff @MJNewton

How did you get the temperature sensors inside the ducts?

Are you not worried that might create leaks in the system?

[MJNewton]

I just taped them inside the where the ducts attach to the unit:

 

 

..before then fitting the semi-rigid ducting over which I've used to attached to the rigid piping (to avoid transferring vibrations):

 

 

I will eventually tape everything in place but they were a tight fit and so I don't think there'll be any leakage.

Edited April 21, 2020 by MJNewton

[SteamyTea]

13 hours ago, Savage87 said:

How did you get the temperature sensors inside the ducts?

When @Joe90 and myself set up his MVHR for monitoring, we put a small cut into the ductwork, popped the sensors in and then taped over the hole and cable.

 

@MJNewton

Am having an look at your scripts to see if I can make sense of them.

Is there a reason that you read the sensors with Bash rather than Python?

Not got to the bit about RDD yet.

[MJNewton]

11 hours ago, SteamyTea said:

Is there a reason that you read the sensors with Bash rather than Python?

 

Just familiarity; it's what I learnt when I first began to use Unix/Linux. There's probably a certain amount of ignorance of what else is available and better too I imagine!

[MJNewton]

I've drawn everything out so it's a bit clearer what external components I've used:

 

...and a screenshot of the GUI interface that the Shelly relays provide for app control over the LAN or Internet:

 

Edited April 22, 2020 by MJNewton

[SteamyTea]

9 hours ago, MJNewton said:

There's probably a certain amount of ignorance of what else is available and better too I imagine

Me too.

[Savage87]

@MJNewton How did you connect the shelly to the aico relay base?

 

I saw that you have boost switches for the bathroom/ensuite and you also have a humidity sensor on the extract. Do you have an automations based on humidity or do you use the swithes.

 

I'm currently doing the wiring for my unit, which has an integrated humidity sensor, I also have a humidity sensor in the bathroom, but I'm not sure if to use a boost switch in the wc or have in on a motion sensor?

[MJNewton]

7 hours ago, Savage87 said:

@MJNewton How did you connect the shelly to the aico relay base?

 

Whilst the Shelly is a 'smart' relay (a buzzword term which in most contexts just means it is 'network enabled'), like others of its type it can also accept a physical switched input. The Aico relay base is simply just a relay that activates when the alarm triggers hence it was just a case of wiring it up to the Shelly switch input.

 

Quote

I saw that you have boost switches for the bathroom/ensuite and you also have a humidity sensor on the extract. Do you have an automations based on humidity or do you use the swithes.

 

At the outset I wasn't quite sure how I'd want to control the unit, and I didn't want to assume I'd end up with a 'home automation' type control system or if it'd be suitable to retain if we ever sold the house. So, I figured that 'dumb' boost switches for extract rooms would be worthwhile and would provide utility for dealing with events that cannot be automated and do so without anyone having to reach for a phone etc!

 

Where something could be automated I was keen to do so and humidity-based boosting was an obvious one. This unit does have a humidity sensor but it is based on absolute values and whilst it worked pretty well it wasn't perfect e.g. it could trigger unnecessarily at times of the year when humidity is just generally higher or might miss an 'event' if set too high to avoid these false triggers. I figured a 'rate of rise' trigger - ideally alongside an 'absolute limit' trigger - gives a better method of control and so that's what I did with the Pi. It looks for a >5% rise in humidity in any 5 minute period and also keeps an eye out for a maximum threshold being breached.

 

I believe others have had success with a standalone humidity sensor/relay and so a homebrew Pi approach isn't the only way to achieve this though.

 

Quote

I'm currently doing the wiring for my unit, which has an integrated humidity sensor, I also have a humidity sensor in the bathroom, but I'm not sure if to use a boost switch in the wc or have in on a motion sensor?

 

I did consider a motion sensor but I felt I'd already got enough bases covered and didn't want to go over the top (if I hadn't already!). Furthermore, I was concerned at the time that unnecessary boosting at night might be a noise nuisance but as it happens whilst you can hear the boosting (airflow rather than fan/unit noise) it is not intrusive and so it would've been okay I think being triggered simply because someone nipped for a wee in the night.

Edited April 25, 2020 by MJNewton

[Savage87]

Thanks for the info!

 

In my bathroom I currently have a sonoff basic (tasmotised) with a temp/humidity sensor which has an automation if the humidity level goes over 90% ie when having a shower, turn the bathroom fan on. I'm planning to do the same with the MVHR, I will be keeping the motion sensor for the wc (to please the wife) and I will possibly attach it to another sonoff basic which I can automate to work only during the day.

 

Like you, I like to overcomplicate stuff, but I need to keep things simple for the family

[BristolBuild2020]

Glad to see someone has done something similar, I've taken it a bit further and my MVHR is totally proportionally controlled as the built in control is rubbish! 

 

I designed and got some customised Temp/Humidity sensors made up as the ones you could buy at the time were £££, unreliable (had 6 all died) and poor resolution/accuracy.

 

• Works to a target vs supply delta (So if the supply air is higher than the extract then it doesn't spin up as that's pointless...).
• Target is 50% / 60% or 10% / 15% higher than supply for day/night respectively.
• There is a shower boost detection algorithm (detects a rapid increase in extract humidity)
• Night limits (to quieten it down) - limits in the integral and proportion max but shower detection still unlimited.
• An increase in fan speed when people are in by 10% (disabled at night).
• An increase in fan speed when the supply temperature in relation to the extract temperature (with some conditions) as a 'cooling' mode in summer (it sort-of works...!)
• 10% to 100% fan speed variability.
• Gently ramps between day/night mode.

 

Just need a CO/CO2 sensor, which it will in the next house!

 

This is what our last 7 days and 5 years looks like... (easily see showers, cooking, etc!)

 

Very low average fan speeds recently as the supply humidity has been too close to the target humidity.

 

 

Edited October 30, 2020 by BristolBuild2020

[MJNewton]

Sounds great!

 

10 minutes ago, BristolBuild2020 said:

• 10% to 100% fan speed variability.

 

I'd love to hear how you did this. My unit has Ebm-Papst EC motors which accept a 0-10v speed input (and conveniently provide a 10v output for this) and so I was going to use a digipot to create a potential divider driven by the Pi. Speaking of which, what device are you doing your controlling from?

[BristolBuild2020]

A more electronically minded friend of mine designed me if I recall correctly, a mosfet based bit of circuitry (this was 6 years ago...).

 

Takes the 24V from the MVHR itself, converts it into a 0-10V signal from one of my RPI2's 3.3V PWM pins. (So I've got +24V, Control Signal and GND) wired to the MVHR.

 

I've then converted the 0-100% PWM signal into a 10-100% fan speed which I've then used to correct the PWM output.

 

So 10% is 10%, 50% is 50% and 100% is 100%... Etc.

 

I'll see if I can dig out the diagram...

 

 

[joe90]

I understand none of this tech stuff but wish my MVHR was more controllable. RH here varies between 20% and 90% and this confuses my RH sensor which controls the boost facility. I am hoping @SteamyTea understands this and draws me a (simple) diagram so I can make a controller. I always said ventilation is only required when air quality is bad but this seems difficult to measure.

[BristolBuild2020]

53 minutes ago, joe90 said:

I understand none of this tech stuff but wish my MVHR was more controllable. RH here varies between 20% and 90% and this confuses my RH sensor which controls the boost facility. I am hoping @SteamyTea understands this and draws me a (simple) diagram so I can make a controller. I always said ventilation is only required when air quality is bad but this seems difficult to measure.

 

His and mine require some software to actually make work (translate the RH Sensor values into an input to the MVHR).

 

What MVHR do you have? Does it have the ability to be externally controlled?

[SteamyTea]

I shall ponder this, but it is probably just a case of putting in a time delay to allow the RH peaks to settle.

[MJNewton]

1 hour ago, joe90 said:

I understand none of this tech stuff but wish my MVHR was more controllable. RH here varies between 20% and 90% and this confuses my RH sensor which controls the boost facility.

 

Do you mean it varies that much within a short time period (say, minutes)? Or just with the seasons? That said, 20% sounds awfully low - error value territory perhaps?

 

I thought I'd have to get really clever detecting humidity rises but as you can see from charts (and BristolBuild2020's) 'shower incidents' really seem to stand out. I started off with an arbitrary threshold of 5% rise in a five minute period and have found that picks every shower without fail and has never knowingly false-alarmed so I've just left it be. Incidentally, I did think about running the boost until the humidity value had reduced to some figure (say the pre-rise value) but took the easy way out and just boost for a fixed 30 minutes which seems to be sufficient.

Edited October 30, 2020 by MJNewton

[Gone West]

13 hours ago, joe90 said:

I understand none of this tech stuff but wish my MVHR was more controllable. RH here varies between 20% and 90% and this confuses my RH sensor which controls the boost facility.

I don't understand how RH can vary so much. The RH in all our rooms is more or less the same and is between 45 and 50 most of the time. The fans run at the same speed all the time and I didn't fit the humidistat because it hasn't been required. The RH increases when showering but it is temporary and is back down again after 10 minutes. It's strange there is so much variation between houses. Maybe it's down to vapour buffering or where you live.

[joe90]

22 minutes ago, PeterStarck said:

I don't understand how RH can vary so much.

you don’t live in Devon next to the Atlantic, just looking at my RH reading in the conservatory (during storm Doris or whatever) and it is 80%. Ground is heavy clay so all around us is sodden (think my new grass seed has drowned!). ?

[SteamyTea]

3 minutes ago, joe90 said:

you don’t live in Devon next to the Atlantic

Large bodies of salt water tend to stabilise the RH.

Trouble is there is not enough salt in it to reduce the RH  to a comfortably low level.

 

[MJNewton]

29 minutes ago, joe90 said:

you don’t live in Devon next to the Atlantic, just looking at my RH reading in the conservatory (during storm Doris or whatever) and it is 80%. Ground is heavy clay so all around us is sodden (think my new grass seed has drowned!). ?

 

I wouldn't be surpised if RH in a conservatory tracked external RH to an extent, hence 80% wouldn't be at all unreasonable. But 20% RH? That just seems *way* too low.

Edited October 31, 2020 by MJNewton

[SteamyTea]

It probably only hits 80% sometime after peak temperature.

Suppose the trick is to predict this time of 'not very nice to sit in' combination of temperature and humudity, and start to force more dryer and cooler air in before it becomes uncomfortable.

[joe90]

9 minutes ago, MJNewton said:

20% RH? That just seems *way* too low.

back during that heatwave in the spring. (RH just dropped to 60%)

Edited October 31, 2020 by joe90