Thanks for this site and all the hard work and contributions. I stumbled on it (well google) while looking for alternatives to the commercial TED and Brultech products.
Now my question. I noticed that your solution uses Arduino to bit bang/sample current and voltage, etc and then one typically feeds it to a linux box like a PiRaspberry to log (store) the data, serve the data, or otherwise analyze, present...
Good plan -- BUT - how about using one off-the-shelf little computer to do both?
The pcDuino seems a good bet. My question is whether I'll be able to poll the ADCs reliably and consistently enough. The preferred software for pcDuino is Linux - which I'm very familiar with - except in the domain of using it for real-time monitoring. I would hope that since this will be a dedicated little box that will not usually be running heavy graphics - and won't be servicing interrupts except as needed to collect data and serve that data - I could get "away" with a simple polling program that sleeps between polls and periodically reads a real-time clock to synchronize itself.
Thoughts? Comments? Already BTDoneThat?
Re: pcDuino / arduino Due - 32 bit processors for energy monitoring and control
"My question is whether I'll be able to poll the ADCs reliably and consistently enough." That's one good question, and it's pretty important that all the samples are regularly spaced in time, else the rms calculations will be wrong. The other question is how often can you sample all the inputs and convert the values to make them available to a program? Bear in mind there are only 4 inputs that are usable - the 6-bit channels don't really cut it when we struggle for resolution with the 10-bit Arduino inputs. We manage about 50 sample pairs per mains cycle with the Atmel 328P, which is enough to give good accuracy with all reasonably distorted/chopped current waveforms. Unless you can do at least 30, accuracy will suffer.
Re: pcDuino / arduino Due - 32 bit processors for energy monitoring and control
Doing some more "research" via Google, Ebay, and Amazon -- and looking more at your great website -- seems to me like Arduino Due is the way I'll go. boredomProjects.net has already blazed the trail - so hardware-wise I'll just be following his lead. Professionally I work on a project that is hundreds of thousands of lines of C++ code, so comparatively the energy specific Arduino code for the energy meter is a small piece of cake - you guys have figured out a workable, practical way to do the signal processing on the raw sensor data - that's the part of the software that would have been difficult for me alone.
With 12 analogue inputs, each with 12 bits of precision and and a 32bit ARM processor, not to mention all the digital I/O, the Arduino Due might be viewed as "overkill" - but given that a Chinese source on ebay sells if for less than $20US - why not? I haven't used 16 bit micros since the early days of the IBM PC (1980s) - so why go backwards when the ARM board is so cheap?
Looks like I can just push data from the Arduino to a local linux host (e.g. Rasp.Pi) via a USB cable - and from there on I know how or can find/adapt software to save, serve and/or plot the data, etc, etc.
Regarding serial output, I suggest you improve the OpenEnergyMonitor software so each EnergyMonitor object has a name or identity string field... So the serialprint() method can output that along with the readings. Should also output a timestamp with each round of polling the objects, or perhaps with each object reading Thus each output record is self identifying and a slightly smarter data logger and/or plotter can make sense of the data - and immediately display it in a meaningful way. Even better, output JSON or similar semi-standard format, so it's super-easy to parse the data stream.
(If you don't have true time of day clock onboard your Arduino collector, you can still tick off relative seconds and let the next stage collector adjust the relative time to an absolute UTC time)
In other words, come up with a standard way to tag the data with names and timestamps right at the Arduino collector - and then there less need to customize/configure the data collection software to do something sensible with the data.
Also, after you add sensors in the future, you can still look back and re-plot the old and new data together. For example, this year's HVAC energy consumption against last year's - even though you added some extra sensors this year. IOOW - think in terms of self describing, extensible database schemas.