[Bug-6178] Alarm {state} value isn't clear after clearing an alarm that was acknowledged

The code snippet below is my custom email message. The alarm is active when a Boolean is True.

Scenario 1:

  • Alarm bit is initially false
  • Set alarm bit true
  • {state} Email message says Active
  • Set the alarm bit false
  • {state} Email message says Clear

Scenario 2:

  • Alarm bit is initially false
  • Set alarm bit true
  • {state} Email message says Active
  • Acknowledge the alarm
  • {state} Email message says Ack
  • Set the alarm bit false
  • {state} Email message says Ack

Why doesn’t the value of {state} say Clear in Scenario 2???

Thank you.

{ad_PrefixMessage}
+ "\n" + {name}
+ "\n" + "Priority:  " + {priority}
+ "\n" + "Current State:  " + {State}
+ "\n" + "Ack'd By:  " + {ackUserName}
+ "\n" + "Active Duration:  " + {activeDuration}
+ "\n" + "Unack'd Duration:  " + {ackDuration}
+ "\n" + "Occured on " + dateFormat(now(0), "MMM d, h:mm a")
+ "\n" + {ad_SuffixMessage}

x

In scenario 2, how are you acknowledging the alarm? Is it through a Vision or Perspective alarm status table or are you using system.alarm.acknowledge? Are you shelving the alarm at any time during scenario 2? Could you also provide the Ignition version that you are using?

Perspective Alarm Status Table.
No,not shelving.
v8.1.17

Is it possible to get to the the IsAcked, IsActive and IsClear bool properties?
I’ve tried {name.isClear} but it doesn’t work (Expression doesn’t like it)

Strange that {state} isn’t providing the entire state as it should. I will write up an issue to get that resolved internally. However, going by the notification block documentation you should be able to utilize the bool properties using the format: {isClear} {isActive} or {isAcked}

@osolorzano

Test Sequence # 1 Using Custom Email Message - the bool properties from the custom message don’t change but do change (as you’d expect) in the tag browser.

"isActive = " + {isActive}
+ "\n" + "isAcked = "  + {isAcked}
+ "\n" + "isClear = "  + {isClear}
  • Alarm bit is initially false
  • Set alarm bit true
  • {state} Email message says Active
  • {isActive} is false
  • {isAcked} is true
  • {isClear} is true
  • Acknowledge the alarm
  • {state} Email message says Ack
  • {isActive} is false
  • {isAcked} is true
  • {isClear} is true
  • Set the alarm bit false
  • {state} Email message says Ack
  • {isActive} is false
  • {isAcked} is true
  • {isClear} is true

Thanks. Those properties in the notification block work, but not in the custom email message. The {eventState} in the notification block works correctly. I had to shift strategies for alarming…really want to use the customer messages because I can script (Expression) logic into the messages and use associated data but without an accurate state or {is…} property values I can’t. Its as thought the custom message get fired off to the notification block before all the alarm properties are updated.

Why is the notification blocks message syntax (just text and properties) not an Expression like the custom message and both have different sets of parameters to use? Perhaps I’m missing something but it seems a improvement could be made.

Thanks for the help. Will I be notified when the state issue in the custom message is fixed?
Regards,
Ted.

You are right, I was able to reproduce your issue on my end using the custom email message. The state property needs to be updated to show the full state, the {is…} properties just don’t look like they are working at all. I’ve added these notes to the internal ticket.
Once this bug is resolved we will put a message here on this post, otherwise it will show up in the nightly change logs with the number 6178.

1 Like

@osolorzano
Please have a look at Dynamic Alarm Enable and Pipeline Issues (v8.1.17)
I believe both of these are related.
Regards,
Ted.