1

Having messed around a lot with the system over the last few days I let it ‘settle’ for 24 hours and then compared the measured values with the meter readings. I have dual-tariff that is separately metered (the old fashioned way) and Peak electricity reads 131% of the metered value while Off-Peak reads 92% of the metered value. I’ve compared both P derived and E derived kWh measurements - they’re identical.
Both Peak (CT1) and Off-Peak (CT2) are using 100A sensors and the calibration looks like the default to me. I listed out the firmware settings and they are:

emonTx V4 CM Continuous Monitoring V1.5.4
OpenEnergyMonitor.org
Loaded EEPROM config
Settings:
Band 433 MHz, Group 210, Node 17, 7 dBm
Calibration:
vCal = 807.86
assumedV = 240.00
i1Cal = 300.30
i1Lead = 3.20
i2Cal = 300.30
i2Lead = 3.20
i3Cal = 150.15
i3Lead = 3.20
i4Cal = 60.06
i4Lead = 3.20
i5Cal = 60.06
i5Lead = 3.20
i6Cal = 60.06
i6Lead = 3.20
datalog = 9.80
pulses = 1
pulse period = 100
RF off
temp_enable = 1
JSON Format Off
Reference voltage calibration: 1.0304
AC present - Real Power calc enabled
MSG:1,Vrms:244.95,P1:236,P2:1,P3:0,P4:0,P5:0,P6:2,E1:36992,E2:76480,E3:19,E4:6,E5:0,E6:163,T1:23.25,T2:21.75,pulse:0

I can live with this and will put correction factors into the feeds to compensate, but they are higher than I’d have imagined and are in opposite directions, which seems strange. Does this point to an issue with the firmware?

2

Hello @NickT did you record Vrms for that test period by any chance? Could you share a screenshot of the Vrms, CT1 power and CT2 power values for the 24 hour period?

3

Here you go:

Screenshot 2023-01-03 at 12.10.55
Screenshot 2023-01-03 at 12.10.551920×1884 214 KB

4

Thanks @NickT looks like the voltage sensor is being detected and used correctly and the calibration values are correct, which rules out the usual reason for incorrect readings. 131% and 92% is way outside of the error range that I would expect and I wouldn’t want to adjust the calibration to compensate without working out why these are deviating by that amount.

Are the 100A CT sensors under any sideways force that might effect the contact of the cores?

What is the make, model and age of your billing meter?

5

Moved to new topic.

6

Sideways force? Yes, not a lot but some. There’s not a great deal of space in the DB. CT1 is resting against the left side with the cable pushing against it, and CT2 is loosely placed on the right, around the tail, but again not centred on it, one side being up against the sensor, the other having around a 3mm gap. I didn’t think that the position of the cable within the sensor was that critical, theoretically it’s not supposed to be but I’ve no practical experience with these.

Meter values Midnight 5
Meter values Midnight 51920×1440 262 KB

And the meter was installed in the late 90’s when the flat was built, so is around 25years old, here’s a picture:

Meter values Midnight 8
Meter values Midnight 81920×1440 128 KB

FINALLY…
I’ve just measured the consumption since this mornings report, and the agreement is much better! P1_kWh and E1_kWh are reading 102% of the meter value (4.1kWh on the meter, 4.2kWh on both measurements), which is much better. I obviously can’t check the Off-Peak consumption until tomorrow, but perhaps I should leave it for a while and check again.

Just like the delay() issue with the firmware earlier this may be what we call in the software trade a Heisenbug - one that disappears when you look at it!

1 Like
7

I’m moving monitoring from a emonTx3 to the new EmonTx4. The emonTx4 is at the current 1.5.4 firmware level. Calibrations are CT1-2 at 50A, CT3-5 at 100A and CT6 at 20A, set via the serial utility and saved to EEPROM. (@TrystanLea this firmware upgrade had temperature=0 as default when it loaded so, if this is as expected, it might be worth noting in the documentation that this setting needs to be checked and changed as needed).

Since I have both monitors running in tandem just now, I thought a comparison might be useful.
emonTx3 feeds use 100A CTs and the 9v IdealPower supply. They are labelled emonTx4.

emonTx4 equivalents are labelled emonTx4_17 and use the CTs above plus the emonVs PSU.

emonPi Vrms also shown

Clipboard02
Clipboard021128×619 82.3 KB

emonTx4 data are much cleaner, so the design work by the team has resulted in a great step forward: thanks all.

I note that the main grid feed and the Backup load (a DB which remains live during grid outages) overread versus the emonTx3 by +23W and +10W respectively. CTs for the equivalent feeds are right next to each other.

For solar and battery loads, the CTs are not adjacent and the same offset is seen, with emonTx3 values being less than emonTx4 again.

Clipboard03
Clipboard031131×607 87.3 KB

However, in this case, the emonTx4 data can be compared with the data from the Tesla API (shown as circles) and with the SolarEdge data online. Both emonTx4 feeds appear very close to these third party data streams.

I’m guessing the emonTx3 Vrms is off, to explain the bulk shifts between the data sets.

Overall then, the emonTx4 data looks cleaner and more accurate than the emonTx3 data on my system at least

My only concern is the calibration of the emonTx4 grid feed, as this is consistently at +23W when no power is flowing according to all the other independent measures (Tesla, myEnergy CTs and Smart meter display unit). The cable is a slight oval rather than round. I wonder if this may contribute?