Community
OpenEnergyMonitor

Community

Discrepancy between eMonPi and eMonEVSE

Tags: #<Tag:0x00007f6e026fff50> #<Tag:0x00007f6e026ffe60>

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?

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.

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.

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.

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

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).

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.

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

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.

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.

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.

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

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