[bug-4173, 4176]Alarming Custom Messages - Upgrading 7.x to 8.x

Ignition
,
1

Hey folks,

I ran into some unexpected lost time and frustration with the upgrade and custom alarm email messages. I didn’t see anything about it in the upgrade guides, so I wanted to share it here in case anyone else runs into the issue.

Basic Custom Message Formatting

The gist of it is that custom alarm messages are not required to be bound as expressions in 7.x, but 8.x requires it. With this comes a change in formatting, and these changes are not automatically resolved by the upgrade.

Details

I worked with IA tech support and briefly touched on the issue here. For anyone that referenced the 7.7-7.9 IU Alarming video “Custom Email, SMS, and Voice Scripts”, you may have followed the tutorial and written your custom message directly into the “custom message” box as follows:

At {eventTime|hh:mm:ss}, alarm "{name}" at "{displayPath}" transitioned to {eventState}.

In 8.x, the way Ignition is evaluating this message and passing it to the alarm pipeline has changed, and the message must now be an expression binding rather than typed straight into the box, and it must be formatted as a string and wrapped in quotes:

'At '+"{eventTime|hh:mm:ss}"+', alarm '+"{name}"+' at '+"{displayPath}"+' transitioned to '+"{eventState}"+'. '

Solution:

  • Copy the custom messages and reformat / wrap them with quotes as needed into an expression binding.

Associated Data named “value.”

Today I found that having associated data on an alarm named “value” will resolve initially but break in time, thereby breaking the custom message. Again, something developed in 7.x that does not work in 8.x

When adding associated data (say you wanted to show analog data related to the alarm), if you name that associated data “value,” you can bind it to a tag and it will evaluate. However, after cycling the tag provider (or presumably power), those bindings are broken and so are the custom messages they are associated with.

Details 
Value: {[~]Well/Level/Domestic_Level}

Custom Message:'At '+"{eventTime|hh:mm:ss}"+', alarm '+"{name}"+' at '+"{displayPath}"+' transitioned to '+"{eventState}"+': '+"{Value}"+" in."

Evaluates as: (Ignition Alarm Notification) At 03:38:10, alarm Domestic Water Low at Well transitioned to Active: 43 in.

After cycling the tag provider, the Value tag binding will become the following:

Value: [{     "bindType": "Tag",     "value": "[~]Well/Level/Domestic_Level" }, Good, Wed Aug 25 16:22:19 PDT 2021 (1629933739159)]

Though in the case of the gateway I was troubleshooting, all the bindings looked like this:

[, Good, Wed Aug 25 16:22:19 PDT 2021 (1629933739159)]

The custom message now evaluates as:

(Ignition Alarm Notification) At {eventTime|hh:mm:ss}, alarm {name} at {displayPath} transitioned to {eventState}:{Value} in.

Removing the quotes from around {Value} will evaluate as:

(Ignition Alarm Notification) At 03:38:10, alarm Domestic Water Low at Well transitioned to Active: true in

Which suggests to me that the value binding may looking at the value of the alarm, not the “Value” associated data.

Solution:

  • Manually changing the name of the “Value” associated data to something else (data, level, analog) and updating each binding seems to resolve the issue. With a large system, it can take quite a bit of time to get these functioning again.

If anyone has any insight or can add to this, I welcome the feedback.

2

I think I touch upon that in my list of v7 to v8 things here

3

I can’t promise timelines or indeed, whether anything about this will change, but I filed tickets so we can investigate this and see if we can change something.

1 Like
4

Sorry for the confusion, but we’ve just looked over the tickets, and here’s what we’ve found:

  1. It was never intentional that the format of CustomMessage should change. People have gotten confused between that setting of an alarm, which is a string template that is evaluated by the notification pipeline, and other concepts like bindings on tag properties. They’re not related, and it’s purely a mistake that CustomMessage with the 7.9 style string was being interpreted as an expression. The workaround works because it makes it a valid expression that… results in a string that is equivalent to what you would type in 7.

  2. A custom property on an alarm called “value” would essentially “shadow” the system property of that name (which is not so much a property, as a special keyword that can be used in alarm expressions). I would say that that should be allowed, and should always resolve to the custom property. It sounds like it’s doing that on creation, but not after reloading the tag.

We will prioritize both of these issues to get them resolved ASAP.

1 Like
5

Thank you Colby and Paul. I appreciate the quick response!

6

Does this mean that we can’t use expression language functions like the IF statement to do some complex evaluation of data in the CustomMessage field? For example, if we have a boolean alarm tag called “Out of Spec” and I want the custom message to show the correct word “High” or “Low” depending on an IF statement.

Example of super simple expression as the Custom Message on an Alarm
"Out of Spec " + if("{[.]Data}" > "{[.]Max}","High","Low") + " Alarm"

7

Hi Colby,

I’m working on another upgrade, version 8.1.15, and seem to be encountering the same issue.
I just want to make sure the issue is still present and should be remedied by replacing all alarm strings with expression bindings?

It appears as though strings written directly into the binding box work without being an expression, and the issue is in accessing the alarm properties.

8

I’ve edited this post with the hopes that removing my incorrect assessment will help avoid causing confusion for others.

9

Try:

"At "+{eventTime}+", alarm "+{name}+" at "+"{displayPath}"+" transitioned to "+"{eventState}"+": "+"{Temp}"+" F"

(change the rest as well. Might want to convert to a more standard temperature unit as well :grin:)

10

Thanks, Nick.

The issue I encountered appears to be that the use of alarmEvent.get('CustomEmailMessage') does not resolve all alarm properties that you would see in a pipeline. We’re on a dev environment without the ability to send emails, so I was using the above scripting to get the Custom Email Message, which I will not do moving forward.

Specifically {eventTime} and {eventState} evaluate to null or fail to evaluate, depending on whether the time formatting is included. I believe this is functioning as intended, but makes displaying the Custom Email Message in the client difficult.

These formats evaluate through an alarm pipeline and display the following results:

Not an expression binding, missing time formatting

At {eventTime}, alarm "{name}" at "{displayPath}" transitioned to {eventState}: {Temp} F

Email: At null, alarm "High Temperature" at "PLC" transitioned to null: 34.52 F

Client: At null, alarm "High Temperature" at "PLC" transitioned to null: 34.52 F

Not an expression binding, copied from 8.1 pipeline documentation

The "{name}" alarm became {eventState} at {eventTime|hh:mm:ss} with a value of "{Temp}"

Email: The "High Temperature" alarm became Active at 10:00:00 with a value of "34.52"

Client: The "{name}" alarm became {eventState} at {eventTime|hh:mm:ss} with a value of "{Temp}"

Expression binding

"At "+"{eventTime|hh:mm:ss}"+", alarm "+"{name}"+" at "+"{displayPath}"+" transitioned to "+"{eventState}"+": "+"{Temp}"+" F"

Email: At 10:00:00, alarm "High Temperature" at "PLC" transitioned to Active: 34.52

Client: At {eventTime|hh:mm:ss}, alarm {name} at {displayPath} transitioned to {eventState}: {Temp} F