Unacknowledged alarms which are overwritten keep flashing

[sesa145614_brid]

I created AlarmItem by using EwsServerDataAdapter.AddAlarmItem with mode AlarmTransitionModel.SingleAcknowledgeRequirement.

By calling ActivateAlarmItem, I can see the alarm in SBO Alarms window. Then this AlarmItem is cleared by calling ResetAlarmItem. The same AlarmItem is activated again without acknowledged manually. On the SBO Alarms window, I can see the row keeps flashing with green then red.

I am not sure that I saw this before I upgraded SmartConnector to V2.2.108 or not. Is there any way that I can prevent this happening?

Thanks!

[JeffBowman]

Hi Juh,

I am not 100% what are mean, originally when the Alarm is triggered, what is it doing in SBO? Is it flashing red and green? Or is it just red. When it is reset, how does it show in SBO, then after it is triggered again you said it flashes red and green?

If you actually want the AlarmEvent to be cleared when the ResetAlarmItem the "AlarmTransitionModel" should be different, I think maybe "SimpleSystemAlarm" is what you want? But I would need to verify.

However, most likely this is SBO's behavior,  but if there is an AlarmItem, SBO actually allows you to customize the behavior of the Alarms (Even supply custom messages). In SBO, Host the actual SmartConnector AlarmItem in your database. From there find it and select it, you will be presented with a bunch of tabs that allow for Alarm Customization. Keep in mind, all of these customizations are on the SBO side ONLY, but you should be able to tell it not to blink.

-Jeff

[sesa145614_brid]

Hi Jeff,

When the Alarm is triggered, the SBO shows red only. When it is reset, it becomes green. I keep the green there without clicking on the Ack button then trigger the same Alarm, it shows green then red and stay on red. At this monent, I cannot do the Ack because the green will be overwritten by the red immediately.

I would perfer that user can do Ack if there is no new Alarm coming. If new Alarm comes and the old is not Ack then I can do the Ack by calling function from program. Is this doable?

Following is the code I am handling the Activate Alarm:

if (ai.State == EwsAlarmStateEnum.Active)

     adapter.ResetAlarmItem(ai, "Reset", at, 50);

adapter.ActivateAlarmItem(ai, alarmMessage, at, 100);

Thanks!

Juh

[sesa180908_brid]

Juh,

You might want to review the state transition models depicted in the EWS Specification (available at https://www.smartconnectorserver.com/DownloadCenter/Contents/ews).  Specifically section 4.6.1. 

Perhaps there is a different model that would better meet your purposes?

[sesa145614_brid]

Hi Mark,

After reviewing all 5 State Transition Models, I still cannot find the one to fit my requirement. Do you have any suggestions?

Thanks!

Juh

[JeffBowman]

Hi Juh,

I think I now have a better understanding of what you are asking for.

Please let me know if this isn't the case:

It seems you want to "Force" the acknowledgement of alarms, even if the alarm is reset and re-triggered before the user acknowledges the first one. The only reason I could think of why you would want to do this is because you are using the same AlarmItem for multiple different alarms.

If this is the case, may I suggest to make different AlarmItems per alarm that you want the SBO user to see. So they are handled separately and not in the same "line item".

The way SingleAcknowledgement Works (in SC and SBO is)

- Alarm is triggered (Red in SBO, Alarm State is Active in SC)

- Alarm is reset (Green in SBO, Alarm State is Reset in SC)

- Alarm is Triggered (Red in SBO, Alarm State is Active in SC)

- Alarm is Acknowledged (Yellow in SBO, Alarm State is Acknowledged in SC)

- Alarm is reset (Disappears from SBO, Alarm State is Normal in SC)

- Alarm is Triggered (Red in SBO, Alarm State is Active in SC)

- Alarm is Reset (Green in SBO, Alarm State is Reset in Sc)

- Alarm is Acknowledged (Disappears from SBO, Alarm State is Normal in SC)

Never can multiple "states" of the Alarm be visible at once (e.g. in multiple "line item"), because this is not the way alarms work in SBO. Whereas in Continuum you could have Alarms show a new "line item" per state and perhaps do what you are trying to do, in SBO (and EWS by extension) they are always combined into a single "line Item". In order to show these all at once, you will need to use multiple AlarmItems.

Regards,

-Jeff

[sesa197614_brid]

Hi Juh:

I am not sure where and how you handle with you code:

"if (ai.State == EwsAlarmStateEnum.Active)

     adapter.ResetAlarmItem(ai, "Reset", at, 50);"

If you are running these codes at every looping without any pre-condition, it will absolutely try to reset the alarmItem if it is active every time, you may add some logs to track when it happens and try to avoid it.

For my experience, i will always deal with the alarm acknowledgement by overriding functions in MongooseAcknowledgeAlarmEventsProcessor.

Wish this help you.

---Austen

[sesa145614_brid]

Hi,

I am trying to use the following code to handle the alarm to ensure that before activating the new one that the previous one is Reset->Ack or Ack->Reset and then deleted.

var ai = adapter.AlarmItems.FirstOrDefault(a => a.ValueItem.Id == vi.Id);

if (ai.State == EwsAlarmStateEnum.Active)

{

    EwsAlarmItem ret = adapter.ResetAlarmItem(ai, "Reset", at, 100);

       ret = adapter.AcknowledgeAlarmItem(ai, "Acknowledged", at, 100);

      adapter.DeleteAlarmEvents(ai);

}

else if (ai.State == EwsAlarmStateEnum.Reset)

{

       ret = adapter.AcknowledgeAlarmItem(ai, "Acknowledged", at, 100);

      adapter.DeleteAlarmEvents(ai);

}

else if (ai.State == EwsAlarmStateEnum.Acknowledged)

{

    EwsAlarmItem ret = adapter.ResetAlarmItem(ai, "Reset", at, 100);

      adapter.DeleteAlarmEvents(ai);

}

adapter.ActivateAlarmItem(ai, alarmMessage, at, 100);

And use the following code to handle Reset:

if (ai.State == EwsAlarmStateEnum.Active || EwsAlarmStateEnum.Acknowledged)

     adapter.ResetAlarmItem(ai, message, at, 100);

Somehow I still can see the the flushing.

Dose anyone have any though that what is missing?

Thanks!

Juh

[JeffBowman]

Hi Juh,

I think in order to help you with this, I need a better understanding of your use case.  I am not sure what you mean by 'flushing'.

In any case, if you want to completely handle the alarm state flow on your own, make sure when you create your EwsAlarmItem that you configure it with the 'Unrestricted' transition model. This SHOULD allow you to reset it and set it back to normal. If the transition model is set to another one, the AlarmEvent expects to be handled in a certain way (as the transition modeel expects)

That said, I am not sure why you are 'deleting' alarm events. These are historical events and I am not sure I understand the benefit of deleting them from your database completely. If you want them to go away, set them to 'Normal' and that should effectively 'make them go away'.

Regards,

-Jeff

[sesa145614_brid]

Hi Jeff,

I have removed the line:  adapter.DeleteAlarmEvents(ai); and follow your suggestion to add Thread.Sleep(100) before the

ActivateAlarmItem. The problem still exists.

Based on my investigation, I find that when the alarm is reset by clicking on the Clear button (setting the binding valueItem to 0), I change the message by adding "cleared" then at this moment the flashing happens.

Any idea?

Thanks!

Juh

[JeffBowman]

Hi Juh,

This seems weird, because this looks like it is standard behavior for an alarm.. going from Alarm to Reset..

Your best bet may be to use a different Transition model that doesn't use Reset. If that is the case, simply implement the alarms with a type transition model of 'Simple System Alarm'. That way, it would either be 'Normal' or 'Alarm', but never another state.

If you do need it to be acknowledged, you could implement it with an transition model of 'Alarm with Optional Acknowledgement'.

There is still a chance something is weird with your EWS response though. Can you post a partial log of the Ews.Server logging when this happens?

Regards,

-Jeff