Discrepancy between eMonPi and eMonEVSE

PaulS · 2020-03-13T17:06:30.331Z

I’ve noted that the instantaneous power readings differ between my EVSE and the eMonPi. This is particularly noticable on the Solar Divert app, as if I set it up to have the EVSE power feed as the divert feed, it will colour the EVSE measured draw separately.

What I see is that the amount of power increase measured at the eMonPi is higher than what is measured at the EVSE. So when the EVSE switches on, there’s an increase in power which isn’t account for. It’s of the order of a few percent. I’m wondering if there’s a voltage drop due to long cabling, but there isn’t a voltage feed to compare (or have I missed it?).

Should I expect the two to agree with each other accurately? Is one expected to be more accurate than the other. Can I calibrate the EVSE figures to match the eMonPi?

Robert.Wall · 2020-03-13T17:50:48.698Z

If you have details (cross-sectional area and actual length) of all the cabling between the point where the supply to the EVSE leave your consumer unit and the EVSE itself, then if you know the current, a good estimate of the power lost to the volt drop is possible. If you only know the power, it’s going to be a little less accurate.

Or, if you can find a long test lead, you can measure the volt drop in one conductor (the neutral is the safer) and double it.

pb66 · 2020-03-13T19:51:36.473Z

IIRC the emonevse doesn’t measure voltage so it would use a fixed value (240?) and multiply that by the current to calculate power using a fixed pf (1?).

I think the emonpi is likely to be more accurate but the emonevse’s reporting sccuracy could possibly be improved by multiplying the emonevse/current and emonpi/voltage as the voltage level will be more accurate, but it will be apparent power not real power that is reported, a slight adjustment maybe included for pf if charging isn’t at unity to get closer to the real power value.

PaulS · 2020-03-15T14:54:31.644Z

Robert.Wall:

If you have details (cross-sectional area and actual length) of all the cabling between the point where the supply to the EVSE leave your consumer unit and the EVSE itself, then if you know the current, a good estimate of the power lost to the volt drop is possible.

Yes, It’s 6mm^2 cable running for about 15m at 32A. Looking up a similar cable it’s 3Ω per km, or 45mΩ for this run. 32A * 45mΩ = 1.44V. Not the 10-15V I would need to account for the 400-500W difference I’m seeing.

pb66:

IIRC the emonevse doesn’t measure voltage so it would use a fixed value (240?) and multiply that by the current to calculate power using a fixed pf (1?).

Ah… if that’s true, then that would make a lot of sense, especially if it was using 230V.

Robert.Wall · 2020-03-15T15:25:57.138Z

BS7671 gives 7 mV/A/m for the run (out and back), so 0.007 × 15 × 32 = 3.36 V
That’s still a lot less than your 10 - 15 V.

The emonPi and emonTx both use 230 V if the actual voltage isn’t sensed, despite the UK’s “centre” voltage still being, as far as I know, a nominal 240 V. The “official” UK voltage was changed to 230 V to suit the EU, but the tolerances were widened to accommodate the old UK standard of 240 V + 6% and the European continental standard of 220 V - 10% (as I believe it was).

jeremypoulter · 2020-03-17T09:57:51.654Z

Yeah there is a fixed voltage of 240V and it does not even consider the power factor. Can easily change the voltage to 230V, especially if that matches EmonPi/EmonTx and maybe add some advanced options to allow the voltage to be configured and/or read from an MQTT feed.

glyn.hudson · 2020-03-17T14:56:45.827Z

For higher accuracy EVSE power feed you could multiply the EVSE current by emonPi VRMS in Emoncms input processing.

jeremypoulter:

add some advanced options to allow the voltage to be configured and/or read from an MQTT feed.

Adding the option to specify an MQTT feed for VRMS is a good idea, since most users will already have an emonPi / emonTx already measuring VRMS.

PaulS · 2020-03-17T17:09:30.982Z

glyn.hudson:

For higher accuracy EVSE power feed you could multiply the EVSE current by emonPi VRMS in Emoncms input processing.

I probably give that a go, but having run the numbers I’m not expecting that to be enough. My Vrms seems to get as high as 243V-244V which will get me 100W in the right direction. That still leaves 300W difference.

I can log Amps on the eMonPi as well, right? Maybe I should compare those figures.

BTW The eMonPi is producing figures within 5W of my electricity meter, so I’m pretty sure it’s the EVSE that’s out.

glyn.hudson · 2020-03-19T00:56:42.229Z

PaulS:

I can log Amps on the eMonPi as well, right? Maybe I should compare those figures.

I’m afraid current in amps is not available as a feed from the emonPi. What EV are you charging? In my experience the power factor for an EV is usually pretty good, e.g 0.98 for Nissan LEAF. However, some EV’s e.g Zoe have a worse power factor (I’ve heard 0.75 being measured) which would result in the EVSE reading being less accurate.

PaulS · 2020-04-13T17:09:48.296Z

Been off the board a while, but for reference it’s a BMW i3

glyn.hudson · 2020-06-08T21:10:44.851Z

jeremypoulter:

Yeah there is a fixed voltage of 240V and it does not even consider the power factor. Can easily change the voltage to 230V, especially if that matches EmonPi/EmonTx and maybe add some advanced options to allow the voltage to be configured and/or read from an MQTT feed.

V3.2.0 update now includes the option to specify VRMS from an MQTT feed:

ESP32 beta V3.2.0: Significant update Solar PV Divert

OpenEVSE

I’ve just published a beta WiFi 3.2.0. Firmware release for the ESP32 OpenEVSE/EmonEVSE WiFi module. The update is a significant improvement to the solar PV divert (Eco Mode) function. Once the updated has been tried and tested we hope to back port the update to the ESP8266 WiFi module (currently installed in most OpenEVSE/EmonEVSE units). If you are already running an ESP32 module, you can update to this firmware by downloading the pre-compiled .bin attached to the release via the web interf…