Can the update time in a local copy of EMONCMS be shortened so it is more responsive to changes in power use? I’ve set my EMONTX sketches to update at a quicker rate than the 10 seconds in the standard sketch, but my dashboard still seems to take several seconds to respond to changes in power use.
Have you changed your emoncms input processing to log to feeds faster than 10s?
@glyn.hudson I tried creating a new feed with a 5 second value but it didn’t seem to make any difference. That was created on the previous version though.
Curiously enough the inputs page never seems to update at greater than 10 second intervals, yet emonhub.log shows the updates are coming in at 4 second intervals which is what the sketch is set for.
Is there a setting somewhere that tells the inputs page what speed to update at?
What I would suggest is checking that the feed itself has the updated data first (although there is a good chance you have done this). Go to the setup drop-down, select feeds, expand the node, then click the eye icon next to the quick-update feed. Zoom right in to the feed and make sure you can see changes every 5 rather than 10 seconds.
I had a feed which although I was sending every second, only stored once per 10
I have a related question about how often the processlist is run, for any given Input. I understand that feeds sample the data passing through the list at set intervals, and that the “last value” as recorded by the Input will only change when new bulk serial data updates it, but my question is; if there is more than one feed in a given processlist, how often does a feed pass forward a new “last value” to the next process? Ie, is there any point in a subsequent [log to feed] having a feed interval of 10 seconds if an earlier feed has an interval of 1 minute? Can a [log to feed] hold up the flow through the list?
Similarly, with an Input that updates every 5s or so, how long does it take for a processlist to be completed, ready for the next value?
@kevin - What you maybe seeing is the inputs page refresh rate rather than the update rate of any inputs. The feed and input pages are more for the administration than the monitoring of the values in realtime. You could use a realtime visualisation but if using a phpfina feed you will be seeing the feed updates not the input updates.
@coldpenguin’s suggestion will also show when the feeds are updated but not when the inputs were updated, eg if you have a phpfina feed with a one minute interval it would not display the 10s updates and only display the feeds datapoint at the 1 minute interval or rather at the next update after 1min has passed.
@MikeSims - The full process list for any input is run as and when that particular input is updated and if any one feed’s interval (on that processlist) has passed since last update it will create a datapoint. So to use the previous example approximately every 6th “10s update” will result in the feed creating a datapoint, the other 5 would be ignored.
Therefore when doing tests like this the best method is to create a phptimeseries feed right at the top of the processlist, first item and call it something like input1_raw. It can be deleted at a later date, this feed will track the input updates rather than the feed intervals and be updated with a data point at every input update as it happens without being rounded to the next fixed interval.
Then you can use a “realtime” visualisation set to 1min to see every datapoint (aka input update) you can also use this (temporary?) raw phptimeseries feed to check the fixed interval feeds during the setup and configuration phases
Aaah! Thanks, Paul, that’s something I can experiment with. I have noticed that some feeds record pulses that subsequent feeds seem to ignore or miss, and the Raw feed could help me see what is happening. With transient values like a pulse, single values can disappear if the sample timing is wrong.
Having started trying to understand how everything works and why it does what it does, and why it sometimes fails, it’s a bit like falling through the rabbit hole, there are many strange wonders to behold on the way down, and it never stops!
@pb66 is there any way to change 10 second feeds into 5 second feeds without losing any data?
I guess I could create a set of memory feeds on 5 second updates to use for display purposes but that seems a little too wasteful on resources on a heavily loaded pi3
Is there a reason why [Rate of Change] doesn’t forward any value to a subsequent process? I want to derive a pulsegap duration between two adjacent pulses from the pulsecount Input in a processlist, and [RoC] would appear to be an integral requirement for this, but while it logs differences between current and previous values it doesn’t pass them on for further processing, it actually curtails further processing. The source code shows the return $value is commented out.
actually it appears that the dashboard IS updating at 5 second intervals whereas the Inputs page seems to update at 10 second intervals. On my system further complicated with the occasional missed packet no doubt due to 2 EMONTX’s and 1 EMONTH together with several 433MHz relays all fighting for bandwidth in a one way radio environment.
Is it possible to change the logging time period on a PHPFINA feed without losing existing data?
Sorry I don’t know if there is a tool to do that, there has been a fair few scripts for data manipulation, back-up and conversion but I haven’t kept up with them.
It should be a really simple process and there should be no loss of data since all you are essentially doing is inserting a 4byte null datapoint every 4bytes throughout the existing feed datafile and changing the meta file to say 5 secs rather than 10 secs. The data file will be twice the size, start at the same time and appear to have every other datapoint missing up to the point of change. Only increasing the interval should involve discarding (or merging/summing/averaging) datapoints.
1 Like