Chained alarm property bindings causing error logged from alarm.Execution.BoundProperties

Ignition
1

We recently had a lot of error messages showing up in our Ignition logs from alarm.Execution.BoundProperties saying “Error executing bound property.” and “java.lang.NullPointerException: null” That is the entirety of the error message. We tracked it down to some of our alarm configs which use a custom message expression binding. After fiddling some more, I’ve discovered that I can recreate this issue with the following setup:

  • Setup a tag with a valid “Documentation” property string
  • Configure the alarm “label” property to be an expression which references the tag “Documentation” property
  • Configure the alarm custom message property to be an expression which references the alarm “Label” property

The error occurs in the logs as Ignition saves/updates the alarm config.

The actual message generated when the alarm event happens looks correct, and includes the documentation string in the proper place, so this doesn’t appear to be affecting functionality, but all the messages in the log at “ERROR” level are concerning.

I was seeing this on Ignition 8.0.12.

2

And of course today when I went back to experimenting with this some more, I can’t cause it to happen again… I’m going to keep experimenting and see what I can figure out.

3

Okay. I can reliably recreate this again. Here’s the exact setup I just used to cause it:

  1. Create a simple tag (I’m making [default]sandbox/scratch in my example), and change the documentation property to test string
  2. Add an alarm on that tag, and change the label property to an expression binding of {[.]scratch.Documentation}
  3. Edit the custom email message property of the alarm, and set it to an expression binding of "A: "+{label}

The error message doesn’t appear if there is no constant string in the message’s expression. In other words, if I set the message expression to just {label} it doesn’t complain. It needs the "A: "+ preceding it…

4

Since everything appeared to be working fine, even with the error, I decided to put the new alarm config into use on all the relevant tags and ignore that error message in the logs for now. And after the initial wave, it stopped reoccurring if I re-touch the same alarm config again?

I’m now suspicious that it has something to do with a combination of the prior and current alarm configs or possibly the active/unacked alarm events on the tags being modified, but I’m no longer pushing to investigate since my server seems to have gotten past this and the logs have quieted down…