Can one tell which point has triggered the context update?

[Phillip Weeks]

Thanks Guys this was very useful

[Phillip Weeks]

Given that we are using getTimestamp vs getRuntime.. Is there a way to write the script so it can also perform a historical recalculation of the meta point based on logged point values of the CONTEXT points.

How can I see the functionality available for this[pnt] ?
print(this[pnt]); is undefined

[MattFox]

This should help you work out what is available for the point:
https://help.infiniteautomation.com/about-mango-java-script/
It lists all of the function calls that can be made from a point instance.
When you say historical recalc, are you saying you want to alter the values in the datapoint's history?
Or do you mean you want to perform a function utilising the history of all of the datapoints in use for the meta datasource? If it's the latter, that I can definitely help you with.
Phil might have a better explanation as to why, but I would have surely thought the code should have said:

 if (timestamp == pnt.timestamp)
      return pnt;

So you'd be writing:
print(pnt); instead
I'd be keen to see how this pans out.

[Phillip Weeks]

Yes I calculate and log changes for a group of counters and I log the total changes of all counters to grand total metapoint by running this script at the start of the minute and also on cron on 5 minute intervals as a test also. Grand total = point.runtime.prev(MINUTE,1).sum over all points in the counter set and log this grand total on timestamp change for the total change last minute.
It works in real time, however I want to run it over back through the history of the metapoints it sums.
ie.

var Building_Total_Liters =0;
for(var k = 0; k < pointsList.length; k+=1) {
    if (pointsList[k].runtime !== null)
        Building_Total_Liters += pointsList[k].runtime.prev(MINUTE, 1).sum;
}
if (Building_Total_Liters === Number.NAN) return UNCHANGED;
else return Building_Total_Liters;```

To achieve a similar result with CONTEXT points I thought I could log the context points total values that are in current CONTEXT timestamp to the grand total log
and I am not sure If I am thinking about this correctly ... can there be several trigger points with exactly the same timestamps in CONTEXT?

[MattFox]

Whack three tildes ``` on both sides of your code to turn it into a code block - makes it a bit easier to read.

I see, so when you say run it back through the history you merely want to combine 'n' amount of time's worth of values, not actually change the value of the metapoint at say the 12th of July at 5:05AM.

@phillip-weeks said in Can one tell which point has triggered the context update?:

can there be several trigger points with exactly the same timestamps in CONTEXT?

I wouldn't rule it out as a possibility, but as the timestamps go down to the millisecond, I'd be very impressed if that did happen.

[terrypacker]

@phillip-weeks said in Can one tell which point has triggered the context update?:

can there be several trigger points with exactly the same timestamps in CONTEXT?

@MattFox it's also more likely/possible if you have points from the same polling data source that update your context. For example if on a poll a data source updates the values for all of its points then the timestamp of all the new values will be exactly the same (the time of the poll).

[MattFox]

@terrypacker thanks for making that known, I'll be sure to keep that in mind.

[phildunlap]

Meta data points actually have code to prevent them from running twice sequentially on the same millisecond. This is because the NoSQL database doesn't insert old data as efficiently as current data and very many users were seeing massive machine utilization with innocuous meta points (a + b + c type stuff) that were simply receiving multiple updates at the same timestamp often because the context points would originate on the same data source. So now a meta point will not trigger twice from two updates at the same millisecond, where a script could (but it doesn't have the ability to see which point triggered a context update as I demonstrated in this thread because the timestamp is not artificially set to the time of the point event... I wonder if it should, since the CONTEXT object also has a runtime already, and in the scripting data source these are always the same currently)..

[andrewh]

Thanks for the information in this topic. I used it to create the following scripts that seems to work very well in creating a value with the correct timestamp even when one clock is out, there is a delay in one value arriving or even when the data arrives out of order:

var sampleTime = CONTEXT.getTimestamp();
var value1 = p1.pointValueAt(sampleTime, true);
var value2 = p2.pointValueAt(sampleTime, true);

LOG.info(sampleTime);
LOG.info(value1);
LOG.info(value2);

// If both points have a value at this time, then calculate and record it
if ( (value1 !== null) & (value2 !== null)) {
LOG.info('Saving data');
TIMESTAMP = CONTEXT.getTimestamp(); //sampleTime;
var valueCombined = (100*Number(value1.value)) + Number(value2.value);
LOG.info('Logging ' + valueCombined + ' at ' + TIMESTAMP);
return valueCombined; // This is a string
}
else { // This is the first point value received for this time
// The combined value will be calculated when the value for the other point
// triggers this script
return UNCHANGED;
}

This works well even if the publisher can't publish for a couple of days and buffers the data.
It anyone has any suggested improvements, please let me know.

One thing I have discovered is that if the data has trouble getting through, and the buffer fills up or is reset for some reason and the data comes through in a synchronization, then the script is NOT called, so the meta point is NOT calculated. I know it's possible to perform a manual "Generate History" on the meta data source. Does anyone know a good way to automate this to calculate meta points after a synchronize?

[andrewh]

I have performed further testing and found the above script needs an Execution delay of at least about 5 seconds to work. This is because if the 2 source data points update within a few seconds, the script is only triggered when the first one is updated, not the second one (ie the script won't trigger again within a few seconds of it running).
Unfortunately, further testing has indicated that the script no longer works reliably where there is a comms outage causing a delay in some of the data.