No, wrong. You only have the one current/power/energy channel. This I call a logical channel and the logical channels count from zero, so the first and only one is still LOGICAL CHANNEL ZERO. Logical Channel and Pin no (physical channel) are only related by the order in which you list the physical current channels in the sketch. So it’s totally correct for logical channel 3 to read zero, because you’ve not defined it (nor channels 1, 2 & 4).
Great thank you Robert. I have adjusted the voltage calibration a little. The current is about correct with 2 turns within the CT. (My Avo 8 range is only 10Amps & the needle is off the scale). Now I shall read about phase in the PDF to see if I need to change something or reverse it. Kettle claims to be 220 - 240V, 2520 - 3000W
AC present
V=235.79
Ch 0 I=24.188
W=5559
VA=5703
Wh=60
pf=0.9747
You need a small tweak to the phase calibration. I suggest steps of not more than 0.2 to begin with, and don’t expect it to be correct over the full range of currents and voltages - the phase error inherent in both the voltage transformer and the current transformer changes according to the mains voltage and the current respectively, and there’s nothing you can do about it - except set it when conditions are “typical” (whatever this means).
(The reason for logical channels is the emonTx V3 had current input 4 as a special dedicated high sensitivity one, so anyone using only channels 1 (grid connection) and 4 (P.V) could define just 2 channels and get a much higher scan rate, hence better fidelity, than if it had to scan all 4 channels.)
Bear in mind that your logger must not try to control what emonLibCM does, it needs accept the data when it’s sent, rather than commanding a port (or similar) to take a reading. This is how emonCMS works.
Equally, you’ll be writing the values to and refreshing the LCD display on receipt of the data from emonLibCM (inside the "if (emonLibCM_Ready()) { … } block.
Thank you. That may be a problem. One of the things I wanted to do was log the times of start and stop of power flow, being uninterested when there was no flow. I remember that you said I might use the Emon1 library and I see that has this code
float realPower = emon1.realPower; //extract Real Power into variable
float apparentPower = emon1.apparentPower; //extract Apparent Power into variable
float powerFActor = emon1.powerFactor; //extract Power Factor into Variable
float supplyVoltage = emon1.Vrms; //extract Vrms into Variable
float Irms = emon1.Irms;
I was expecting that I could use something like float Irms = (EmonLibCM_getIrms(ch),3); or lcd.print(EmonLibCM_getIrms(ch),3); I need to mull on all this.
For car charging, I am expecting that the power remains relatively constant - until it steps down when the battery approches full (or over 80%). I imagined querying at, say, minute intervals and logging if there was significant change. Perhaps the Emon1 lib would allow me to interfere with the loop without causing problems.
The original emonLib measures near-instantaneous (sampling period 100-200 ms) on command. You can’t run both the original & CM at the same time.
There’s nothing stopping you from doing something that’s very nearly equivalent using emonLibCM. You can set the reporting period to a small value and only do further processing when you’re interested.
After you’ve got (say) the current (but power might be more meaningful), you then check whether it’s above a certain threshold, and send the value, or just a logical "on’, along with the time to the logger functions. While it remains above the threshold, you remember you’ve sent the ‘on’ state and send nothing more. When it falls below, you send the ‘off’ state and the time - and remember that too so as not to repeat every 20 s or so. If you want more precision for when the transition happened, reduce the reporting interval in emonLibCM. It will happily go down to 1 s. It seemed to work for me down to 0.1 s, doing multiple powers. If you’re happy with the average over the previous minute, set the reporting period to a minute. I’ve not tested above 5 minutes.
You’re not limited to one threshold, you could (say) independently of emonLibCM calculate the average power over a period (probably by energy over an interval divided by the time) and flag deviations from this, which would likely be the best indicator of the car reaching full charge and the charge rate dropping.