Notification - Alarms stick in pipeline when tag is modified

there is a little problem with the alarm notification module in 7.6.4. An active pipeline is not removed when the alarm conditions in the tag are changed.

I can be reproduce this in a memory tag with an ‘above setpoint’ alarm.
When the setpoint is changed below the actual value, the alarm gets active and a notification pipeline is created.
When the alarm setpoint is changed back to a higer value, the alarm is correctly cleared, but the pipeline stays active.
For every setpoint change, a new pipeline is created. While setting up and testing a notification today, i ended up with about 25 active pipelines before i realized the problem.

Are you still experiencing this issue?

Are you using redundancy?

Yes, this is still reproducable in 7.6.6.

I am not using redundancy.

I am trying to replicate this issue here without much success. How do you have your pipeline configured?
When you say “every setpoint change”, are you bringing the tag back into an alarm state and then taking it back out?

The closest I came to reproducing this is by using a delay block and triggering the alarm by changing the setpoint. In doing this I was able to create many pipelines based off a single alarm. Once the alarm was out of the delay block it would fall out of the pipeline.

I’m doing the same but see a different behaviour.
When i change the setpoint in the alarm configuration above the current value, the alarm is triggered, but no pipeline is created. I have to change the value below and the back above the new setpoint to create a pipeline.
When the alarm is active and a pipeline is running, i change the setpoint below the current value. The alarm is immediately cleared, bur the pipeline stays active until i cancel it on the gateway’s web page.

Here is my setup:

and a screenshot of the pipeline status:

So what you are saying is the alarm stays in the pipeline for more than the 1 minuted delay? Or are the alarms dropping out after 1 minute?

The alarms stay there forever, they are not dropping out when the delay expires.

I am not able to reproduce this issue here, can you call tech support so someone can take a look at the issue?

I’m seeing exactly the same behaviour with our 7.6.4 system, where if tags are edited the alarm gets stuck in the pipeline and the only way to clear it is to stop the gateway and delete the .Alarms file.

Was there any resolution to this?

Should I upgrade to 7.6.6?