Send Notification Alert only on Close

In our situation, the details of an event are not written to the PI Point Attributes of the Event Frame referenced element until the end of the event. Consequently, without the option to send a Notification at the end of the event frame, I am forced to create 2 Event Frames: one EF captures the data for the entire event and sends a Notification that the event started, and a second EF that captures the details at the end of the event and triggers a Notification with the event details. I would not need two Event Frames if I could trigger a Notification at the end of the Event Frame.

We have the same situation. This seems to be a natural extension to notifications - if you can notify at the start, notify at both start and end - why not just end?

@kliffhopson: What details are captured only at the end of the event frame? The configuration would usually dictate that there's some calculation that is ongoing. So are you saying that the finished data needs to be included in the closing email, and this captured detail usually differs from the data that is captured during real-time? Also, this makes it sound like Notifications is also acting as a reporting mechanism and not just alerting. Is that correct? In general: What is the advantage of only sending on end over sending on both? The purpose of Notifications is primarily to inform users to take action on something or to inform them of related data to a user-created event. Sending an Event Frame has been opened would give people information about what event is occurring and the relevant data. It may spur them to take some sort of action. Sending out the corresponding close would tell them they no longer need to take action. If we only sent it on close, most users would need additional context on what happened in the first place, when it happened and why it happened. This seems to be directly answered by sending on start. Technically, this doesn't seem like a difficult thing. But I think I need more info to understand what space it is filling.

@Hahnming: my responses are in bold What details are captured only at the end of the event frame? The Event Frame Analysis references an AF Element with Attributes that are all PI Point data references. One of those references is a roll-up alarm tag that alerts about any alarm in a large group of alarm tags. This is the attribute that is used to trigger the Event Frame. At the moment when that tag stops alarming, the application writes values to the rest of the tags referenced by the AF element - these tags report the details of the alarm event. ..are you saying that the finished data needs to be included in the closing email, and this captured detail usually differs from the data that is captured during real-time? The detail tags referenced by the AF element are normally "No Data." They only have the event details for the 10 second period that starts at the end of the event. Also, this makes it sound like Notifications is also acting as a reporting mechanism and not just alerting. Is that correct? No. I don't see how you infer that from my statements. However, I do see Event Frames as a reporting mechanism. And Notifications are now triggered by Event Frames. So... ? Regardless, the difference between "reporting" and "alarming" is mostly semantic. Alarms are reports. And reports can be for alarms. What is the advantage of only sending on end over sending on both? The information is not available until the end of the event. If I use the option to send (the same message content) at the start and the end of the event, then the message at the start will show "No Data" for most of the message contents. This is not useful and also looks bad. In conclusion: We do need to send a Notification at the start of the event. But that Notification needs to be different than the Notification that is sent at the end of the event. It would be ideal for us to have a single Event Frame that can be used to trigger 2 different Notifications - one at the start and another at the end of the event.

I can add our example where it might be helpful as well. When a generator trips off line unexpectedly it cause a dip in the frequency. We have an event frame that triggers when the frequency dips below a certain value. But of importance here is what was the lowest value for frequency during this event - what we trigger on most certainly will not be the minimum. So we have that calculation in an attribute in the event frame template. We use a 'recovery' value in the template (higher than trigger value) in order to end the event frame so the calculation will yield a result. If we built a notification with present capabilities, we have include the start time, end time and this minimum value attribute. Problem is - at the start - end time and minimum value are garbage - no result yet. Having emails with end time of 1969 - not elegant at all. So in our case - we want to send a notification of the event with the stats of the event - the duration of low frequency condition and the minimum value. Hence - all I want to send is one notification at the close of the event frame.

OK, good to know. I think anything that is outside of the actual trigger for the alarm is reporting info related to the incident while the trigger is related to the event. So if the end trigger is used both to close the event frame and to write data to it, I can see where there is some sort of inconsistency. Is this some custom application that is writing it? Are the details related to string data? Just wondering since we could couple it into the trigger if necessary. Also, if we gave the option only on notify on close, it sounds like this use case would still require something like a delay? Or are you just asking for being able to configure different messages altogether depending on start vs end? In terms of reporting/alarming, sure. I set a distinction if only because Notifications is (besides ACE/something custom) the only way that we can really send emails. I would say that any email that doesn't spur action to do something about the start trigger would be reporting and not alarming, but again, I understand if this is just semantics to most people.

@Hahnming: my responses are in bold Is this some custom application that is writing it? yes. Are the details related to string data? Some of the details are string data type. Some are boolean. Some are numeric. Also, if we gave the option only on notify on close, it sounds like this use case would still require something like a delay? Or are you just asking for being able to configure different messages altogether depending on start vs end? I am not sure that I understand what you are asking. In our case, the end of the event is triggered when the boolean alarm tag that triggers the start of the event frame returns to normal. The time stamp of the event details has the same time stamp as the return-to-normal event of the alarm tag. So I don't think a delay would be necessary for this case. Also, thank you for being so responsive to our request for this new feature! And thank you for making the effort to be certain that you understand our requirements.

In response to Bruce McCamant, "I can add our example where it might be ..." Bruce, Thank you for participating in this discussion! It sounds like your requirements are very similar to ours. And your perspective is valuable. Sincerely, Kliff

We would like this feature so we can alert when batch has completed. There are attributes that are true/false when the batch is active.