While no customers have asked for this directly, I have seen many customers ask how to check a tag for being stale. The solution to date assumes all tags have the same staleness timeout, which really is not the case most of the time.
This new "StaleTimeout" point attribute would be a duration (time span) customizable for each tag. There could also be a new PIPoint property called "IsStale" which could bounce the current value's timestamp off the "StaleTimeout".
ADMIN RESPONSE
Aug 20, 2022
While this remains in our backlog, it has not been prioritized. We will revisit this idea with our next prioritization exercise.
I would benefit! I am new to Pi and learning the system. We have implemented an instance of the UFL Interface and bringing in some CSV's. We haven't quite decided at what time frequency we will bring data in but the smallest resolution of time would be one day (we gather data nightly and would push to Pi). However, this time frame could easily change. So overall as a customer I would appreciate a parameter I could control and what denotes a stale value. Thanks.
I have a customer who archives a value every minute for all tags, even if the value hasn't changed. The reason they do this is so when they look at a trend over an historic period they distinguish between flat lining data (i.e. value was being read from the instrument, it just wasn't changing) and stale data (i.e. there was an issue reading the value of the instrument). In combination with the stale timeout attribute, the value that is stale could be marked as questionable so that when you later trend the tag you can see that it was stale and not flat lining.
We generate a daily stale tag report that's clouded with tags that aren't actually stale because we have to apply the same staleness policy across all tags. For example, some tags only get new values once per month but they're held to the same standards as a tag that should be getting a new value every hour. Wading through non-stale tags (and making sure to recognize when they are in fact stale) adds a lot of time to our troubleshooting efforts.
