Alert notification groups

The high isn’t a problem- that’s a “register” message so that the correct state shows up in the status system.

Ok, so that all looks correct, unless I’m missing something about the time. Since you were the one changing the values, do the messages seem to line up with what you were doing? I see the last three were about 5 seconds apart- is this accurate?

I’m still not exactly clear on what the problem is we’re trying to track down: that the email messages are off state, or that the current status properties aren’t updated quickly?

Regards,

yeah everything seems to line up time wise.

Maybe I am going about this wrong. My thinking was that the State_Name would go low when a low alarm was active, and then go back to blank when the alarm cleared. Maybe I should use the alarm_type in conjunction with the state_name???

Ok, so talking purely about the email message (and not the properties under the tag), you’re unsure why STATE_NAME is not empty when the alarm is clear, right?

In that case, you’re correct in your last message that you should incorporate ALARM_TYPE into your message. When the email is created, the perspective is not “Here’s the current state”, but instead “Here’s what happened to a state”.

So, say the tag was in the low state range, and you changed the value into something in the high state range. You’ll see two events generated, a clear for the low (“Low state cleared”) and an active message (“High state active”).

Most custom messages are something like the following:

At {[TIME]}, {[STATE_NAME]} became {[ALARM_TYPE]} for {[DISPLAY_PATH]}

Let me know if I’m still off track!

Regards,

Yeah I understand better now. Makes sense now, I guess I was under the impression that the state_name would follow what is in the .alertcurrentstate of the tag. regardless, I feel stupid!