Open Energy Monitor Port

Social Project Share
84

@kennethlimcp, using a 100A/50ma current clamp will only give you a range of 0.5 to 4ma when measuring 1-8A. With these types of clamps, you can put a low-value resistor in parallel with the output to give you a voltage but you will need to use a high input impedance op-amp to amplify the voltage in order to measure it. Seeedstudio has a good tutorial here but it does not deal with signal amplification since they assume you are measuring the full current range.

85

@kennethlimcp your current clamp is the same model that the openenergy monitoring project uses as standard so I doubt whether you will have any problems with it.
Open Energy Monitor Introduction to Current Clamps

If you put your 4ma through a 330 ohm resistor you will get Ā±1.3v output which nicely fills most of the range of the Sparkā€™s ADC. Iā€™d be surprised if you need to buffer it with an op amp because the Spark ADC has an input impedance of around 220kohm but @peekay123 pekay knows what he is talking about so I bow to his superior knowledge.

Since the current is rather low you may get a noisy signal so it is worth putting quite a large capacitor (Iā€™m guessing but start with say 20uF electrolytic.) between the analog pin and ground and also make sure that the current clamp and leads canā€™t flap around too much. Take a look at the open energy monitor projectā€™s advice on current clamps and particularly avoiding a large back emf if you go open circuit while plugged in to the ADC. I think it is worth trying this low tech. solution before pursuing pekay123ā€™s gold standard.

If your current lead is flexible enough and has enough play in it, you could loop the lead several times through the current clamp. The effective current is multiplied by the number of times the lead goes through the clamp so if you were able to fit 10 loops through the clamp youā€™d get up to 40ma and only need a 33ohm resistor.

1 Like
86

@kennethlimcp, @phec is right to try the low tech approach first. In my experience with a 50A clamp measuring sub 1A currents, noise and signal amplitude were a big issue. The input impedance of the ADC is also affected by the sampling rate so try his excellent suggestions and go from there. I ended up using a hall-effect sensor (ACS family of sensors) since I could put it ā€œin-circuitā€ as part of the design. :smile:

1 Like
87

@peekay123 and @kennethlimcp, Iā€™m pretty sure that the simple solution will work just fine. Iā€™ve just taken a look at todayā€™s power measurements. I measure both with a current clamp and by counting the LED flashes that the meter produces once per kW second. Even at powers under 1 kW (~4a) they are in reasonable agreement but individual measurements are quite noisy. This is using a current clamp with built in ballast resistor giving 1v per 60a.


The graphs show some of my power history measured by flashes vs power measured by current clamp - the first section is at night when there are just computers and refrigerators on then there is a 3kW burst of immersion heater - the second section is early afternoon and in this graph the red line shows PV generation and the green and blue lines show me exporting some power. The flash measurement is discretised as I count the number of flashes between polls (around 15 secs) and the current clamp value is an instantaneous value measured at the poll time.

Another source of error is the very strange current waveform at low powers due to the large number of switch mode power supplies I have.

This shows that the current I draw is something far removed from a sine wave. In this sample the current clamp gives a value of 650w while the flash count gives 720w.

1 Like
88

I would like to use the electric port RJ11 that is commenly found in energy meters for measurement through sparkcore cloud. Can anyone help me to transmit the serial data from RJ11 port through the Tx, Rx pins of sparkcore. tha data includes KW,KVAR,I,V,pf,freq, etcā€¦ how can I measure these through sparkcore thruoug a web interface. Iā€™m new to sparkcoreā€¦

89

Hey great port of the energy monitor for spark coreā€¦One request though-- Could you merge the recent changes in the master open enegy monitor code to this branch tooā€¦I donā€™t know how and i might mess up the codeā€¦ They have made a lot of improvements such as using a low pass filter instead of high pass filter etcā€¦
Thanks in advance

90

@jiyojolly, thank you for pointing out the new version of the emonlib. Iā€™ve had a quick look at the latest Open Energy monitor code. It does look neater. Iā€™ll update the SparkEmonLib to incorporate the better filter. The dodgiest bit of the code/hardware is the correction for the time difference between V and I measurements and the hardware dependent phase shift introduced by the sensors. That doesnā€™t seem to have changed. Having plotted out the voltage and current waveforms it is clear that with my hardware the phase shift varies with power so I donā€™t see that there is much to be gained by further refining the phase correction.That is why I use the meter flashes to measure power most of the time - after all they represent what the power company sees - and use the current and voltage sensors derived power only for low powers and to determine whether I am importing or exporting.
Iboredman has forked the emon software for use with an Arduino Due (ie a faster ARM based system more like the Spark) and has an alternative solution for the phase correction, appropriate to the higher ARM sampling speed. Iā€™m not sure how much of this is incorporated into the latest version of the main Git repository.

Donā€™t hold your breath for the code update - unfortunately I wonā€™t have any free time in the next couple of weeks, but should get started towards the end of the month. I donā€™t understand Git so the update will be another Git Gist rather than a patch.
Iā€™ll test the software on a Spark with a voltage sensor before posting but not on my full working system because I donā€™t want to risk breaking it with the large number of Spark updates that have been introduced since I programmed the system last August.

Spark have produced a huge number of improvements in the interface and with the forthcoming data visualisation toolkit Iā€™m tempted to stick with what Iā€™ve got until I have a Photon and then redesign the whole system - probably replacing the 20 x 4 character display with a Raspberry Pi touch screen and getting more interactive with my phone.

2 Likes
91

This project looks really cool. Nice work.

I wrote up a similar project I did a while ago: https://unop.uk/dev/raspberry-pi-electricity-monitor/

Iā€™ve considered doing some direct measurements of the meters with my core but there is no power source in the meter cupboard (ironic I know).

92

@JSingleton - Brilliant presentation! I also had a problem with local power near the meters and before I bought a Spark I ran a long length of 4 core telephone cable from the meters to an Arduino. The digital ports connected to 2 photoresistors (for generation and general power) and a reed switch (for gas) the 4th core was ground. It was relatively easy to run the telephone cable unobtrusively from the meters to the Arduino. The Arduino converted meter flashes to power values, correlated the generation and general meter readings to infer whether I was importing or exporting and displayed the data. The Arduino serial port shared this information with the Pi which stored the data and has the interface to switch on and off appliances depending on the level of power generation. I had no trouble getting a clean signal with 20 meters of telephone cable though the reed switch needs careful debouncing because you can guarantee that every few days the meter will stop turning when the reed switch is on the point of making/breaking.

While this solution doesnā€™t at first glance seem to fit well with the capabilities of a Spark, using a Spark instead of an Arduino (or the PIO pins of a Pi) does offer the advantage that you could site the Spark at the nearest power socket to the meter cupboard rather than where you want the Pi and the display.

2 Likes
93

@phec Thanks!

The resolution isnā€™t too bad even with the 7 second sample period. You can still see the inrush current of the compressor on the fridge (although not on every cycle). There is so much more that could be done with sub-second sampling but thatā€™s a lot of data to store so it would need some pre-processing. Maybe just a low-pass filter, rolling average or integration.

If you havenā€™t checked out the interactive graphs then do. You can click and drag to zoom in on either axis. http://jpsingleton.github.io/rawExample.html and http://jpsingleton.github.io/lowPassExample.html

These all use http://dygraphs.com/ which is awesome. I use it on https://shutdownscanner.com/home/dashboard too.

I did have a graph of overlayed electricity, gas, indoor temperature and outdoor temperature which was pretty interesting but I canā€™t find it right now. It shows the thermal leakage of the property and you can even work out what sort of thermostat is in use (PID or cheap switch with simple hysteresis).

The problem with measuring pulses is you donā€™t get consistent precision. I used to have a gas meter with an RJ11 pulse port on and measuring low flow rate was tricky as you donā€™t know what happened until the next pulse. It works OK for high usage when it pulses pretty quickly but when nothing is in use it can go hours without a pulse. De-bouncing is an issue but you can just use a Schmitt trigger or software.

Iā€™d like to try and read the infra-red interface on the electricity meter as that should be more accurate and consistent. Itā€™s also what you get billed for so there shouldnā€™t be any discrepancy like if you miss a pulse or use a badly calibrated current clamp. Here are some links on this:

This process for separating out individual appliances also looks interesting: https://en.wikipedia.org/wiki/Nonintrusive_load_monitoring

1 Like
94

Here is my port of the O.E.M project for Spark.
It includes the tinker code so you can feed inputs (with a jumper) with fake data.

95

@officeboy, that is great. The git repository that you refer to has a Spark compatible version of emonlib and I see that you have updated it to keep it in line with the master emon branch. Consequently my gist is now redundant. @jiyojolly please note officeboy and Cinezasterā€™s excellent contribution.

1 Like
96

@phec I thought you did a nice job on your library and a really nice job documenting it, but I just couldnā€™t bring myself to use it due to the name.

97

I take your point. All my Spark libraries started with S which made it easy to find them. When I did the emon one I thought oops - but was too pedantic to change the naming scheme.

1 Like
98

Thanksā€¦Hey I forked the master code from github and made changes to it to adapt to sparkcore myselfā€¦Finally got it workingā€¦Saw the @officeboy and Cinezaster github code after I went through hell making changesā€¦ Thanks for your input!!

99

@jiyojolly Iā€™m glad you got it working.Do you get reliable power factors with the newer filter?

100

Yeahā€¦Tested with a incandescent bulb(40W) and got .99ā€¦Had to tweak the PHASECAL to an extentā€¦But got it workingā€¦i also tested with an Fan load(inductive load) and got .67ā€¦Seems right I guessā€¦

2 Likes
101

Just wondering if anyone has looked at modifying the library for use with the Photon?

1 Like
102

Yes. Iā€™ve done it. I had a struggle because there is a bug in the Photon compiler that I didnā€™t spot for a while - sprinf() doesnā€™t work with floats. Particle.io have a work around but I didnā€™t find it until Iā€™d pinned down the problem.

  1. Hardware changes: the Photon is almost pin compatible with the Core. To use the existing socket without remaking the stripboard, two pairs of pins need to be connected
    D0 canā€™t be used as an interrupt so connect pins D0 and D3
    Photon doesnā€™t have a 3v3* pin but it is OK to short 3v3 to Vbatt

  2. Software changes:
    Redefine gasPin to be D3
    Use this very unwieldy line to put float data into the UDP buffer
    (If you have v 0.4.5 of the firmware then sprintf works again so you donā€™t need this work around - thank you Particle People)

    sprintf(UDPoutData, "%s %s %s %s %s %s %s %s %4d \n", \
          String(timeSinceLastRequest/1000.0,2).c_str(), String(emon1.Vrms,2).c_str(),String( emon1.Irms,2).c_str(),  \
          String(emon1.realPower/1000.0,2).c_str(), String(emon1.powerFactor,2).c_str(), String(powerGas,2).c_str(), \
          String(powerGen,2).c_str(), String(powerExp,2).c_str(),emon1.crossCount);

Everything then works as a straight replacement.
Of course the Photon can handle UDP packets of 1k without running out of memory so the waveform samples can be longer and with greater resolution.

Fot both Core and Photon versions of the code Iā€™ve made a minor change to the boredman/cinezaster version that @officeboy and @jiyojolly pointed out (see above) of emonlib that allows me to access the I and V waveforms.
Iā€™ve made all doubles float to save memory. Add the following two lines to the public section of the EnergyMonitor class definition in the library header file:

    uint8_t Vwaveform[128];
    uint8_t Iwaveform[128];

Set these two new arrays in the main measurement loop in the code part of the library:

    //-----------------------------------------------------------------------------
    // B) Apply digital low pass filters to extract the 2.5 V or 1.65 V dc offset,
    //     then subtract this - signal is now centred on 0 counts.
    //-----------------------------------------------------------------------------
    offsetV = offsetV + ((sampleV-offsetV)/1024);
    filteredV = sampleV - offsetV;
    offsetI = offsetI + ((sampleI-offsetI)/1024);
    filteredI = sampleI - offsetI;
    Vwaveform[numberOfSamples%128]=uint8_t((filteredV+2048)/16);//Particle save waveform
    Iwaveform[numberOfSamples%128]=uint8_t((filteredI+1024)/8); //Particle save waveform

The Photon is a good deal faster than the Core so you may need to tighten up the software that does the polling.
I had a ā€œif time%15 < 0.5secs do pollā€ which now needs to be ā€œif time%15 < 0.1 secs do pollā€ to avoid double calls.

4 Likes
103

What a great project! I just recently bought an emon_tx3 and the pre-loaded SD card for the emonPi (already had the Pi hardware). I havenā€™t had too much time to tinker with this yet, but the idea of expanding the system using Photon boards is really appealing to me. Has anyone found a nice looking box that can house the Spark/Photon plus some input jacks for the sensors? Would be nice to have something nicely packaged like the emon_tx3. Iā€™d buy it in a heartbeat if there was a turnkey solution available :slight_smile:
Cheers.