Understanding state change direction

Understanding the direction of state changes is important because it has an effect on whether notifications are triggered. Nobody wants to set up an alarm that they think will result in notification under certain conditions, only to find out later that the alarm occurred yet no notification was received. To illustrate how this scenario could happen, and learn how to work around it, consider the following range state configuration on a number point:

Before we start considering state changes, let's quickly digress to make a point about the position of a "NORMAL" state. In the above example, the "NORMAL" state happens to be centered on a value of 0. However, this is not required, and not appropriate in all cases. Consider the example of monitoring a commercial food freezer, where the desired temperature might be between -25°C and -18°C, so this is defined as the "NORMAL" range. Any value below -25°C might be labeled "LOW" and indicate an incorrect calibration of the freezer. A value range between -18°C and -0°C might be labeled "HIGH" and also indicate an incorrect calibration of the freezer, while any value above -0°C might be considered "FAULT", meaning your freezer has broken down completely. Note that a state higher than "NORMAL" can still be below 0. Be sure to drag the "NORMAL" state into the correct position when configuring your own parameters.

Back to our original example, and time for a short test: how many different state changes are possible with the 5 states shown in the above configuration?

• 8

• 12

• 16

• 20

• 24

   

The correct answer is 20. Of those, 14 are in a direction "away from normal", while 6 are in a direction "towards normal".

A couple of points to note:

• A state change doesn't need to finish in the "NORMAL" state to be considered "towards normal"

• A state change could finish "closer" to normal than where it started (for example the "VERY HIGH" to "LOW" state change), but still be considered "away from normal"

That second point can seem counter-intuitive, but it helps to remember the following rule: if, after a state change to a non-normal state, you kept going in the same direction, would the next state take you further from normal than you currently are? If so, the direction of the state change is "away from normal". For example, if, after the state change from "VERY HIGH" to "LOW", you kept going in the same direction, the next state would be "VERY LOW", which would take your further from normal than the "LOW" state where you currently are.

So, how does the state change direction affect notifications? Lets review the 6 "towards normal" state changes, this time graphically:

With this in mind, it's time for the key piece of information that we've been building to:

Entering a state in a "towards normal" direction will not trigger a notification.

This applies even if you think you have configured an alarm with notifications on your state! Now, of the 6 state changes shown above by the green arrows, of course we don't expect the 4 which end in the "NORMAL" state to trigger an alarm. After all, there is no mention of an alarm being raised in the text box of the "NORMAL" state, and it even says "Notifications will not be sent".

But what about the other 2 states? Lets look at them in the table again:

If we go from "VERY HIGH" to "HIGH", the state is not considered active. The key is the first statement inside the text box of the "HIGH" state: "State will be active when level increases to 10." The key word here is increases. Going from "VERY HIGH" to "HIGH" is a decrease, not an increase, so the state will not be active, and notifications will not be sent. This is true even though the alarm has been raised, as shown in the eagle.io UI:

The same principle applies if we go from "VERY LOW" to "LOW"; the state is not considered active. The text box for the "LOW" state says "State will be active when level decreases to -10", but going from "VERY LOW" to "LOW" is an increase, not a decrease, so the state will not be active, and notifications will not be sent.

In both these examples, the text box contains the statement "Notifications will be sent to Maintenance category when state becomes Active". This is another way of saying that unless the state becomes active, notifications are not sent. And as we have seen, a state change can raise an alarm without the state being considered active.

Right at the top of the article, there was a mention of how to work around this. Even though the new state is not considered active when the direction of the state change is "towards normal", we can trigger notifications based on leaving the previous state. For example, we can set the Notifications of the "VERY HIGH" state to be "Active or Inactive":

This way, if we go from "VERY HIGH" to "HIGH", even though the "HIGH" state is not considered active and will not trigger notifications, the "VERY HIGH" state is now considered inactive, which will trigger notifications. Once again, the text box tells the story: "State will become inactive when level decreases below 20. Notifications will be sent to Maintenance category when state become Active or Inactive."

In conclusion, by understanding the concepts involved, you can have confidence that the configuration you apply to your states will result in the desired notifications!