Alarm Retransmission

[markhotch]

Hi All!

So we are developing a piece of software that will take alarms from StruxureWare systems and push the alarm data to the cloud for aggregation and analysis.

I have implemented the EwsClient from SmartConnector and we are polling our Enterprise Server every second for new alarms.  We are picking the alarms up using the "GetUpdatedAlarmEvents" method without issue, however, the data that we get back is sometimes duplicated.

What we have found is that if an Alarm is Active for more than 24 hours, the alarm is regenerated and passed back out of the "GetUpdatedAlarmEvents" method.  This means that we are taking the same data twice.  I have contacted Product Support to see if this is a mechanism of StruxureWare, which they have confirmed it is not.

Has anyone else experienced anything similar?

Thanks in advance!

[sesa180908_brid]

Mark,

I don't think we've done any testing with these particular constraints but we certainly can add that to some interop testing we have upcoming with SBO 1.9.  There is certainly nothing that an EWS client could do, using SmartConnector's EwsClient library or not, to cause this.

I'm curious though.  What exactly did PS say?  That this wasn't something that SBO did or SBO EWS Server did?

Also, was the duplicated "AlarmEventsType" that was returned the exact same - property for property?

[markhotch]

Hi Mark,

I will check what PSS actually said as this was raised by someone in our UK bureau originally.

In terms of the actual alarm that is retransmitted, it appears to be the exact same, with the same Timestamps etc, however, I am trying to find a way of capturing the data when it gets polled so that I can check the Guid of the alarm to see if it is the same...

I will keep you posted.

Thanks!

[markhotch]

Hi Mark,

I have been doing a bit of testing this morning which has involved setting up a quick C# forms app and downloading the EwsClient dlls from the SmartConnector NuGet library.

I have managed to implement both the GetAlarmEvents method and the GetUpdatedAlarmEvents method.  Following these steps seems to re-create my issue:

1.  Trigger an Alarm in an AS

2.  Run "GetAlarmEvents" to retrieve the alarm initially along with the GUID that is needed for the GetUpdatedAlarmEvents method.

3.  Manually forward the AS time by 23 Hours and 59 Minutes

4.  Wait a minute

5.  Run "GetUpdatedAlarmEvents" passing in the guid from step 2.

When the result returns, I get the exact same alarm again.  I have pasted these below...

Initial GetAlarmEvents request

/Server 1/Servers/Automation Server|/Server 1/Servers/Automation Server/Alarms/Fan Fail Change of State Alarm|874d19b1-6610-4485-8315-a0ec8852dafb

02/Server 1/Servers/Automation Server/Alarms/Fan Fail Change of State Alarm

Fan Fail Change of State Alarm

1

10/10/2016 09:33

10/10/2016 09:33

5

1

Fan Failed

GetUpdatedAlarmEvents request (after time forwarded)

/Server 1/Servers/Automation Server|/Server 1/Servers/Automation Server/Alarms/Fan Fail Change of State Alarm|874d19b1-6610-4485-8315-a0ec8852dafb

02/Server 1/Servers/Automation Server/Alarms/Fan Fail Change of State Alarm

Fan Fail Change of State Alarm

1

10/10/2016 09:33

10/10/2016 09:33

5

1

Fan Failed

I can share my Test App if you want to check this for yourself?

Hope this helps and as always, thanks for your time 🙂

[sesa180908_brid]

Mark,

This definitely sounds like an issue with the server.  Was the EWS server an ES or an AS; and what was the version?

[markhotch]

Hi Mark,

I have seen this on SBO 1.7.1 and 1.8.1 and it seems to happen when I poll the ES for alarms that exist within a connected AS.  (I.e. the Alarm Point and Alarm Object exist within the AS).

Thanks!

[Mike_Bielby]

Mark,

Did you ever get a resolution to this issue?

[sesa180908_brid]

It’s an SBO issue.

[Benji]

Well, that's being debated isn't it 😉

[Adam_Summers]

Hi Mike,

I've just forwarded you the correspondence on the ticket (REF: 00DA0abSm._50012ckdha), it was confirmed by Ulf Magnusson as a bug and I was told it would be be fixed with 1.9 - which means unfortunately for those using SBO prior to 1.9 the issue will remain and we have to work around by caching alarms in client side apps to detect duplication.