Menu

Category Archives: Heat pump monitor

Last time, we installed OWFS to read the DS18B20 sensors connected to the 1-Wire bus and represent the temperatures as a file system. We now need to be able to publish them to the Emoncms to log and display the data.

Publishing to Emoncms is very easy – it has been designed to work with lightweight embedded devices with limited memory. A simple Python, Perl or C program could form a JSON request and post the data periodically. However, my Raspberry Pi is already using an RFM12Pi to receive data from my network of sensors. This uses a demon-ised Python script called oem_gateway to listen to the RFM12Pi and send the data to Emoncms.

You can install oem_gateway by following the instructions supplied on the github page.

I decided to modify oem_gateway instead of rolling my own script. The changes can be seen here, in my github repo.

A new OemGatewayListener called OemGatewayOWFSListener was created. This requires a number of settings in oemgateway.conf:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

# Listener for OWFS 1-Wire sensors

[[OWFS]]

type=OemGatewayOWFSListener

[[[init_settings]]]

# The path where the 1-Wire FS is located

path=/mnt/1wire

# The node to send as

node=9

# How frequently we should send

interval=10

# What resolution should we read the sensors with

resolution=11

[[[runtime_settings]]]

# A list of sensor IDs in full

# sensorX must be unique

# ID has 28. (family) and 0000 (blank CRC bits)

sensor1=28.33F749050000

sensor2=28.DB564A050000

sensor3=Dummy

sensor4=28.AB1663050000

These are relatively self-explanatory, probably with the exception of “Dummy” sensors. oem_gateway sends all sensor values using numerical indices i.e. {1:18.7,2:18.6,3:19.2} by iterating through a list of values. There are no names or explicit indices, so if one of the data values isn’t present, the indices change, and Emoncms has issues. Rather than change all listeners to have named sensor values, I decided to allow “Dummy” sensors to be placed in the list of DS18B20 IDs.

This means that we can unplug a sensor without impacting the indices, so that Emoncms shifting all the values incorrectly.

This has been publishing temperatures to Emoncms for a number of weeks with no issue now.

Whilst this is neat, I would much prefer to use an Arduino to poll the DS2482 and send the data wirelessly to this node – for next time!

Last time, we setup the Raspberry Pi so it could read the values from some DS18B20 sensors using the command line tool owfs. We’re a still few steps away from publishing these temperatures to Emoncms at the moment – namely getting owfs to start automatically, reading the values in Python, and then publishing them.

Running owfs automatically

When building owfs from source, you don’t get automatic startup as an option. It is quite easy to setup though.

First, let’s build a config file to store settings:

1

sudo nano/etc/owfs.conf

And copy and paste this in:

1

2

3

4

5

6

# owfs will source temperatures from this device

owfs:device=/dev/i2c-1

# file system location

mountpoint=/mnt/1wire

allow_other

It is important to note that this setup means that only owfs can access the 1-Wire bus. The default configuration is to run owserver and then have all other ow* processes connect to owserrver – i.e. it distributes the data. I want to keep my setup as simple as possible, so owfs connects directly to the bus.

There are a number of sensors that can be used to monitor temperature using a microcontroller. RTDs, thermistors, LM35s, thermocouples and so on. These are all analog output sensors, and this introduces a few problems:

You need to use a single analog input (ADC) for each temperature sensor, and this might also include additional buffer/amplifier circuitry, Wheatstone bridges or horrible stuff like cold junction compensation on thermocouples. ADCs also tend to be power hungry and slow in small microcontrollers.

Each sensor needs it’s own cable running back to the microcontroller.

As cable runs increase in length, you end up with all sorts of nasty analog issues like voltage drop, noise, etc.

There is a way to avoid these issues – using digital temperature sensors like the Dallas DS18B20. These solve the above problems.

You only need to use a small number of digital IOs to interface to the sensors (either directly, or via a bridge chip). This can be as little as a single pin.

Tens or hundreds of sensors can be on the same bus, massively reducing the number of inputs used, and simplifying cabling especially when you are reading more than a few sensors.

Driving a bus digitally is much easier than reading analog values. Many of the bridge chips have quite advanced features to deal with the analog gubbins (slew rate control, power active pull-ups etc.)

It’s for these reasons that I much prefer using DS18B20 sensors when I can. They do have some disadvantages though:

They are slow to respond and slow to read. With 9-bit precision, a reading takes at least 100ms. At 12-bit this increases to 750ms. You can sleep your microcontroller during this period, so this is more a latency than a power issue.

They have a narrow temperature range compared to a lot of sensors – only -55degC to 125degC. But this is more than enough for domestic heating flow/return and ambient air temperatures.

They are costly – about £4 a go through big suppliers (though closer to £1 if you buy 10 on eBay), possibly offset by other advantages like less circuitry and cabling.

They are only readily available in the bare TO-92 package. There are waterproof versions, there are stainless steel pocketed versions, but they are much harder to find than PT100 waterproof sensors.

In balance though, I feel they are ideal for this project.

Previously I have driven the DS18B20 sensors directly off a pin on the Arduino, bit-banging the 1-Wire protocol using the excellent 1-Wire and DallasTemperature libraries. This works – mostly. However, as soon as cable runs get longer or network topologies get non-ideal, you start getting errors – the dreaded 85degC readings.

The Raspberry Pi has far weaker IO drive than the Arduino (16mA per pin vs 40mA on an ATmega328), and is far less resilient to ESD and mishandling. I was really concerned that directly using an IO pin in a real world application would cause problems, so started looking for a add-on driver board. I quickly found the Sheepwalk Electronics RPI2 I2c to 1-Wire bridge. This is a small plug-on board, with a DS2482-100 1-Wire master, PCA9306 I2C voltage level converter, and a DS9503 1-Wire ESD protection IC. This takes the hard work out of doing 1-Wire, and is supported by lots of software. I also ordered a passive hub and a number of RJ45 connected DS18B20 sensors.

The I2C->1-Wire bridge

So, how do we get these working with a Raspberry Pi?

Make sure you can communicate with the I2C device

The I2C module is blacklisted by default on Raspbian. You need to edit a file to stop this happening by removing it from the mod probe blacklist file:

Shell

1

sudo nano/etc/modprobe.d/raspi-blacklist.conf

and comment out the line with a hash.

Shell

1

blacklist i2c-bcm2708

You also need to make sure the i2c-dev module is loaded. This isn’t dev=development but dev=/dev i.e. access the i2c device via /dev. To do this, edit modules.conf:

Shell

1

sudo nano/etc/modules

And add the line

Shell

1

i2c-dev

right at the end.

You can now either restart, or issue the following commands to make sure the modules are loaded:

Shell

1

2

sudo modprobe i2c-bcm2708

sudo modprobe i2c-dev

And you can confirm they have loaded using:

Shell

1

2

3

4

5

pi@raspberrypi2~$lsmod|grepi2c

i2c_dev55570

regmap_i2c 16451snd_soc_core

i2c_bcm270839490

pi@raspberrypi2~$

We’re good to start communicating with the DS2482-100 bridge chip now, and to do so, we are going to use i2cdetect, which is part of the i2ctools package. Issue the following command to install this

Shell

1

sudo apt-getupdate&amp;&amp;sudo apt-getinstall i2c-tools

Now run i2cdetect:

Shell

1

2

3

4

5

6

7

8

9

10

11

pi@raspberrypi2~$sudo i2cdetect-y1

0123456789abcdef

00:--------------------------

10:----------------18--------------

20:--------------------------------

30:--------------------------------

40:--------------------------------

50:--------------------------------

60:--------------------------------

70:----------------

pi@raspberrypi2~$

This shows the device at i2c address 18 – you can alter this to another value using some jumpers on the RPI2 board. You can see my i2c bus isn’t exactly jam packed, so we will stick with 18.

Communicate with the 1-Wire bridge

Now we need to communicate with the 1-Wire bridge. There are a number of pieces of software that can do this, but for simple temperature monitoring, OWFS (1-Wire file system) seems popular.

The standard package available from normal repos is 2.8p15, and the latest code is 2.9p1. There are enough changes that I wanted to build from scratch.

There are a few bits and pieces that need installing for this to work on the default Raspbian install.

Shell

1

sudo apt-getinstall python2.7-dev libfuse-dev swig

This won’t build PHP etc. libraries for OWFS but I am not very likely to be using PHP.

You need to make sure this confirms that it will build with the options you need.

Shell

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

Current configuration:

Deployment location:/opt/owfs

Compile-timeoptions:

USB isDISABLED

I2C isenabled

W1 isenabled

Parallel port DS1410E isenabled

Zeroconf/Bonjour isenabled

Debug-output isenabled

Profiling isDISABLED

Tracing memory allocation isDISABLED

1wirebus traffic reports isDISABLED

Module configuration:

owlib isenabled

owshell isenabled

owfs isenabled

owhttpd isenabled

owftpd isenabled

owserver isenabled

owexternal isenabled

ownet isenabled

ownetlib isenabled

owtap isenabled

owmon isenabled

owcapi isenabled

swig isenabled

owperl isenabled

owphp isDISABLED

owpython isenabled

owtcl isDISABLED

pi@raspberrypi2/usr/src/owfs-2.9p1$

You need i2c and owfs support in there for what we are doing.

Now you need to build and install, expect this to take a long time on the Pi (30-60m):

Shell

1

sudo make&&sudo makeinstall

owfs allows us to access the i2c devices using the file system. To set this up, first create a directory for the devices to show up in:

Shell

1

sudo mkdir/mnt/1wire

owfs uses something called fuse to allow it to create the filesystem representing the 1-Wire bus and devices. I don’t fully understand what it does, but you need to change one of the options by editing fuse.conf:

Shell

1

sudo nano/etc/fuse.conf

and then uncomment this line by removing the #:

Shell

1

#user_allow_conf

And last, at least for this part, we are going to start owfs manually and check that everything is working:

Shell

1

sudo/opt/owfs/bin/owfs--i2c=ALL:ALL--allow_other/mnt/1wire/

This starts owfs, looking at all available i2c bus masters, and mounts the result in /mnt/1wire. So we take a look in /mnt/1wire

The directories starting 28. are the temperature sensors. Four connected to the hub and one on the hub itself. The other directories and files control settings and provide information about the bus and communication.

Now we can read the ttemperature off all of the sensors:

Shell

1

2

pi@raspberrypi2/mnt/1wire$cat28.*/temperature

17.2517.187517.62517.37517.125

Yes, our front room is that cold. I broke the heating last night.

The passive hub with additional DS18B20 sensor

In the next part I am going to get owfs starting automatically with the Pi and then read the sensors in a simple Python program.

I'm a security researcher and reverse engineer. By visiting this site, you must realise that any or all files on this site may be jam packed full of the finest exploits, tricks and other gubbins. You might also get geo-located and port-scanned for fun and profit.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRead More
If I really want to track you, by tricking you into visiting this site, then it's going to be a lot more subtle than a browser cookie.