On all Measurement Apama EPL

Hello everyone,

I’m working with a CAN message that is read via device protocol and split into two 32-bit Measurements. In my EPL logic, I analyze them using the following structure:

pythonCopy code

on all (Measurement(type=MEASUREMENT_TYPE_A) as first32Bit and Measurement(type=MEASUREMENT_TYPE_B) as second32Bit)
    // Logic goes here

However, I’ve encountered an issue where if only one of the 32-bit Measurements changes while the other remains the same, the statement inside the block will not be executed. Changing the ‘and’ operator to ‘or’ resolves the issue, but it complicates referencing both ‘first32Bit’ and ‘second32Bit’ inside the logic.

How can I adjust this so that the statement is executed even if only one side is updated?
Your insights are appreciated.

Is there a reason you don’t keep the measurements paired as separate fragments or series on the same Measurement event? That would remove the need to recombine them via a listener.

The reason for this setup is that at the end of the logic, I have some data that needs to be processed only after both measurements have been accounted for.

I think this is because of the way device protocols work: if you extract the two 32 bit parts separately to send measurements, it will produce two separate measurements.

I am wondering, why you are not keeping the 64 bits in a single measurement?

There is an issue when reading all 64 bits at once. So for this I had to split them in two 32 bit measuremts.

Wouldn’t having the two values on the same Measurement event automatically account for them both with your final bit of logic?

Multiple ways I can think of:

  • Use “or” as you mentioned in your original message and work with “ifpresent” to detect which of the two event types actually triggered the listener
  • Use the same measurement type but different series in the device protocols for the two 32 bit parts. Have a single event listener for both and inside of it work out which of the segments was actually sent.
  • Create a listener without a “type” filter and use if-statements to detect which of the two event types was received.
  • Create two separate event listeners for the two types

The second option is actually my preferred option. In any case you will probably need to retain the previous value from the other measurement. Note that you would need to keep that in a dictionary or sequence to be able to access updated values inside a listener.