Time-based logging type
-
I'm thinking of adding a logging type so that pointvalues can be logged every X (minutes|Days|Months|Years).
Most of the data i've come across in the electricity business is logged every 5,15, or 30 minutes.
It would be useful to have this logging type so watchlists and views could update in near real time without generating excessive amounts of data.
The logging on change by tolerance feature is nice (especially for multistate and binary points) but for analogs it requires a good idea of the amount of noise in every point to set the tolerance properly. Can offer great resolution when required though.
I might tackle this myself. Any input before I start?
-
Interval based logging is included in the commercial version and it does a great job of allowing the watchlists and graphical views to update multiple times per minute and log the average/min/max every specified inerval.
My personal preference for hourly logging is to have the point values logged on the hour and for 15 minute intervals to be logged at 00, 15, 30 and 45 minutes past the hour. It seems that currently the values are being logged every 15 minutes, but not on the hour etc.
One of many things on my to-do list!
-
Hi Craig,
As much as possible having processes run at specific times (e.g. 0/10, 0/15, etc) is avoided because it can make for big spikes of processing at those times. When the timing of things is based upon when the resource started it makes for more balanced CPU utilization.
This of course is doing things for the sake of the machine rather than the user, but it's meant to keep users from getting themselves into trouble without knowing it.
-
Yep I can see that it might peg the CPU when I tell it to log 400 point values at the same time but that is what I need.
with that many points to log all at once I wouldn't expect them to all be logged instantaneously and simultaneously. I'll go back to the patch I had to see how well it coped. I do recall I was using the time the quartz job was meant to fire instead of the time it actually fired for the timestamp so that even though many of the jobs were run 'late' they would all still log the exact same timestamp.
-
The other issue here is the problem of deciding on a starting time. If your interval is, say, 15 seconds it seems obvious to start at the top of the minute, or maybe the nearest multiple of 15. But what happens if your interval is 13?
You also open the door to special cases. What if my interval is 24 hours, but i actually want it to run at noon? Cron expressions may help, but they can't do things like every 7 seconds. Also, if you replace the existing interval selection with crons, you force all users to learn cron.
If you offer both crons and the existing interval selection, then the interface becomes more complicated. Eventually, when you decide to be everything to everyone you end up with the interface used for scheduled events.
-
Eventually, when you decide to be everything to everyone you end up with the interface used for scheduled events.
I'll think about triggering the logging from a scheduled event then!
-
You're hard core dude.
-
really I just want to augment mango to suit our requirements without having to maintain a patchset and our own build
-
:)
Seriously, don't get me wrong, the functionality is all good. Maybe a way to keep the interface clean is to have some kind of "advanced" button that exposes the extra options or something. We'd have to consider how that would behave when you return to the page later on (i.e. decided whether to expose it by default depending upon options chosen...).