Updating configchange of sqlt_core generating alarms

As you may have seen in my previous posts, I am implementing two ‘analog’ alarms for a single digital tag, one for 0 and one for 1.

Now, if the tag has a value of 1, it is in the alarm state defined by the alert entry in sqlt_as with high=1 and low=1 (both inclusive). When I run the query to update the configuration for this tag (UPDATE sqlt_core SET configchange = CURRENT_TIMESTAMP where id = 36), I see that a new alarm is generated, but sometimes two alarms are generated, and this isn’t the behavior I am looking for since this will send out two notifications to anyone in the distribution list. I have verified this using the MySQL query analyzer to update the sqlt_core configchange field and the problem still exists.

Is there any way to prevent this from happening?

The first alert occurs because the tag gets reloaded - essentially it’s a new tag, so it gets evaluated, and the alert is generated. The second alert… unfortunately is a bit of an undesired artifact of the sqltags system. The problem is that there is a tendency to load tags multiple times (caused by a variety of things, one example being that mysql doesn’t support milliseconds, other being that it’s the safe route- the opposite would be that a tag might never get loaded), so the whole thing happens again.

As it relates to notifications, you should be able to prevent it from being sent by deselecting “Send email for initial state” under the Alert Settings in FactorySQL. It won’t help with the log, but at least you won’t be annoying people with too many emails.

I’ll enter a bug ticket to take another look and see what we can do to prevent or deal with the double loading.