1 of 1 people found this helpful
In case anyone is still wondering about this, I went ahead and added a line to my fault check analysis that writes the current fault count to a new attribute I created. The attribute writes to a tag with archiving disabled, since I don't need the history. As expected, the event frames bring in that value just fine. One thing to keep in mind is that because archiving is disabled, the event frame attribute value won't make sense when looking back at past event frames. For my purposes, this is acceptable.
I probably should have lead with this, but the overall idea here is about notifications for interface device statuses. I have an analysis that will write a value of 1 to an output tag when the device status tag has a value that I consider a fault (and write 0 when back to normal). This is then used to trigger a notification. It works great for most interfaces, but I've found that some interfaces, from time to time, can rapidly fluctuate between a good and bad device status. This causes an excessive number of notifications to come in. Manually disabling and re-enabling notification rules for the large number of interfaces we monitor is out of the question, so the event frame attribute I created serves to automatically suppress the notification (via notification rule trigger conditions) when an interface has more than 20 device status faults over the past 7 days. And it's been working great!
Hope this helps someone, and feel free to ask me questions.