Water Consumption Monitoring
This build documents my experience of setting up the emonTx for use as a water usage logger using the IRQ pulse counting port on the emonTx to count the pulse outputs from my water meter.
The metering source
In order to implement water monitoring, I ended up buying a cheap water meter from eBay for about £16, which pulses for every 1 litre used. A local plumber fitted it for £65.
The old water meter that was already fitted by the utility company (SevernTrent) is wired to a touchpad which they use to take a reading about every 6 months. I sat for ages, and wasted a lot of water, trying to see if it actually generated a switched or voltage-change pulse. I suspect it pulses for every cubic meter, as that is the number that appears on our bills, but I couldnt actually detect anything though.
I had a couple of frustrating calls with the utility company trying to find out how the meter worked, or whether they would swap it for one that pulsed every litre, but they just didnt understand what I was trying to do, so I ended up getting my own.
To make sure the meter was working accurately, I connected it up to a commercial pulse logger, made by Enica. I ran the taps for a measured litre and 10 litres of water, and the Enica logger showed the water meter was accurate enough to generate reliable figures.
Other people may be lucky, and already have a nice meter they can use.
The emonTX build.
I bought a TX kit, which comes supplied with the components for 1 channel CT monitor, being originally designed for power usage.
I followed the pictorial build provided by Glyn. However, I was initially confused by the instructions, as they are for a full 3 channel build - I thought I was missing a load of components. Glyn advised me of my error, although I was actually one capacitor down, which I got from Maplin. Glyn did offer to send a replacement.
I think there is still room for improvement on both the 3 channel and 1 channel build instructions, and when I get time, I’ll submit something to help, if others don’t get there first.
Because I wanted to use the pulse counting option, rather than clamp, I redirected the components from the clamp circuit to the pulse circuit – this meant a relocation of the jack socket primarily. This mod requires the creation of suitable holes in the TX case – I used a Dremel to make spaces for the socket and USB connector. The case is pre-drilled for the LED and CT clamp socket.
I loaded up a couple of the sample sketches, which worked and proved my soldering skills weren’t as bad as Id feared.
The TX transmits using an RF12B module – this is supplied, but needs a corresponding device on the receiving Nanode, which I made sure I ordered at the same time as the TX.
With all parts assembled, I loaded up the final TX sketch (Firmware) and EmonBase sketch into the Nanode.
A couple of minor (and expected) changes were necessary in both sketches, which resulted in successful communication between both devices. I was happily seeing a message every 10 seconds from the Nanode, saying there were values on CT1 (clamp circuit) and zero value on CT2 (pulse) and a value representing the TX’s battery status. CT1 values were seemingly random though, due to the missing capacitor – installing the replacement caused this to stabilise at zero,
I took the TX to the water meter cupboard about 30m and 2 floors away, and connected up to the pulse output of the water meter, as well as a USB power supply. Turning on the tap, I returned upstairs and was pleased to see values of 1 or 2 pulses appearing on the CT2 count of the serial output of the EmonBase sketch.
EmonCMS and Water Usage
In order to record, graph, and ultimately change, water usage, I set up the emoncms system. I initially installed this on the hosted server I use, but I don’t think I have the appropriate access rights (and/or knowledge) to get this working. Instead, I installed XAMMP on a virtual machine on my local network. After configuring a couple of parameters, invoking the emoncms initial webpage generates a SQL database and login id’s, ready to accept data feeds.
Amending the emonBase sketch to reflect the IP address and database names for the server, I was able to successfully populate the SQL database with values transmitted from the TX.
During my initial testing, I left the default data capture rate of 10 seconds enabled for a couple of days. The graphing facilities of emoncms showed reasonable and expected consumption rates around the time the family took showers, filled the kettle, did washing etc. However, during the night, and other periods when there should be no water usage, I observed random and frequent records of 1-2 litres of usage. These figures were recorded in the SQL database, but not in the Enica monitor that I left connected for comparison.
Co-incidentally, the 10 seconds data capture rate generates many data records, and could soon fill up a small SQL database, and is too granular for overall daily water usage (its quite useful for real-time monitoring though – if you have a monitoring screen near the taps (or shower!?) – it can act as a good reminder to turn off the taps, or take a quick shower……)
So, to get a higher level overview of water usage, I changed the logging interval to 1 minute (and corresponding RF timeout to 90 seconds). Using this configuration, the random and spurious extra pulses have disappeared. I am wondering if more frequent RF transmissions in the TX are generating spikes, which trigger the pulse interrupt – Glyn has suggested scoping this, which I may do in the future to determine the cause.
Now, having got a clean source of data, Im quite comfortable in the information being presented. I can use this to help the family be aware of their water consumption. Of interest straight away, is how much our ‘old style’ toilets use when flushed – even though we have put in an expanded plastic bag to bulk out the cistern, each flush still seems to take about 15 litres – about a third of a 4 minute shower!
Im going to change the default logging interval to 5 minutes and run the TX in parallel with the Enica monitor to assess the long term accuracy.
Also, I want to log to Pachube (and possibly emoncms at the same time), but my programming skills aren’t up to scratch as ive failed to combine the emonbase/nanode/rf12b/pachube example sketches.
I shall acquire another emonTX to act as the pulse counter for Gas monitoring – this will be another hack as my current gas meter has no pulse output. I do have an optical generator from ELV, which is supposed to recognise one of the digits cycling over.
Ive got some kit from CurrentCost and Derek Kennedy’s Home Automation Hub which all need investigating/integrating.
Finally, I want to combine everything into a dashboard similar to the fantastic BWIRED http://www.bwired.nl/