Single Room MVHR

[Onoff]

On 01/07/2019 at 09:03, PeterW said:

 

No

 

Just fit it... CT1 (or cheap sealant if it’s coming out in the next 24 months) to the wall and be done with it, but bear in mind you should really have a fall on the duct to an outside vent so any condensation that forms inside runs to the outside not the inside. Bit of fibre insulation around the first part of the duct will help stop it initially. 

 

How about this stuff?

 

 

https://www.tlc-direct.co.uk/Products/FDAD4.html

 

Pretty sure I have occasional visitors running along the eaves where this duct goes through so I see a potential chewing issue. If they get into the duct they can get into the void in the wet room corner!

 

Many holes to block still!

[PeterW]

46 minutes ago, Onoff said:

 

How about this stuff?

 

 

https://www.tlc-direct.co.uk/Products/FDAD4.html

 

Pretty sure I have occasional visitors running along the eaves where this duct goes through so I see a potential chewing issue. If they get into the duct they can get into the void in the wet room corner!

 

Many holes to block still!

 

Cos it’s crap and not designed for what you want to do ..?? You’ve no chance of attaching that to a spigot on a fan and turning it 90 degrees up. Use convoluted aluminium duct, and buy a roll of 100mm rockwool and use the rest to insulate over the top of the ceiling. 

[Onoff]

If I were to run this stuff (is this convoluted aluminium duct?), through a good length of soil pipe could that act as the basis of a DIY heat exchanger? 

 

Thinking because of the undulations it would retain heat (to exchange) better than a straight through, smooth sided metal tube.

 

Thanks

 

[Ed Davies]

To get appreciable heat exchange you need a lot of area.  Some arithmetic is called for. Here's some I did earlier: https://edavies.me.uk/2014/03/mhrv-area/ which might give you an idea.

[Onoff]

2 minutes ago, Ed Davies said:

To get appreciable heat exchange you need a lot of area.  Some arithmetic is called for. Here's some I did earlier: https://edavies.me.uk/2014/03/mhrv-area/ which might give you an idea.

 

Erm...maths? I'm really more a monkey see/have idea, do.

 

So...Raspberry Pi. I want to measure 4 temperatures simultaneously. I assume I will use DS18B20 sensors. I'd like to set it up sensing 24/7. An at a glance graph would be good. Even better, linked to a phone.

 

Any pointers?

 

Cheers

[SteamyTea]

3 minutes ago, Onoff said:

I want to measure 4 temperatures simultaneously. I assume I will use DS18B20 sensors

Consider DHT22s, they show the RH as well.

3 minutes ago, Onoff said:

An at a glance graph would be good. Even better, linked to a phone.

 

It is easy to get the numbers showing, but I have not yet found any code (that I understand) that shows a real time chart.

Seems that most of the stuff online wants to push it though a database package somewhere along the line.

A nice, simple bit of Python is what is wanted, maybe @Ed Davies could knock some up for us all.

[Onoff]

9 minutes ago, SteamyTea said:

Consider DHT22s, they show the RH as well.

It is easy to get the numbers showing, but I have not yet found any code (that I understand) that shows a real time chart.

Seems that most of the stuff online wants to push it though a database package somewhere along the line.

A nice, simple bit of Python is what is wanted, maybe @Ed Davies could knock some up for us all.

 

I imagine my lad could do it. Is there any restriction on length for the cabling to a sensor?

[SteamyTea]

17 minutes ago, Onoff said:

Is there any restriction on length for the cabling to a sensor

I have run 7 sensors on a 10 metre cable.  I may have changed the resistor, can't remember which way though.

As a RPI Zero W is only a tenner, may be easier to use a few more.

Or use some ESP8266, pretty sure they can take a DS18B20's, can certainly take the DHTs.

There is also the BME280's, they do temp, RH and pressure.

22 minutes ago, Onoff said:

I imagine my lad could do it

What would be nice is a simple chart, one that can show all records, monthly, weekly, daily and hourly at the touch of a button, or a swipe of the screen.

One problem with charts of a phone is that they are so small that they are hard to read.  So may need stacked y-axis to show different sensors.  Not sure how easy that is to do.

[SteamyTea]

4 minutes ago, SteamyTea said:

ESP8266, pretty sure they can take a DS18B20'

https://randomnerdtutorials.com/micropython-ds18b20-esp32-esp8266/

 

Yes they can.

[MJNewton]

7 hours ago, SteamyTea said:

Consider DHT22s, they show the RH as well.

It is easy to get the numbers showing, but I have not yet found any code (that I understand) that shows a real time chart.

Seems that most of the stuff online wants to push it though a database package somewhere along the line.

A nice, simple bit of Python is what is wanted, maybe @Ed Davies could knock some up for us all.

 

Whilst not quite real time (updates every 5 minutes but could be made to be shorter), I log various temperatures with a Raspberry Pi:

 

 

 

It's to monitor my MVHR but, as you can probably tell by the figures, the sensors aren't installed yet! The graphing can be configurable on-demand too but at the moment it's a fixed 'past two days' x-scale.

 

Getting realtime figures 'on demand' could also be done. Happy to share my code when I'm back home (freezing my nuts off in Finland at the moment!)

Edited December 11, 2019 by MJNewton

[SteamyTea]

2 minutes ago, MJNewton said:

Happy to share my code when I'm back home

Yes please.  I could rig it up to @joe90's MVHR that I stuck a RPi on.

 

[Ed Davies]

18 hours ago, SteamyTea said:

As a RPI Zero W is only a tenner, may be easier to use a few more.

 

Any idea where has them in stock? Lots of places advertise them at reasonable prices but don't actually stock them.

 

I have a bunch of temperature and temperature & humidity sensors connected to various things. My central logger is a RPi (running Raspbian with my Python code) but only one of the sensors (a DS18B20 temperature sensor which measures the temperature of the flow to my study radiator) is directly connected to that. The rest talk to the Pi via Wi-Fi:

 

1) 3 vAir [¹] monitors which log via MQTT. One does temperature, humidity, pressure, CO₂ and light level in the bedroom. The other two do temperature and humidity in the kitchen and my study. These are based on the ESP8266.

 

2) 1 ESP32 in the living room which has a DS18B20 running my own firmware which sends the temperature via UDP.

 

3) 1 Sonoff TH16 (ESP8266 based) in the kitchen with a DS18B20 running my own firmware to report the temperature in the fridge salad tray via UDP and control the power to the fridge as the fridge's own thermostat doesn't work properly.

 

4) 1 Sonoff TH16 with a DS18B20 with my own firmware underemployed in the airing cupboard to report the temperature of the top of the DWH cylinder coil.

 

The DS18B20 directly on the Raspberry Pi is connected via a USB 1-wire bus master because I had one (originally used on my laptop) and because logging via the One Wire Filesystem (apt install owfs) was so convenient in Python. The more direct and, in some ways, more-convenient-for-wiring way to connect DS18B20s to a Pi is via  GPIO pins. Unfortunately, AFAICS  owfs doesn't work with that.

 

That's a long-winded way of saying I've tried all the likely combinations except the one I'm about to actually recommend. ?

 

So what do I think @Onoff would be best doing? Get a Raspberry Pi (any one with Wi-Fi that's cheap and available), connect the some DS18B20s to a GPIO pin with a suitable pullup resistor and use whatever code to is needed (must be documented all over the place but I haven't looked, yet) to put times and temperatures in a file then plot the results with a spreadsheet or whatever on his main system.

 

The advantage of the Pi over an ESP8266 or ESP32 or whatever is the proper operating system which will be fairly familiar to an Ubuntu user who's comfortable using the command line and the availability of plenty of space for storage. With an ESP thingy you'd need to send the data recorded to another always on computer for logging which might not be ideal.

 

[¹] Sadly the chap making these has given up. I think he wasn't charging enough, if he'd have charged half as much again it wouldn't have been too expensive but might have been worth his while to continue.

 

[SteamyTea]

5 minutes ago, Ed Davies said:

Any idea where has them in stock

Ordered one from PiHut, day before yesterday.

They only let me have one, and it was the one without the pins soldered on.

6 minutes ago, Ed Davies said:

use whatever code to is needed

There is loads. I keep meaning to make my code a bit posher. Want to add the sensor ID so I don't have to muck about typing it in.

 

I also recommend a real time clock and a USB to TTL cable, makes setting up dead easy.

 

Have been having trouble setting up a static IP address on the latest version of Raspbian (Buster).  They seem to keep changing the way this is set up. It really is the sort of thing that needs to be done in one text file, right at the very beginning.

[SteamyTea]

13 minutes ago, Ed Davies said:

monitors which log via MQTT

I keep seeing this, what is MQTT and why is it hard to set up.

[PeterW]

Lots in stock

 

https://shop.pimoroni.com/products/raspberry-pi-zero-w

[Ed Davies]

2 hours ago, SteamyTea said:

I keep seeing this, what is MQTT …

 

MQTT is a protocol over TCP which sends simple messages which are fragments of text (or other arbitrary bytes, I think, but that's not how it's usually used) which are often just numbers or bits of JSON or whatever. Each message is labelled with a “topic” which is a string which has the same hierarchical form as a Un*x file name (names separated by '/'). Some topics from my system: cc/power, dhw_cyl/coil/top/temperature, living-room/temperature, study/humidity.

 

At the middle of the system is a broker which receives all these messages from various clients scattered around the place and passes them on to any clients which are subscribed to them.

 

There are various implementations of MQTT. I use mosquitto which is in the Debian and hence Raspbian and Ubuntu repositories so it's just a small matter of apt install and away it goes (it's controlled by systemd).

 

There's a separate package (mosquitto-clients) which contains commands to publish and subscribe from the command line. E.g., from my main Ubuntu machine I can subscribe to all the topics on the MQTT broker on my RPi (called ripple) asking for verbose output (i.e., starting the lines with the topic before the message) using

 

$ mosquitto_sub -h ripple -v -t '#'
metar/EGPC/dtime 2019-12-12T13:20:00.000Z
metar/EGPC/temperature 3
metar/EGPC/rh 87
metar/EGPC/wind/speed 2
metar/EGPC/wind/direction 200
cc/power 210
cc/power 207
george/uptime_secs 2382.41
cc/power 208
esp/30aea4739ca4/uptime_millis 39507626
ow/28b21ac801000038/temperature 13.75
living-room/temperature 13.75
kitchen/temperature 11.81
kitchen/humidity 59.62
cc/power 204
cc/power 81
study/radiator/temperature 48.1875

 

The standard Arduino libraries for the ESP8266 and ESP32 have an MQTT implementation built in which seems to mostly work [¹].

 

There are also a few MQTT clients for Android (and, I'd assume, iOS). I use MQTT Dash because it was the first one I tried and it seems to work reasonably well.

 

MQTT doesn't really have much idea of history; it only serves current values for topics (though you can set a “retain” bit when publishing a message so any client which comes along before you publish the next one will get the previous version and not have to wait until the next one is published - I use this for one special case but don't use it a lot).

 

 

3 hours ago, SteamyTea said:

… and why is it hard to set up.

 

It's not, really. Just needs setting up what machine has the broker and what topic to publish to in each of the sensors and so on. But it only does part of the job, collecting data from various sources together into a stream - you still need something to do the logging and graphing.

 

[¹] I've stopped using MQTT in my ESP32 and Sonoff code (I now use UDP) because of a suspicion that the MQTT implementation was causing hangs when it didn't cope with a flaky Wi-Fi connection very well (which also happen once in a while on the vAir monitors which I assume use the same implementation) but I'm still seeing the odd ones so maybe that's not the problem.