Help with abnormal power readings (3 or 4x higher than expected)!

Hi guys,

Just setup my new RPICT7V1 Version 3 board yesterday (lechacal) and managed to add all my inputs to EmonCMS via EmonHub .

Calibrated the voltage sensor but my CT sensor is getting a lot higher wattage readings than it should . Just to give you an idea, a heater that has a previously measured power consumption of around 2000w has readings of 7000w in Emonhub, which checks with the cat from TTYAM0 serial .

I have tried to calibrate this by adjusting my scale to 0.3x and in a way it does kinda work, as the values become much closer to what they should be .

However, I don’t think it’s normal I have to reduce the scale this much and my readings are also a bit off because the low power consumption reads too low but when I turn on the 2000w heater it still reads around 2150 to 2200w .

Which leads me to think there is something wrong with my setup , could it be a hardware issue ?
I had little to no space to clamp my CT in the phase cable so it’s not loose inside the clamp and it’s touching one of the inside walls, could this have anything to do with it ?

Here’s a pic of how I installed mt CT sensor :


I don’t see anything wrong with that, apart from the neutral cable touching it - that is likely to make only a small fraction of 1% difference to the readings, so in real terms, it makes no difference at all.

I don’t know your RPICT7V1 Version 3 board - is the burden resistor the correct value (I can’t find a circuit diagram), and have you got the correct calibration according to Raspberrypi Current and Temperature Sensor Adaptor - lechacal
Those are the obvious points to check first.

What do you mean by that? Which is “my scale”? Do you mean in emonHub scales = ...?

I don’t understand what you’re trying to say there - is there a zero offset - meaning that it reads something when there’s no current? Or is it non-linear so you can make it correct at one power level and then it’s wrong at another?

I have to say I found this sentence on the LeChacal page rather amusing “CT sensors only measures Alternative Currents (AC).” I think somebody needs to point them towards Electropedia.

Thanks Robert, really appreciate the detailed explanation of all these topics .

Indeed I didn’t have the right calibration, hand’t found that before so I was tweaking around with emonhub instead .

Yes exactly !

I mean it’s non linear, exactly as you said !

I believe he is refering to the way the CT sensor works in that specific board, not sure though , I’m super dummy when it comes to electricity :smiley:

I changed the sketch file and reupload to my board with the correct callibration factors for my 30A CT sensor and it seems to be working well now, thanks !

Now just 1 thing left to figure, somehow no matter how lower polling I add and my settings in emonhub I am only getting readings every 30-40 secs, even though I can see my board is sending them with the correct polling interval .

Now you have the correct scale in your sketch, has that now corrected itself?

The word in English is alternating (not alternative) :laughing:

I don’t think emonHub can control that. @pb66 is the creator of emonHub, and he can give you a definitive answer; but my understanding is it processes and forwards the data as received, subject to the receiving software accepting it - because emonHub can, I believe, store the data and forward when the connection becomes available.

This one got my attention:
I realize he may be referring to the CT output, but since his Real Power output
is in Watts, and Vrms is in Volts, shouldn’t Irms be in Amps?

But you don’t get watts (nor volts) from the c.t. :roll_eyes:

Maybe the output is plain text - with 3 digits to the right of the decimal point ?

So how is the data getting to the EmonHub? via a serial connection?

Where do you see those ‘readings’

If you tail the emonhub log, how often do you see a NEW FRAME entry?

Correct, the frequency that the data is created is in the hands of the device, that data is passed to emonhub via serial and emonhub forwards it, it does have a “throttling” feature to limit the number of http requests made to the server, ie if the device sends every 5s, this could be buffered and posted in a single “bulk” upload every 30s, this is predominantly to help’s load and also to help with latger setups, even if you have (for example) 10 emonTX’s sending every 10s, by resticting the send interval to 10s would mean all 10 payloads are sent in one bulk upload every 10s rather than 10 requests each 10s.

Can we assume you are still using original emonhub v1.2? (ref Help with RPICT w/ Atmega Controller - WARNING Device communication error - check settings). What setting have you tried and where is it located? The default setting is actually 0s so by not defining interval = 30 or similar in the http reporter (original emonhub has reporters, the emonpi variant has a http interfacer)

If you look at emonhub.log you should be able to follow each received frame of data through the process to the outgoing http request. Maybe there are some illegal chars that cause emonhub to discard some frames?

Just to reduce confusion, “polling” is a term that is used when one device or software requests or interrogates a device or software for data, ie the “polling” device is in control. Your device is in control, it “posts” or “sends” it’s data when it chooses, emonhub simply listens and acts on data as and when it comes, your device is in control, it isn’t being “polled”. HTH.

1 Like

Looking at this line from the other thread

it seems there are some calibration details printed at start up, maybe it would confirm what is set up regards CT’s and burdens etc.

@Tripton can you try stopping the emonhub service and reading the serial data as described here (Raspberrypi Current and Temperature Sensor Adaptor - lechacal), hopefully the device has a reset? I expect the setup data to only be printed at start up, if you inerupt the power, the device will boot faster than the RPi and the start up text missed, thje device needs restarting without interrupting the RPi.

No I suspect it is set up as mA as the emonhub config on this page (Raspberrypi Current and Temperature Sensor Adaptor - lechacal) shows a specific node definition, plus if you look at this line from the other thread

2020-01-14 01:26:16,288 DEBUG 2 NEW FRAME : 1578965176.29 11 0.0 0.0 0.0 0.0 0.0 0.0 0.0 226.4 203.0 205.7 238.1 204.3 223.7 230.5 0.4

with 7x 0w values followed by 7x 200’ish values I suspect they are indeed most likely mA not Amps.

Yes correct, using serial interface .

The readings are in EmonCMS . After a bit of digging I found the setinterval parameter that comes as default in the configs is not right. In fact, it should be interval instead . After changing it I am now getting the updates every 3 secs as per the polling setting in my board config sketch !

I was just coming to post about that, it was originally “interval” then it got swapped to “sendinterval” in the emonpi variant and has since been swapped back to “interval” so yes it can be confusing. The default settings in the wiki for your device is wrong, it should be “interval”, the wiki was probably written during the “postinterval” era and not been updated.

However! The default setting for the original emonhub (which you were using) is 0secs where as the default for the emonpi variant is 30secs so that leads me to think you are no longer using the original version and are now running the emonpi variant, is that right?

1 Like

Yes Paul, that’s right !

MainThread EmonHub emonHub emon-pi variant v2.1.2

1 Like

Good! Before you go too far with configuration etc, the default feed type in emoncms uses a fixed interval, the smallest is 5secs (on it’s 10s) so having a interval of 3 secs will cause you to lose around 40% of your data and the remaining 60% will be aligned to 5s intervals in the feed, therefore if you later run graphs or post-processing your results may be inaccurate as what was reported as 2 3s payloads will have one dropped and the other stretched to 5s. I would highly recommend changing that setting to 5s in yor device if that is possible. The norm here is to now use 10s intervals, this also increases accuracy further due to the way emoncms truncates timestamps to whole seconds so 2.99sec intervals (eg not quite exactly 3s) becomes 2s, that’s a 33% potential error, where as 9.99s intervals become 9s, that’s only a 10% inaccuracy. Some believe that these errors “average out” over time but that is not possible as the timestamps are always truncated with int(timestamp) rather than rounded with int(timestamp + 0.5), rounded would average out over time as there will likely be as many rounded up as rounded down, where as truncate is always rounded down, never up.

Are you now getting realistic values? If not please post a longish emonhub.log excerpt we can take a look at or try the test I mentioned previously and post the results here.


Thanks for clearing that up !

May I know what causes this limitation in EmonCMS not being able to keep up with the polling rates of the input devices ?

Wouldn’t it be able to process all the data properly with a 3sec time interval considering the server specs were enough to handle this ? 1 database call every 3secs isn’t something that would require any high resources .

Sadly I still have a non linear behavior on my measurements .

What is happening is that there is a difference in the accuracy between low power devices and the high power ones . For example :

If I set my calibration factor to match the expected power difference from a heater that does 2000W power consumption, my lower reading consumptions (standby devices, freezers, etc) are a bit off and reading lower values than expected .

If I set calibration factor to match the lowest reading power consumptions than the heater will not read the 2000w but a lower value .

A bit lost about this but it’s hardware related so I don’t know if anything can really be done here .

Emoncms is quite capable “of keeping up” you could be posting (not polling) data from many devices in 10s, 5s, 3s or even 1s intervals and it will keep up, take for instance, that keeps up with thousands of devices posting every 10s.

It was decided many years ago that the highest granularity that was needed was 1s therefore emoncms uses whole seconds only, parts of it use js which uses whole milliseconds but that is pretty much like measuring for a carpet in mm when it’s sold by whole meters only.

Given the 1s maximum resolution, there is the ability to use 1s intervals in phptimeseries or mysql feeds but another decision in emoncms was to make only the phpfina feeds available to the apps module and a few other features, so if you deviate from the run of the mill phpfina then you start to face other restrictions. As explained above, the fact that emoncms truncates timestamps, a 1s interval would be +/-100% inaccurate as 0.9999s would be seen as 0s whilst 1.0000001 seconds would be seen as 1s. This renders small interval more vulnerable to errors and since all the OEM sketches (except the emonpi strangely) have a max post rate of 10s as that was a happy medium that provided fast(ish) updates without overloading (almost halving traffic from old 5s intervals) with minimal inaccuracy, there was no point supporting smaller fixed intervals than 10s, except on local installs to support older 5s devices (and emonpi’s).

If you want greater resolution I would recommend using grafana/influxdb.

Maybe not but it would potentially require 3x as much as 10s, and it’s not just about posting the data, you also need to query the data to see it, with files 3x the size containing 3x the datapoints and rendering 3x the data on screen it can mount up. Nearly all graphing uses “cherry picked” values to form a view anyway, if you try to view 1 whole day it may be in a graph 900points wide (or is it 1200 I forget either way) so whether that is 900 of the 8640 10s datapoints or 900 of the 28800 3s datapoints it still won’t be 100% accurate, but either way it will be more accurate than you are likely to detect at that level, its only when you start looking at 10min periods under the microscope that 3s is better than 10s, but due to the “whole second” thing it’s still not accurate and therefore almost without value.

If it’s non-linear I would suspect that is a phase error effecting loads of differing PF differently, either the CT’s are not fully close. broken or the calibration isn’t quite right, hence my requests for the data previously.

1 Like

I concur, and most likely the latter. Over time, the characteristics of the SCT-013-000 have changed, even the default value we use in the emonTx (1.7) is no longer correct; from memory it should be nearer to 1.9 for “medium” currents (and by reversing the order of reading current and voltage, the amount of “correction” could be reduced significantly, at the same time reducing the errors that the phase shifting algorithm introduces - but that would give us a backwards compatibility nightmare).

Now those can easily have very low power factors, where any phase error is most significant, but apart from that, c.t’s are inherently inaccurate at low currents - it comes from the physics happening inside the ferrite core. The best solution is to correctly size your c.t. for the maximum load you want to measure, the expensive solution is to use a higher grade (“revenue”) c.t. whose accuracy band goes lower. (The SCT-013-000 is only specified for accuracy down to 10 A.)

1 Like

the expensive solution is to use a higher grade (“revenue”) c.t.

In case someone asks the question “how much does a revenue grade CT cost…”

Here’s a revenue grade 75 Amp CT with a 13mm wire window. Cost is 10.27 USD.
Made by CR Magnetics. The data sheet says the max output is 12.0 Vrms.


Availabe in 40, 50 and 200 Amp variants as well.


1 Like

That of course is a ring-core device, therefore installation for some could be a problem. A split-core of equivalent quality will be somewhat more expensive.

True. Those offered by Magnelab and Continental Control Systems cost ~50-55 USD.

I think next time I am in a position to do so, I’ll install all of the house circuits in such a way that these can be fitted at install time.