Developer ‘Tiqs & Tricks
September 2024
Filters for Fun & Profit
The Activity Patterns in the Filter category are “picky listeners” that speed up real-time responsiveness by only allowing events through for further processing if those messages are what they want to “hear.”
Developers set “what” for which each pattern is listening, but the “how” differentiates them from each other. There are four Activity Patterns in the Filter category:
- Dwell
- Filter
- Missing
- Threshold
We’ll start with the namesake pattern, and explain how each of the other patterns puts its own spin on how it’s listening for just the right event conditions.
Author’s Note: Any health metrics examples given below are for the purposes of explaining Filter patterns, nothing more. They are not intended to be medical advice!
Filters see events in “black and white”; something either is or it isn’t, full stop. With handy logic operators like AND (&&), NOT (!=) and OR (||), developers can fine-tune specific ranges of single or multiple properties to determine what should be admitted for further processing.
Example: Live biometric data is coming in from runners in a marathon. Our program checks for any pulse readings higher than 200, to alert the runner’s coach of a possible health issue.
One important thing to mention about Filters: Only one event is ever considered for this gateway. Filters don’t look for trends in a stream of events.
The Dwell pattern, in contrast to the Filter pattern, requires a stream of events for its gateway. The filtering condition must be true over a period of time before further processing will occur.
Example: Coaches want their runners pushing themselves hard, but not too hard. They’ve decided that the best heart rate range during the race is between 160 – 180 beats per minute, and they want to know when athletes stay in that range for at least three minutes. So they add a Dwell to the Visual Event Handler, to check for heart_rate < 181 && heart_rate > 160, for a duration of at least 3 minutes:
All well and good, but if the athlete’s heart rate
- continues in that range, or
- leaves that range,
…Dwell won’t send any events through; once the condition is met once, Dwell sends that event, and no more.
Only if the heart rate re-enters the range for the 3 minutes would Dwell allow another event through.
Enter the Threshold pattern, which can listen for a events meeting a criteria, and also listen for when those events leave the criteria. Unlike Dwell, however, there’s no time lapse requirement. To explain this activity pattern better, here’s a Threshold configuration, and we’ll go over it means:
At the top, you see our one required parameter, which is the condition that the pattern should detect. No surprises there.
direction: This can be true, false, or both. If true, then Threshold works pretty much just like a Filter, sending on any event that meets the criteria. If false, then it will only send on events that don’t meet the criteria(!) But the beauty of this pattern is
by having both, which will send an event when the criteria is met, and one when the event falls out of the previously-met condition.
We’re not worried about the first heart rate reading of each athlete meeting the criteria, so we can safely ignore the initialStateFirstEvent and the initializeCondition evaluation parameters, but if we didn’t start collecting data until somewhere in the middle of the race, we’d want to set those so the threshold could record whether or not the events met the criteria from the get-go.
overConsecutiveReadings is very handy, especially if our sensor equipment is bumping along on a runner. In our case, the Threshold won’t send on an event unless either the racer’s heart rate measurement has stayed in the 160-180 range for 3 consecutive readings, or left that range for 3 consecutive readings.
withinDuration means that the system will need to see those three consecutive readings within 30 seconds, or the Threshold won’t act on them. If the sensor readings are especially spotty, this parameter will prevent the system from tying together data that’s too old to be properly related to the previous events.
Example: Runner A enters the “golden heart rate range” of 160 – 180 about 20 minutes into the race, and Threshold allows an event through, so his coach can be notified. Fifteen minutes later, Runner A charges up Cardiac Hill, and now his heart rate is higher, so Threshold again allows an event through which shows the higher reading. The coach can now advise the runner to pace himself; there’s a lot of course left. Runner A takes Coach’s advice and his heart rate drops back into the desired zone, and Threshold once again sends on the data.
Finally, the Missing activity pattern alerts if an expected event doesn’t arrive into the system within a specified duration of time. And here’s where our marathon racers example takes a dark turn…
Just kidding! No athletes were harmed in the making of this blog; I’m sure he’s fine, but his coach will be alerted after a minute of no readings, that the biometric sensor data on his runner has stopped working. We didn’t check the emitOnlyOnce box, so this event will repeat every minute, until the equipment starts working again, or the application stops.
The Takeaway: The patterns in the Filter category actively listen for events, and related conditions, of relevance and allow developers to fine-tune processing for any scenario the program might encounter.
Take full advantage of Filter activity patterns to send events to their proper real-time processing channels. With filters, developers can also discard non-relevant events, which removes unnecessary load from the system, thereby improving scalability and performance.
Take full advantage of Filters!
Attachments:
You must be
logged in to view attached files.
Developer ‘Tiqs & Tricks
September 2024
Filters for Fun & Profit
The Activity Patterns in the Filter category are “picky listeners” that speed up real-time responsiveness by only allowing events through for further processing if those messages are what they want to “hear.”
Developers set “what” for which each pattern is listening, but the “how” differentiates them from each other. There are four Activity Patterns in the Filter category:
We’ll start with the namesake pattern, and explain how each of the other patterns puts its own spin on how it’s listening for just the right event conditions.
Author’s Note: Any health metrics examples given below are for the purposes of explaining Filter patterns, nothing more. They are not intended to be medical advice!
Filters see events in “black and white”; something either is or it isn’t, full stop. With handy logic operators like AND (&&), NOT (!=) and OR (||), developers can fine-tune specific ranges of single or multiple properties to determine what should be admitted for further processing.
Example: Live biometric data is coming in from runners in a marathon. Our program checks for any pulse readings higher than 200, to alert the runner’s coach of a possible health issue.
One important thing to mention about Filters: Only one event is ever considered for this gateway. Filters don’t look for trends in a stream of events.
The Dwell pattern, in contrast to the Filter pattern, requires a stream of events for its gateway. The filtering condition must be true over a period of time before further processing will occur.
Example: Coaches want their runners pushing themselves hard, but not too hard. They’ve decided that the best heart rate range during the race is between 160 – 180 beats per minute, and they want to know when athletes stay in that range for at least three minutes. So they add a Dwell to the Visual Event Handler, to check for heart_rate < 181 && heart_rate > 160, for a duration of at least 3 minutes:
All well and good, but if the athlete’s heart rate
…Dwell won’t send any events through; once the condition is met once, Dwell sends that event, and no more.
Only if the heart rate re-enters the range for the 3 minutes would Dwell allow another event through.
Enter the Threshold pattern, which can listen for a events meeting a criteria, and also listen for when those events leave the criteria. Unlike Dwell, however, there’s no time lapse requirement. To explain this activity pattern better, here’s a Threshold configuration, and we’ll go over it means:
At the top, you see our one required parameter, which is the condition that the pattern should detect. No surprises there.
direction: This can be true, false, or both. If true, then Threshold works pretty much just like a Filter, sending on any event that meets the criteria. If false, then it will only send on events that don’t meet the criteria(!) But the beauty of this pattern is
by having both, which will send an event when the criteria is met, and one when the event falls out of the previously-met condition.
We’re not worried about the first heart rate reading of each athlete meeting the criteria, so we can safely ignore the initialStateFirstEvent and the initializeCondition evaluation parameters, but if we didn’t start collecting data until somewhere in the middle of the race, we’d want to set those so the threshold could record whether or not the events met the criteria from the get-go.
overConsecutiveReadings is very handy, especially if our sensor equipment is bumping along on a runner. In our case, the Threshold won’t send on an event unless either the racer’s heart rate measurement has stayed in the 160-180 range for 3 consecutive readings, or left that range for 3 consecutive readings.
withinDuration means that the system will need to see those three consecutive readings within 30 seconds, or the Threshold won’t act on them. If the sensor readings are especially spotty, this parameter will prevent the system from tying together data that’s too old to be properly related to the previous events.
Example: Runner A enters the “golden heart rate range” of 160 – 180 about 20 minutes into the race, and Threshold allows an event through, so his coach can be notified. Fifteen minutes later, Runner A charges up Cardiac Hill, and now his heart rate is higher, so Threshold again allows an event through which shows the higher reading. The coach can now advise the runner to pace himself; there’s a lot of course left. Runner A takes Coach’s advice and his heart rate drops back into the desired zone, and Threshold once again sends on the data.
Finally, the Missing activity pattern alerts if an expected event doesn’t arrive into the system within a specified duration of time. And here’s where our marathon racers example takes a dark turn…
Just kidding! No athletes were harmed in the making of this blog; I’m sure he’s fine, but his coach will be alerted after a minute of no readings, that the biometric sensor data on his runner has stopped working. We didn’t check the emitOnlyOnce box, so this event will repeat every minute, until the equipment starts working again, or the application stops.
The Takeaway: The patterns in the Filter category actively listen for events, and related conditions, of relevance and allow developers to fine-tune processing for any scenario the program might encounter.
Take full advantage of Filter activity patterns to send events to their proper real-time processing channels. With filters, developers can also discard non-relevant events, which removes unnecessary load from the system, thereby improving scalability and performance.
Take full advantage of Filters!
Attachments:
You must be logged in to view attached files.