I have experienced the same issues in the past and it can be really troublesome.
Analysis service does have issues with lag (such as from PI-to-PI) and does ignore out-of-order data for triggering conditions. The only workaround I know for this, is to use PE expressions and use more advanced triggering conditions. Note, in this thread Event Frame Analysis: EndTrigger "True for" setting , Jim Gavigan shared his approach to time true.
For event more complex situations involving 'True For', we had to write an event generator engine.
There are a few obvious scenarios where this is problematic.
First, if there is known latency in your connection, then the "True for" setting essentially includes the latency in its time count. For example, if we have a "True for" setting of 2 minutes and the data arriving at the PI System is 1 minute old, then the "True for" setting essentially checks that the condition is true for only 1 minute. If the data arriving at the PI System is 2 minutes old, then the "True for" setting has no effect.
Second, if there is a data outage of any significant length of time, the "True for" setting has no effect on the analyses that run as the data unbuffers.
Admittedly, this is a complex problem. Giving us the option to configure the "True for" setting to be event-interpreted rather than clock-interpreted would allow us to customize the analysis to user requirements and data delivery constraints. In other words, the "True for" should only be evaluated when the next input value for the analysis is received in the event pipe.
Eduan Smit, thoughts?
I have a similar problem, becuase of the configuration the type of number.
Have you try to put ‘LT-Test01’ = "1", and see what happen???