You’re totally spot on with this statement! 
Thanks for the software info, it looks rather impressive. I’ll be in touch once I’ve had a chance to discuss with @TrystanLea.
Hi @overeasy
Not sure if it is permitted to ask this here, but which company in China you use to manufacture the PCB?
A link to a website would be a great help. Just want to keep it as a reference, in case I need it for future project.
Thanks in advance.
Thanks! 
Nice work @overeasy, I’ve added your development with credit to the Labs: Active development topics list.
At long last, all of the major pieces are in place and seem to be working reliably. Here’s what the beast looks like. I’ll get a better picture in daylight tomorrow.
The top board is an AdaFruit “feather” ESP8266. Under that is an AdaFruit feather “data-logger” shield that has the SDcard and a real time clock. Below that are three IoTaWatt 2.1 ADC shields. The visible side has nine inputs., the other has 12 for a total of 21.
On average it samples about 35 inputs per second, so each input gets sampled about 1.5 times per second. Each cycle sampling consists of about 490 voltage and current readings. That’s at 60Hz. At 50Hz the cycle rate would decrease slightly and the samples per cycle would increase.
The top ADC is configured with burden resistors, has channel 0 set for VT input, and is running at 3.3V.
The second ADC has channel 0 set for CT input (though none connected), has no burden resistors so is running voltage type CTs (SCT013-030), and is also running at 3.3V.
The bottom ADC is configured like the second except it is running at 1.2V, so it has a 33mv CT connected and an SCT013-050 CT that is remarkably accurate at low wattage with the 1.2V and 12 bit ADC. The trade-off is that it will overdrive at about 25A.
Each of the ADC boards can be configured independently, and run at either 3.3 or 1.2 volts. Any channel may be used for voltage sensing, but channel 0 on each shield has a select-able attenuation circuit and 5mm jack for a VT. With three shields and three VTs, three-phase should not be a problem.
The SD log has been redesigned to support faster query. It takes about 4 seconds to serve up a 750 data point graph. I’ll get into the pros and cons of this log format later, but the typical emoncms graphs are probably the worst case. With redesign of the graphing apps, it should be able to serve up any number of simultaneous feeds in the same 4 seconds. Pie charts should be instantaneous over any time period.
Support for eMonCMS is solid. It will update in real time, and it will catch up with bulk updates after an internet outage. Because it has a real time clock and lots of SD storage, it can run without internet indefinitely, catching up when connected, or just serving the data locally on local WiFi. There’s no need for MQTT or any intermediary store and forward.
What’s left is some cleanup and burn in. I’ll be deploying a few in other residences over the next couple of weeks. Someone is currently exploring the cost of having some ADC boards built by a fabrication service. I expect the cost will be moderate in small quantities.
Software and hardware updates to Github next week.
The next phase of this project will be to integrate more of the Emon apps and probably develop some new ones.
5 Likes
This looks really great! Would like to order one or three of your feather add-on boards.
I really like it that you can store your data on SD card and upload them if a internet connection is available. I would like integrate this routine in the feather board M0 (I try to use the integrated 12bit ADC), but I’m not so skilled about programming. How is it possible to separate this routine and integrate it at other platforms?
Looking at ways to make them available. Realistically at least a few months away.[quote=“Simsala, post:18, topic:2989”]
(I try to use the integrated 12bit ADC),
[/quote]
I don’t know much about the onboard ESP8266 ADC. The software requires at least two ADC channels to read power (one voltage reference and one current reference), so the ESP alone can’t do it. If some other ADC were used, the ADC sampling is localized and could be adapted.
Good luck.
@overeasy this is looking really nice! I wanted to check that I understand correctly, do you sample each CT channel sequentially, sampling voltage and current 498 times in one 60Hz cycle 16.6 milliseconds, so 996 samples in 16.6 milliseconds or 59,760 Hz?
Why is it 35.1 AC cycles sampled/second rather than 60 AC cycles sampled/second for 60Hz AC? Is the difference due to time to switch to another CT channel?
Correct.
Basically - yes. To get the maximum samples during a cycle, the samples are just stored. No floating point arithmetic, nothing complicated, just grab samples as fast as possible. After the last zero crossing, a few extra samples are taken to accommodate phase correction. Then the samples are processed, which takes about a millisecond. So it’s too late to start another cycle and the next crossing doesn’t come around for 6 or 7 milliseconds. That’s when the device does everything else. Checks the WiFi server, writes to the SDcard, sends data to a server like eMonCms. There is a scheduler and the communication and logging is done by discrete services that are scheduled and dispatched during that period.
So each sample event takes a minimum of 1.5 cycles. The limit is therefore 40 cycle samplings per second at 60Hz. It would be 33.3 in a 50Hz world. Still, 1.5 - 2 samples each second per channel (20 max).
Thanks for your answer. Actually I would like to use another microcontroller not the ESP. The Adafruit M0 has the same microcontroller as the arduino zero (SAMD21). Will your software only work on the ESP or could it be easily adapted to other microcontroller? Especially the SD-card logging and upload service?
easily… no.
1 Like
The latest boards have come back and I think at this point I can say that the hardware portion is viable. This “shield” design provides a solid platform and now my attention will move to improving the software, particularly the output side to better interface with the existing services and tools and probably extend the local WiFi interface to support more graphic tools.
The basic IoTaWatt device looks like this:
On top is the Adafruit ESP8266 feather Huzzah. In the middle is one IoTaWatt ADC shield, and on the bottom is the Adafruit datalogger shield with a real time clock and a 16GB SDcard. The shield has seven channels, typically used as one voltage and six current, so you could monitor six circuits with this basic setup.
Add another shield and you get this:
Seven more channels. Any channel can be configured as either a voltage or current channel, but practically speaking, the first channel on each shield has inputs for both voltage (5.5mm barrel) or current (stereo jack), and related circuitry. So now 14 channels, 1 or 2 voltage and 13 or 12 current.
At the risk of revealing my agedness, here’s what I call the Dagwood Sandwich:
Here the third board is populated with screw terminals for the CTs instead of stereo jacks. Personally, I like the jacks, but for most CTs that requires soldering on a male jack or using these:
Finally, here are the components laid out individually:
The three position header on the back is a jumper to select address (0,1,2 = chan 0-6, 7-13, 14-20). The switch selects 3.3v or 1.2v ADC range.
That’s about all there is to it. Oh, and installation/use documentation is in the works.
2 Likes
A lot of the web-interface portions are ESP specific. However the metering and calculations should be adaptable to other MCU’s. I have done this with my i2c based version.
Jon would no doubt say it looks “A-OK.” 
Ol’ Bumstead built a mean sandwich, eh? 
All kidding aside, it looks great!
That’s interesting. I’ll stand by my “easily… no” reply. For basic sampling, the eMonTX stuff is pretty much the same calculations - without the gather then process approach.
Is there a post describing your efforts? I can’t imagine that i2c ADCs would be very fast, but then again I’ve pretty much had my head down on this and haven’t taken a really good look at the landscape. No matter how you slice it, you need SPI for an SDcard. I’d be curious what MCU you are using. The ESP is so cheap and capable, I haven’t really taken the time to evaluate alternatives. That said, I have my eye on the ESP32 for the next generation.
Looking Great!
Have you thought about taking this to the next level by parsing the signals with energy disaggregation algorithms and identifying individual devices in the household? There’s at least one product on the market that is doing this now but it only uses two CT sensors so it has to disaggregate an entire house. I would think it would be a lot easier and much more accurate if you were to disaggregate individual breakers. For devices that are always on such as a switch or router, an esp8266 based outlet or individual esp8266 with 1 CT to monitor at the device might be an idea.
The disaggregation concept could also be applied to household water flow. I’ve seen clamp-on ultrasonic flow devices that could be used. In line devices could be used as well provided they can measure low flow accurately. Should be easier to do too, since the number of devices that use water is tiny compared to electrical devices.
Just throwing out some ideas. My brain is full of these ideas, but I just don’t have the software and circuit knowledge to turn them into a product myself.
Not really. I don’t know what’s under the hood of the Sense monitor, but they talk about crazy high sample rates. Judging by the resumes of the developers, I’m guessing they are doing some fancy continuous signal processing to identify the various appliance profiles. Their background is speech recognition so I think it’s like Siri picking out your words from the background noise. Takes a lot more processing power and better sampling than IotaWatt has.
I guess it’s cool to have your phone tell you when your laundry is done or if you left some lights on. Not sure if it can break down usage (as opposed to use) as well as discrete circuit monitoring.
All that said, they will probably be able to do some other worthwhile things like identify problems with devices, possibly even diagnose.
I don’t think the technology is applicable to residential water usage in any meaningful way.
You may be pleasantly surprised at what you can do with visual inspection of your per-breaker power graphs once you get to know them a bit. I’ve had per-breaker monitoring for a while and have become pretty good at recognising the relevant patterns.
One of my breakers (GPOs2) is basically all the outdoor power outlets including the laundry in the basement. It’s very easy to glance at the graph for it before I decide whether to head down to the basement and hang the washing out. It’s got a clear wash cycle followed by 4 rinse/spin cycles, the last one the biggie:
That low-level square wave ticking away in the background is the circulation pump on the solar thermal hotwater heater.
Of course, it’s a much harder problem to automate all that. Rather than have it email me to tell me the laundry is done, I just check the graphs with the human eye/brain. I have automated some fault-detection on other circuits though. For example, I do generate automated emails when the pool pump is rotor-locked, or cavitating due to water starvation.