With the ever rising cost of electricy I became interested in knowing what the money is being spent on, is it that computer running 24x7? Is it the electric oven? Maybe the fridge freezer? Some of these can be measured at one moment to give an accurate long term average, others will always vary from day to day, so although they could all be estimated it is better to get the true figure of power consumption over the medium term.
Which is where this little program steps in. The Elster A100C, and probably many others - though not necessarily in the same format, continuously outputs its status using invisable infrared pulses. Specifically, every second it outputs 110 bytes containing, amongst other things, the total amount of energy consumed in WattHours. This is 1000 times more resolution than displayed on the lcd - it is WattHours not just KiloWattHours.
The output of the gas meter is much more crude, a hidden magnet is embedded in the least significant digit. No idea how common this is, but given the limitations of having no electrical power, this signal is probably as good as it gets. A reed switch can detect the presence of this magnet, in my case closing the contacts when the digit reads 4.5 to 7. Timing how long it takes to make a full revolution gives an average gas consumption over that duration. As this is the thousandths digit, a full revolution means one hundreth of a unit (1 cubic meter) has been used. Putting all this together and using my latest bill, that means an open to close transition of the read switch costs 0.323 pence.
This program can be compiled with the line:
gcc -Wall rdmeters.c -o rdmeters
and then run with the line:
./rdmeters /dev/ttyUSB1 "Elster A100C" 2> /dev/null
where the /dev/ttyUSB1 is the second usb-serial dongle. The string "Elster A100C" helps rdmeters locate a known position in the data stream, from this it can work out the beginning and the end of each data frame.
Get it wrong and rdmeters will be unable to find the frame, and will instead print out raw hex of the first 256 bytes of irda stream and then quit, leaving you to find the make/model name in the hex and use it as the correct option to rdmeters.
It is assumed that the make and model fields are always in the same part of the data frame relative to the checksum and WHours counters. You will know that assumption is wrong if the unit counter don't match what you see on your meter.
The 2> /dev/null throws away all mentions of checksum failure, which is probably what you want when it working. I see maybe 1 checksum failure per minute, with the laptop in a cupboard with the plastic near the ir sensor leaning against the eletricity meter by the ir sender.
For the gas meter reader to work, the serial port must support the TIOCMGET ioctl to directly read the status of the CTS pin. The statserial utility can be used to test for this, as it uses the same access method. This was tested with an on-board serial port and an FDTI based usb-serial dongle (watch out for the FDTI bug in 2.6.28.x).
See rdmeter for a description.
See rdmeter for a description.
While building this circuit, the voltages of the 9 pins was measured on both a real onboard serial port and a USB to serial converter. They are provided here for reference. The serial port was active but not sending or receiving any data.
Pin | Signal | Onboard | USB |
1 | CD | 0V | 0V |
2 | RX | ||
3 | TX | -12V | -8.16V |
4 | DTR | 12V | 8.8V |
5 | GND | ||
6 | DSR | 0V | 0V |
7 | RTS | 12V | 8.8V |
8 | CTS | 0V | 0V |
9 | RI | 0V | 0V |
Thanks to Iain for bits of information and helpful links to the gas meter.