I have just finished installing an ESP-WROOM-32 with split core transducers and voltage monitor board at my homestead’s main 200 amp service panel.
I cranked up the processor and lo and behold the only thing currently working is
the webpage displays connecting through my local LAN. The problem is ALL the values are reading a big fat ZERO. Lol…
I know I have a learning curve involved in order to get up to speed on proper calibration techniques and whatnot.
At the moment I am wondering if the code is compatible for the ESP32 WROOM microprocessor? I am working throught the Arduino IDE 2. platform and using the Emonlib.h [1.1.0] library files. Everything compiled just fine; which means nothing as far as whether the code will actually give a result.
Are there any special requirements when working with the ESP32?
The other question is in regard to tutorials or online links that will get me up to speed on understanding EMON and how to properly make calibration adjustments. All of this predicated on figuring out why I have no data on either the voltage or current inputs. So software seems the first suspect.
Any tips or tricks are very welcome,
Mister Ed
I know very little about the ESP32, but I know others have written and asked about it, so I’ve got to suggest you search this forum (the search in the light blue top bar) and maybe the archived forum too (the search in the dark blue top bar) for something like “ESP32 emonLib”. The maybe obvious (or not) point is it’s a different processor, operating at a different speed. This means assumptions built into the sketches you will find here might be sub-optimal, if not wrong. Note: we stopped using emonLib some years ago, we now refer to it as ‘Discrete Sample’ (sometime wrongly spelled as ‘Discreet Sample’). It was superseded by emonLibCM (Continuous Monitoring version) and more recently by emonLibDB (for the Atmel -DB processor range).
I draw your attention to the 'Docs" section here (in the dark blue bar at the top of this page), in particular the Learn sub-section and Electricity Monitoring. This gives you the basic theory and outline sketches, and should also answer your calibration question.
My first thoughts are, have you connected the hardware to the pins you are reading in the software, and are the standing voltage levels from the bias circuit correct, and have they got the right signal voltage superimposed on that bias? The Atmel ATMega 328P which emonLib was designed for expects the d.c. level on all inputs to be 1.65 V (with a 3.3 V supply) and have a 3.3 V maximum peak-peak signal to be measured sitting on it - so the voltage on the pin swings no further than from 0V to 3.3 V. And emonLib expects numbers in the range 0 to 1023 from that voltage range.
I have no idea what you compiled - clearly you can’t compile and run emonLib library on its own, you need something to call its functions and do something useful with the results, and you don’t say what that is - so I can’t help there.
Not really. It certainly won’t have any more work done on it, but it’s relatively simple code, and there are plenty of people here who understand it.
And it should be easy enough to adapt to most processors.
That’s what I didn’t know.
The input pins will almost certainly change, plus, when I look at the ESP32 pin allocations, I think you will have to tell it that you’re using the GPIO pins as analogue inputs. Look at esp32emon.h in that Github link to see what’s needed.
To read a second pair of pins (I presume for accuracy you’ll be using one a.c. voltage and one c.t. on one leg of your supply, and a second a.c. voltage and c.t on the other) you’ll need a second instance of EnergyMonitor, the obvious name for which being emon2. (But you could call them emonA and emonB if you prefer.)
I see in the parts list that it calls for one of these:
1 x ZMPT101B AC Transformer Module 250VAC, 5-30VDC. For most use cases, one voltage meter is enough even if there are more phases.
If it is what I think it is and it has an op-amp and adjustment potentiometer, and it looks as if it is, forget it. From the circuit diagram I have seen for one of these (not necessarily the one you might have bought), and from reports, you will never be able to calibrate it to read real power correctly, because the op.amp and filter circuit introduces a huge phase shift - about 20° for me or about 15° for you, meaning that a purely resistive load will show a power factor of 0.966. You will get far more accurate readings of real power (which is what you are billed for) using a plain 120 to 9V a.c. transformer, and a pair of resistors to drop the voltage to about 1 V rms (at 120 V line-neutral).
Alternatively, you could desolder most of the components on that module and use the ZMPT101B transformer on its own. It is actually a current transformer, and with the multiplier resistors we use in the emonVs in the primary side and a 150 Ω burden (R9 etc) on the secondary, you should get about 0.6 V rms, and that will be plenty for the ADC in the ESP32 (and like the c.t, you calibrate it in software).
I have everything crammed into a small enclosure now that mounts next to the service panel. I would hate to tear it all apart to replace the voltage monitor. Modifying it might be an option.
Your observation on the ZMPT101B is disheartening. The internet can be a source for valuable information and in this case a source for less than optimal guidance. You aren’t going to like my next question because I can tell you are a purist at heart and anything you are personally involved in should be “spot on.” Having said that could I introduce an offset into the real power formula to compensate for the undesired phase shift? Or is it skewed too far to adjust the signal value?
Sorry, but my investigation came as a result of complaints from users who had bought this unit in ignorance (or misguided, as you clearly did) who found they could not calibrate it to read real power accurately.
I’m actually a professionally qualified Chartered Electrical Engineer, from several generations of engineers on both sides of the family, so it’s in the blood I’m afraid.
Of course you can, but the change is too big to compensate directly and you need to rewrite emonLib. I can’t do it for you, because the exact changes needed will depend on the processing speed of your ESP32, and I don’t have one to work on. If you want to try that route, I can tell you what you need to understand, and I can tell you the algorithms you’ll need, but implementing the detail and the testing will be down to you. There’s an outline of the correction emonLib applies and how it does it here: Explanation of the phase correction algorithm — OpenEnergyMonitor 0.0.1 documentation The problem is, this algorithm becomes wildly inaccurate when it extrapolates, rather than interpolates, so you need to store either voltage or current for a number of samples so as to line up exactly the apparent waves after they’ve become artificially shifted because they were sampled at different instants, add the phase shifts inherent in the transformers (equivalent to time shifts) and finally add the phase shift introduced by the filters in the module.
If you want to do this, I’ll still help you as much as I can. Or you can live with the inaccuracy.
" so you need to store either voltage or current for a number of samples so as to line up exactly the apparent waves after they’ve become artificially shifted because they were sampled at different instants, add the phase shifts inherent in the transformers (equivalent to time shifts) and finally add the phase shift introduced by the filters in the module."
I just drowned in your very cold North Sea. This I know from being stationed many decades ago at RAF Mildenhall in East Anglia.
Obviously the research/rewrite effort involved in accomplishing the correction modification to the signal inputs is way way beyond my untrained capabilities. I may end up just using Emon to observe currect/voltage levels and ditch the power factor stuff since it will most likely be considerably erroneous.
I have learned some valuable lessons in this process. I am still going to tinker with Emon so you may see me still making inquiries here.
I sure wish I had some of those pub stouts and bitters right now. haha
I did read your posts from about 5 years ago with user IZ3MAN about the ZMPT and I am left with the conclusion that this project needs an overhaul if I want to expect reliable data.
If I gut the ZMPT module and just use the transformer what resistor array do I need to use on the input and output of the transformer. Is there a link to an existing schematic that would show how I need to arrange the circuitry.
You can only just see it in the photo in the Github link you posted, there’s just a single resistor in the primary circuit. By everyone’s reckoning, this is a dangerous thing to do as you’re relying on a single component that for my money might be rated for your 120 V, almost certainly isn’t good for my 254 V maximum. everyone else uses multiple resistors in series, so that even if one fails to a low value or a short circuit, there’s no immediate danger. We use a ZMPT101B in the emonVs (for use with the emonTx3 and emonPi2) and this is the circuit we use:
It’s designed for any voltage up to 254 V (our statutory maximum), and gives an output good for a 0.333 V rms (1 V peak-peak) input, and as it runs at a much higher current than the module, it gives a much lower phase error.
For you, it would run at approx. 2 mA, so you’d need a 150 Ω resistor for R9 in order to get 150 mV rms (a little under 0.5 V peak - peak). You can adjust the burden resistor value within limits (< 200 Ω) to suit the ADC ranges available to you. I wouldn’t worry about not using the full range of the ADC input - this is far more important for current because the current range is 0 - maximum, whereas the voltage is essentially constant, varying only ±10% from the design value. (You probably have better resolution on the voltage at half the full range than you have with the current on normal loads.)
If you make this up on stripboard or similar, make sure you have adequate clearance between all tracks - there might be 350 V peak between two tracks if you have an open-circuit resistor and it’s connected between two legs or if it is connected line-neutral and the neutral falls off.
I completed the modification that eliminated the op amp and capicitor on the voltage modules and replaced them with the series of three 10k resistors on each input.
I am reading .283 and .288 volts AC on the output of each of the two circuits with a 119.8 volt AC input. This is using the suggested 150 ohm burden resistor.
I am hoping the near 3 tenths of a volt will be a sufficient baseline signal to show the two split-phase voltage levels.
I have never sawn a PC board with a coping saw before but that that is what I did to get the transformers removed from the rest of the board.
I now need to do some testing and calibration because my EMON software output is currently a bunch of zeros.
Those voltages sound reasonable, so the next question is, what does your input circuit look like?
I’m not familiar with the ESP32 processor in total, so don’t expect me to have any deep knowledge of how to set up the software libraries you’re likely to need in addition to emonLib.
What you are looking for is what input voltage range does the ADC input expect, and does your hardware supply a signal that has a “no input” voltage that sits close to the middle of this range, and does the range extend from that centre voltage at least half a volt either side?
If all this looks sensible and correct, bear in mind emonLib is written specifically for the Atmel ATMega 328P, not the ESP32, so there are other libraries and things you must do to read the input voltage and get a number in the software so that emonLib can use it. EmonLib won’t do it unaided. Searching here for ESP32 should find a few threads which might help, like this one which explains the process of setting up the ESP32 and what to look out for reasonably clearly: ESP32 Problem with YHDC SCT-013-000, or there must be other on-line tutorials.
I was under the impression the EmonLib code I downloaded into the Arduino IDE was all that was needed as Emon looks directly at the voltage and current inputs to the ESP32.
I definitely need to do more homework. My baseline DC signal for the current inputs is around 1.6 vDC but the inputs are not varying with current flow. I probably need to get a higher value than just an amp to make sure. Thanks for that link.
No, emonLib looks directly at the voltage and current inputs to the Atmel '328P as used in the emonTx V2. If there’s something clever in or can be added to the Arduino IDE that maps the ESP 32 inputs to look like Arduino Uno inputs, then it may well work directly, but I don’t know if anything like that exists.
All I know about your sketch is what is in post no.3. If that’s all you have, then you need an Arduino Uno or an obsolete emonTx V2 to get readings . Remember, you’re looking at what you have - hardware and software. I only know about what you have from what you’ve written here. I don’t know what if anything you copied/incorporated from that Github link. That alone tells me (reminds me?) that the pin numbers need work to get readings to appear, and the link I gave immediately above mentions gain and range adjustments, which I’d need to research to understand.
Attached is a screenshot of the Voltage Board active input captured on the Arduino IDE Serial Plotter.
Also attached is the screenshot of the image by Dan Pieg (Github) after he adjusted the potentiometer on the unmodified ZMPT101B voltage board. As you can see my modified “Wall” board without the potentiometer/op amp/cap has a waveform every bit as good as the unmodified one!
I can see an obvious problem with your captured wave (top picture): there is no bias offset to lift the ‘no input’ centre of the wave into the centre of the input range of the ADC, so the ‘bottom half’ of the wave is clipped.
The second potential problem, for which you need the mains wave on the same picture/graph, is there will be a massive time difference between the mains and the module output in the lower picture. I can only simulate to module’s output given the published circuit, this is the result for you at 60 Hz:
It is the displacement between the input current (Vreference) and the output which would result in inaccurate power measurement. It is the op.amp and associated components which generate this error.
Have another look at the ‘Learn’ page where you’ll find a fuller explanation of why and how we need the bias voltage. CT Sensors - Interfacing with an Arduino — OpenEnergyMonitor 0.0.1 documentation Yes, this is for a current transformer, but the circuit configuration in the lower diagram (Configuration used in the emonTx4 and the emonPi2) is much closer to that of the emonVs, which is what you are aiming for with your ZMPT101B.
Are you saying this ‘bias offset’ is something I need to properly display the waveform or it is needed as part of the input signaling to allow the value to be interpolated correctly? If it is the latter I have no idea how to approach doing such a thing.
I appreciate the additional link you provided and will study it more closely. I do have all the inputs working after discovering an errant wiring of the audio jack sleeve pin used for the current input.
One thing I wanted to ask you about is in regard to the phase shift value used in :
The 1.732 value that is used by Emon appears to be a set value for the phase shift parameter. Does this value hold true even with my modification of the ZMPT101B voltage board? I know you spoke of unwanted phase shift using the ZMPT with its op amp, cap, and potentiometer.
I feel much better now that all inputs are providing a reading and the calibration process has allowed me to bring them closer to actual input values.
My intention is to move the ESP to its Mains Panel location and reassess the data and do further calibrations with it sensing realtime loads.
I plan on capturing both split-phase voltage waveforms on the Serial Plotter and compare them to one another.
The biggest challenge I have is to do this outside at the panel and observing the screen with bright sunlight is challenging. I suppose I need to make some sort of cardboard cubicle to house the little PC.