Extending the Reports
-
We are using Mango (1.8.2) to monitor several systems and record some test data. There are two things I would like to do to augment reports:
1.) I would like to extend the freemarker template used for viewing charts to include the point's datasource name. Is this variable available to freemarker? The same change would be desired for the consolidated chart.
2.) Can the .csv export be modified to place the different data points in columns across the spreadsheet instead of having each datapoint sequential? The result being to have the timestamp in column A, first datapoint value in B, second datapoint value in C, etc.
If someone could point me in the right direction, it would be appreciated!
BRAD
-
Hi Brad,
-
Should be straightforward, and since this is done in other areas of the system it is also reasonable. On the consolidated chart the legend might start wrapping, but that's about as bad as anything would get.
-
Multiple trend reports (for lack of a better name, referring to a single timestamp and associated point values) are tricky because there may not be a value at a given time for a given point. What would the report look like if you selected, say, a point that updates every 5 seconds, and a point that updates every 5 minutes? There are certainly solutions to this problem (with a dash of "garbage-in-garbage-out" caveats), but suffice to say that this is not currently available in Mango.
-
-
Matthew -
Thanks for the reply. I guess what I was looking for in the first question is, what is the variable name I should reference in reportChart.ftl in order to display the datasource name? Also, if you can point me in the right direction to the .java file where the data is gathered for the jfree chart generator, I would appreciate it.For anyone interested, I did come up with a possible alternative solution to my second question. It is required for all of the points to be updated at the same time to avoid the problem Matthew described, but it seems to work. A Mango publisher can be used to upload data to a Google spreadsheet. To figure out what variables to use, create a form in Google docs and look at the source code for the form. It will have the url to post to in the form action and the parameter names to use (namely entry.0.single, entry.2.single, etc.) Just remember to add a static parameter of submit=submit. I was hoping to do this in Mango natively, but this seems to work OK.
BRAD
@mlohbihler said:
Hi Brad,
-
Should be straightforward, and since this is done in other areas of the system it is also reasonable. On the consolidated chart the legend might start wrapping, but that's about as bad as anything would get.
-
Multiple trend reports (for lack of a better name, referring to a single timestamp and associated point values) are tricky because there may not be a value at a given time for a given point. What would the report look like if you selected, say, a point that updates every 5 seconds, and a point that updates every 5 minutes? There are certainly solutions to this problem (with a dash of "garbage-in-garbage-out" caveats), but suffice to say that this is not currently available in Mango.
-
-
Hi Brad,
Re 1), Turns out it was not so straightforward. A table needed to be altered to accommodate the data source name, and the value carried through to the report. The changes will be in 1.10.0.
-
2.) Can the .csv export be modified to place the different data points in columns across the spreadsheet instead of having each datapoint sequential? The result being to have the timestamp in column A, first datapoint value in B, second datapoint value in C, etc.
- Multiple trend reports (for lack of a better name, referring to a single timestamp and associated point values) are tricky because there may not be a value at a given time for a given point. What would the report look like if you selected, say, a point that updates every 5 seconds, and a point that updates every 5 minutes?
I have a patch that is useful when interval logging is used. I believe I patched the interval logging to log the scheduled fire time of the log method as opposed to the actual, and also to log all values at the same interval (ie all values logged every 5 minutes get logged at 0 minutes past the hour, 5 minutes past the hour, etc).
Then there is another patch which puts all values in the CSV writer with the same timestamp on the same row.
I believe other scada packages interpolate and average the data as required to get a value in each column for each interval.
-
Hey Craig,
If your report was, say, for every 15 minutes, and you had the following data:
1:45 - 10
1:50 - 11
1:55 - 12
2:00 - 13
2:05 - 14
2:10 - 15
2:15 - 16... what will the value for 2:00 be?
- The average of (1:45 to 2:00] = 12
- The average of (1:52.5 to 2:07.5] = 13
- The average of [2:00 to 2:15) = 14
- Something else
Personally i'd think it's 1) since the five minute readings may be historical averages anyway. But, if the readings are all instantaneous maybe 2) is correct. Also, in a case like this:
1:45 - 10
1:46 - 16
1:59 - 11... what is the value at 2:00 now? I believe the value should be weighted to account for the length of time a value was held, so the 2:00 value should be (10 * 1 + 16 * 13 + 11 * 1) / 15 = 15.27.
What do you think?
-
Hi Matt,
In the case where the logging interval is faster than the reporting interval, ie with a reporting interval of 15 minutes and a logging interval of 5 minutes, I'd expect the value at 2:00 to be the actual sample: 13.
The actual values logged could be instantaneous or the average of all the samples since the last logged value. For instance I have the modbus data source poll time set as low as I can without the polls starting to overlap, about 10s. Most variables I simply log the instantaneous value every 15 minutes, but for particularly noisy ones I log the average of the 6 samples/minute * 15 minutes = 90 samples. The result is there is some time delay in averaged samples, I think that it is acceptable, but I suppose it depends on the characteristic of the process.
For the second case, where the report interval does not coincide with the logging interval, I would linearly interpolate between each point. Thus to report on the value at 2PM a value after or at 2PM would have to be logged.
Slightly unrelated, but I've been meaning to look into how RRD (http://oss.oetiker.ch/rrdtool/) stores data as I believe it sets the bar for high performance logging and archival of time series data. There is a java port as well I believe.