Natural Gas and More
This is the final installment of George’s energy monitoring article series. He discussed the solar power supply in Part 1 and the utility power data acquisition in Part 2. In Part 3, he wraps up the series by looking at the remaining modules that comprise his home energy monitoring setup, including the sensors, the natural gas monitor and the real-time clock.
Once again, I purchased readily available modules with the functions I needed. For the temperature and relative humidity (RH) sensing, I selected an Adafruit Si7021, ID 3251 break-out board based on the Si7006-A20 chip from Silicon Labs. The Si7006-A20 is a monolithic humidity sensor integrating humidity and temperature sensor elements. The humidity sensor relies on the change of electrical resistance of a conductive K-polymer dielectric material. Resistivity-based humidity sensors are affected by the temperature and, therefore, a temperature sensor is included in the package. This is an added benefit of the Si7006-A20, which you can use as a humidity as well as a temperature sensor. The Si7006-A20 is a CMOS IC and its block diagram is illustrated in Figure 1.
Because the Si7006-A20’s is a CMOS IC, its standby power consumption is quite low—typically 0.06 μA to 0.6 μA depending on its setup. In the course of temperature and RH conversion the current draw rises up to 90 μA to 180 μA, depending on the data being converted. Conversion time is approximately 4.5 ms. The Si7006-A20 sensor module can be used through the temperature range of -40ºC to +125ºC (-40ºF to +257ºF).
Based on my tests using telephone quad wire, the Si7021’s I2C interface works well up to about 1 m (around 40”) in length. This is sufficient for my required 60 cm (around 24”) wire run. For a longer run you will need to use a bus extender/booster such as the Texas Instruments (TI) P82B715 or rethink the interface completely. P82B715 draws 60 mA from a 5 V supply, increasing significantly the demands on your solar power supply.
Data Logging
For current time, date and data logging I used the Arduino Data Logger Shield, available from Adafruit Industries, product ID 1141 (Figure 2). Similar shields can be obtained from other sources, such as the WIG-12772 Logomatic V2-Serial SD Datalogger from SparkFun Electronics, Universal Solder and others. The logged data is stored on a regular SD card.
An integral part of the logger shield, talking with the microcontroller via I2C bus, is a Real Time Clock (RTC). When its backup battery is inserted and the unit first powered-up the RTC gets synchronized with the Internet clock. The Data Logger library does not provide for the standard and daylight saving time changes, but I prefer to date-stamp the log at standard time anyway. Removal of the battery and a temporary power-down causes the clock to stop and reset upon reinsertion of the battery and its subsequent power-up.
— ADVERTISMENT—
—Advertise Here—
In addition to being the source of the current date and time, the RTC generates 1 second hardware interrupts on its SQW/OUT pin. The pin needs a 10 kΩ pull-up resistor as the Arduino’s internal pull-up seems too large for reliable pin toggling.
The interrupt drives the execution of all the input and output functions. This is when average values are calculated and, if the LCD is enabled, displayed. Once every hour on the hour, a comprehensive data package is written to the SD log. Then, every once in a while, I import the log into an Excel spread sheet for graphical analysis.
The LCD display backlighting draws a fair bit of power, so to keep the power consumption low, I enable the display manually by depressing the appropriate push button. It then cycles through values of the outside temperature, relative humidity, current flow of each phase, natural gas consumption and the current time and date, displaying each for five seconds. The display runs as long as the push button continues to be depressed. The different variables are shown with different background color schemes. This is not a necessary design requirement, but my LCD module does have this capability, so why not use it?
Gas usage monitoring
For a realistic view of my household energy consumption, I also wanted to monitor my natural gas usage. We have a gas furnace, a gas water heater, a gas fireplace, a gas clothes dryer and a gas cooking stove top. Measuring the gas flow, however, proved to be a challenge. I haven’t found a reasonably priced small gas flow gauge with an electrical output. Worse, all such devices—assuming they can be obtained—would require installation into the gas line by a properly trained and licensed technician. And that entails a large cost. Fortunately, an indirect approach by monitoring secondary electrical signals as shown in Figure 3, became a viable solution.
Aside from my stove top, my natural gas appliances all use electrical signals for their operation. The water heater has a fan installed in its exhaust, running whenever the heater should be on, or else the safety logic prevents it from being ignited. I attached a bi-directional opto coupler, U1, parallel to the 120 VAC motor terminals. When the fan runs, an active low signal pulls down one Arduino input with its internal pull-up enabled. For electrical safety, the opto coupler is located close to the motor and the interface to the monitor is low voltage.
In one of my previous projects, I monitored the operation of a gas-fired clothes dryer by installing a current transformer on its 120 VAC power line to the motor. The current transformer output is processed by another embedded controller, but there is a 5 VDC output signal available when the dryer is running. The U2 opto coupler is a Darlington unipolar device, which also provides an active low signal to the Arduino.
The furnace and the fireplace are controlled by 24 VAC thermostats. The two bi-directional opto couplers U3 and U4 generate the active low interface signal for the Arduino when those appliances run.
Gas appliances state their gas consumption on their name plates, but it is confusing—at least to me. The gas flow seems to depend on the altitude, temperature and perhaps some other influences that I found rather incomprehensible. The point is that I need relative values because they affect each other and are affected by the time and weather. The gas supplier takes care of accurate, absolute consumption measurement. So, I first calibrated the gas flow by running each appliance for 30 minutes and recording the readings in cubic meters (m3). Then I normalized the readings to obtain the trends and ratios.
I haven’t found a solution to establishing the stove top consumption. I tried several ideas but none of them worked to my satisfaction. But I’ll continue looking. For the moment, I compared our monthly gas usage recorded by the monitor with the consumption on the gas company’s invoice. I found that the month-to-month gas usage attributed to the stove top remains fairly constant through the year, and, more importantly, it is insignificant when compared with the overall gas usage. Given that my interest lies in normalized rather than accurate values, the stove top consumption may be safely ignored, for the time being. So that’s it for my efforts to monitor (and hopefully to reduce) my energy consumption. Am I a hog? Or can I reduce my needs without some drastic or impractical measures? I don’t know. It’s too soon to tell.
— ADVERTISMENT—
—Advertise Here—
A Last Minute Update
The RTC proved to be a disappointment. I used an older logger shield with a DSL1307 RTC. It was gaining some 4 minutes every week. That’s obviously an unacceptable performance because it would have required regular time adjustments every few months. Hopeful that another RTC would be better, I purchased another logger with a purportedly better RTC, the NXP Semiconductor PCF8563. This one, unfortunately, is running too slow.
To fix the problem I have several options to consider which, let me emphasize, preclude any regular time adjustment. To begin with, there are RTCs claiming better accuracy, but that would entail purchasing another piece of hardware—something I have tried to avoid as one of the project’s goals. I might be able to trim the RTC oscillator, by hardware or software.
But there’s another relatively straight-forward and inherently accurate solution. Some time back I built a WWVB repeater based on GPS and described in one of my past articles [6]. The date and time data are broadcast within my home by an XBee transceiver. Because I have a spare XBee transceiver, I can modify the monitor architecture and use this interface in place of the data logger shield. The total power draw is not likely to increase appreciably, if at all.
I need to do some analyses and design reviews before making a decision which way to go. But that is a topic for a future report once the decision has been made and the changes implemented.
For detailed article references and additional resources go to:
www.circuitcellar.com/article-materials
RESOURCES
Adafruit | www.adafruit.com
Microchip Technology | www.microchip.com
NXP Semiconductor | www.nxp.com
Texas Instruments | www.ti.com
Silicon Labs | www.silabs.com
Sparkfun | www.sparkfun.com
Universal-Solder | www.universal-solder.ca
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • AUGUST 2019 #349 – Get a PDF of the Issue
Sponsor this Article
George Novacek was a retired president of an aerospace company. He was a professional engineer with degrees in Automation and Cybernetics. George’s dissertation project was a design of a portable ECG (electrocardiograph) with wireless interface. George has contributed articles to Circuit Cellar since 1999, penning over 120 articles over the years. George passed away in January 2019. But we are grateful to be able to share with you several articles he left with us to be published.
