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 ?
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.
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
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)
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.
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 emoncms.orgâ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.
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?
Good! Before you go too far with configuration etc, the default feed type in emoncms uses a fixed interval, the smallest is 5secs (on emoncms.org 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.
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 emoncms.org 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 emoncms.org (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.
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.)
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.