Need Help? Talk to a specialist: 1-630-543-3747
ACT FAST! Beat the price increase and save on Chart Recorders, Charts, and Pens when you purchase by January 1.

DicksonOne | Logic of Alarm and Alarm Delay Timing

Logic of Alarm and Alarm Delay Timing

We're often asked why do I still see the orange alarm bar or why haven't I received an all clear email/text/call when it appears that the logger has returned to normal (based on the most recent measurement being "good").

Below is an example of an alarm and the logic we use to move an alarm into different phases. 

Assuming a 5 minute alarm delay, the alarm would work as follows:

Step 1
12:00: A datapoint is received that has an undesirable value. This puts the alarm into a 'triggered' state. Users are not notified in a trigger state.

Step 2
12:03: A datapoint is received that has an undesirable value. The alarm remains in a 'triggered' state. Users are not notified in a trigger state.

Step 3
12:06: A datapoint is received that has an undesirable value. This puts the alarm into an 'alarm sent' state (and sends any configured notifications of an alarm). The orange bar appears in DicksonOne interface.

Step 4
12:09: A datapoint is received that has an ok value. This puts the alarm in a 'alarm sent and trending normal' state. 

Step 5
12:12: A datapoint is received that has an ok value. The alarm remains in 'alarm sent and trending normal' (it's only been 3 minutes since the first good datapoint)

Step 6
12:15: A datapoint is received that has an ok value. This puts the alarm in a normal state (it's now been 6 minutes of having only good data points). The orange bar in D1 disappears.

A Few Additional Notes About the Logic

If an alarm is in "triggered" and receives a good datapoint, it goes back to normal because it hasn't exceeded the alarm delay duration.

If an alarm is in the "alarm sent and trending normal" state and receives a bad datapoint, it goes back to "alarm set"

If the alarm delay is zero, it passes through "triggered" state to the "alarm sent" state, and it also passes through the "alarm sent and trending normal" state directly to "normal". This means you'll see a lot more notifications if the datapoint values are hovering around the alarm boundary.

Last, with regard to the alarm delay, the timer on the delay resets each time the alarm changes state. Steps 1 and 4 restart the "delay clock" in this example. If you have a particularly large alarm delay, half hour to an hour, this means it can take a full hour for your alarm to return to normal despite having  received "good"data points. 
Why do we restart the alarm delay clock when something changes states? 
DicksonOne customers are concerned about excursions. As such, we err on the side of providing more information (including alarms) than less. 

Logically, however, it also makes sense. Consider an alarm delay of an hour. Say your alarm is triggered because it has been outside of the safe zone for more than an hour. If you start receiving data within the safe zone, but within an hour time frame, this is good, but it means there hasn't been a cumulative hour of good points. This effectively violates the alarm delay again (for more than an hour we've received bad points, so it takes at least an hour of good points to be in good standing with your alarm delay).

This also prevents a false sense of security in the scenario where you have an hour of bad data, one minute of good data, and then another hour of bad data. If we said that a single data point could reset the alarm (with an hour alarm delay) then in this scenario you wouldn't necessarily know about the second hour of bad readings even though it violates your safe conditions.