where this is all going wrong is with the clear message. so when the operator goes to site to restart the generator, the site comes back online, my "node online" tag gets a value of 1, and then the system sends THE EXACT SAME MESSAGE for a clear state
here's the clear message from this most recent alarm
what i did find when trying to use values attached to the alarm itself (like {label} and {display path} is that the label won't update even if it's bound to a tag value, which is why you'll see me using the tag value in my custom message expression. but it seems that for the clear message, this expression isn't executed prior to sending the clear message.
how am i supposed to have a proper clear message for this alarm without having to create ANOTHER alarm that has an alarm state of 1 and sends the online message? surely this isn't a limitation.
why would the timestamp on the clear message be the same as the active message? and why would the message not update with the new value? help pls.
A couple of questions for clarification:
• This tag lives in an ignition tag provider?
• What generates the 10 minute delay before the initial text message? Is it a tag change script?
• What generates the follow up text message? Is it the same 10 minute delay for boolean tag change?
the tag lives in the default tag provider for the project. it is a boolean reference tag to the MQTT Engine
the 10 minute delay is part of the alarm configuration on the tag itself. you have set and clear delays and i put 600 seconds so as not to flag on loss of comms due to modem keepalive, or edge device issues. i figured 10 minutes of persistence would be adequate for this alarm (and it has been)
i have a 60 second delay on clear (meaning a flicker wouldn't cause a clear)
i'm not doing anything with tag change scripting in this case, only with alarm configuration on the tag itself.
i have not. i have no idea why the clear statement would publish with an old timestamp (sometimes days old), and with an old tag value.
i'm completely befuddled at this point. no clue how to fix it aside from getting rid of the clear message to prevent confusion, but that's the least desirable outcome here.
ok i have done some more testing, and it seems to me that this has to do with acknowledgement.
the way the alarms work is when they're active it will use a pipeline that sends up to 4 text messages at timed intervals before sending an email at the end of the thread
the clear pipeline is a single text message. both pipelines use the same custom message (which should update)
here's where it goes sideways. if i trigger the alarm, and acknowledge the alarm, the clear message shows the same time stamp and tag value as the active alarm does. here's an example
you can see the alarm come in, i acknowledge, then on clear it sends the same timestamp and value.
but if i do not acknowledge the alarm, i get this.
why would the acknowledgement of an active alarm screw up the clear message?
here is how the pipelines are configured
the active pipeline
i tried it with cleared set as a dropout, but that shouldn't matter as it gets cleared by the acknowledgement
and the cleared pipeline
if i check off acknowledged on the clear pipeline, it won't send a cleared message when the alarm clears as the acknowledgement on the active pipeline will clear it.
so it seems that dropping out the active pipeline by acknowledgement ruins the clear message. can anyone reproduce this? it seems outrageous to me that a cleared message will be the same as an active message ONLY if the active alarm has been acknowledged....
finally, if i make the active pipeline the same as the clear pipeline (simple single text with out acknowledgement) everything works as expected. so it is ONLY the acknowledgement that is screwing up the cleared messages.
i'm not sure if anyone is following, but what this appears to be is a bug.
what seems to be happening is that none of the properties in the alarm configuration of the tag are reassessed on clear, if the alarm is acknowledged. so you won't get any updated values if you have bindings to alarm properties on volatile values.
unfortunately the only workaround that i could do for this issue is to scrap any idea of individual tag values and just use generic alarming messages, which is sub-optimal but will get me by until ignition fixes the issue.
there was a ticket open for the display path not updating, however we revealed that all properties are not reassessed in this bug, including expressions for custom messages.
i believe that the ticket has been updated, but posted it here merely to inform others if they were having the same issues i was.
