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.
So if the CT is 30A and the average load is low in the range of 2 to 3A or lower (also loads are not resistive) to change Phase_shift to 1.9 from 1.7 and measure current first and the voltage after?