1 of 1 people found this helpful
One possibility is that the device is buffered or is otherwise not consistently reporting every minute but still produces timestamps spaced at one minute intervals. There is no way force Notifications to process all values with a periodic trigger. You would have to use a natural trigger.
Another possibility that is fairly common is that both the device and Notification frequency are such that they are both operating at the top of the minute. Then there is a race condition as to what Notifications sees. If Notifications checks before PI Data Archive has completed the write from the device, then it will get the previous value. This could cause one of two things to happen, either a Notification is not started when you expect or we miss a close and an instance continues longer than expected. Either way there could be missing sends. If the device's write completes first, Notifications sees the update and does what you expect. Who wins depends on factors like network latency, load on the Data Archive, load on Notifications service, etc.
If I am correct, some suggestions to mitigate this issue are
1) Set the notification's periodic frequency slightly shorter than the device's update cycle. Say 30s instead of 1 minute.
2) Offset the Notification's check so that it is checking after the device reports. So if the device reports at the top of minute, set the offset in notifications to 10 seconds, for example.
If you are getting too many spurious Notifications you may want to use TimeTrue on the condition (this prevents small blips from starting a Notification) or non-repetition (this is more of a suppression on the "Send" side of things).
Thanks, Mike. That makes sense.