dpQueryConnectSingle SELECT ALERT Query

[emaddocks]

Hi,

I'm running a dpQueryConnectSingle for the following query "SELECT ALERT '_alert_hdl.._direction', '_alert_hdl.._act_state', '_alert_hdl.._act_state_prior', '_alert_hdl.._act_state_color', '_alert_hdl.._ack_user' FROM '*.alarm.*'" which gets all the alerts from my devices.

When an alert changes state I get the updated _act_state value come through however when I acknowledge the alert the same _act_state value comes through. So I get 1 come through twice for 'CAME unacknowledged'

Can anyone tell me if this is meant to happen or why it would be happening? I would have expected a value of 2 to come through once the alert is acknowledged.


From the help file _act_state values are:

1 = CAME unacknowledged (Active Unacknowledged alarms)
2 = CAME acknowledged (Active Acknowledged alarms)
3 = WENT unacknowledged (Clear Unacknowledged alarms)
4 = CAME/WENT/unacknowledged (Clear Unacknowledged alarms in case of double ack required)
0 = No alert


Thanks
Eric

[adaneau]

Hi Eric,

How are you doing your ack?

If you make a custom one, this could be the reason.

BR
Alexandre

[emaddocks]

Hi Alexandre,

I've tested it from the para and also using the alertSet function with DPATTR_ACKTYPE_SINGLE. Both give me the same response:


WCCOActrl2: 1: dyn_anytype 7 items
WCCOActrl2: 1: (Type: 0 Sys: 0 Dp: 0 El: 0 : 0..0)
WCCOActrl2: 2: (Type: 0 Sys: 0 Dp: 0 El: 0 : 0..0)
WCCOActrl2: 3: :_alert_hdl.._direction (Type: 0 Sys: 0 Dp: 0 El: 0 : _alert_hdl.._direction)
WCCOActrl2: 4: :_alert_hdl.._act_state (Type: 0 Sys: 0 Dp: 0 El: 0 : _alert_hdl.._act_state)
WCCOActrl2: 5: :_alert_hdl.._act_state_prior (Type: 0 Sys: 0 Dp: 0 El: 0 : _alert_hdl.._act_state_prior)
WCCOActrl2: 6: :_alert_hdl.._act_state_color (Type: 0 Sys: 0 Dp: 0 El: 0 : _alert_hdl.._act_state_color)
WCCOActrl2: 7: :_alert_hdl.._ack_user (Type: 0 Sys: 0 Dp: 0 El: 0 : _alert_hdl.._ack_user)
WCCOActrl2: 2: dyn_anytype 7 items
WCCOActrl2: 1: DATAPOINT (Type: 236 Sys: 1 Dp: 1061 El: 23 : 0..0)
WCCOActrl2: 2: 2018.10.03 07:49:24.179 (0 ) DATAPOINT:_alert_hdl (Type: 236 Sys: 1 Dp: 1061 El: 23 : _alert_hdl..0)
WCCOActrl2: 3: TRUE
WCCOActrl2: 4: 1
WCCOActrl2: 5: 83
WCCOActrl2: 6: "alertCamUna"
WCCOActrl2: 7: 0


Is there another way to acknowledge alerts through scripting?

Cheers
Eric

[leoknipp]

According to the information in the WinCC OA Documentation the _alert_hdl.._act* attributes shall not be used for a dpQueryConnect*.
The _act* attributes can be used at a dpGet() or dpConnect().

Best Regards
Leopold Knipp
Senior Support Specialist

[emaddocks]

Hi Leopold,

It's a shame that you can't get accurate _alert_hdl.._act* values from a dpQueryConnect function.

How do you recommend getting the latest _alert_hdl.._act* values in 'real time'? As the dpGet and dpConnect functions are only run when you trigger them how do you get the Event Manager to notify you of Acknowledged alarms? This must happen on Alarm Summary pages as part of WinCC OA so we'd like to replicate that functionality.


Cheers
Eric

[leoknipp]

The AEScreen also is using the _ack* attributes at a dpQueryConnectSingle() to show the current state of the alerts.
Probably it works by connecting to the _ack_state and _direction attribute. If this information is combined you will get the information for the current state of an alert.

Best Regards
Leopold Knipp
Senior Support Specialist

[emaddocks]

Hi Leopold,

I've found a different resolution using dpConnects as you previously suggested. I've used:

dpConnectUserData("updateAlarmCount", index, alerts[j] + ".._act_state");

This returns the correct '_act_state' value when the user acknowledges the alarm. I wasn't able to use the combination of '_ack_state' and '_direction' as these two values did not change when the user acknowledges the alarm (see my previous post).

My only concern now is that the amount of dpConnects i'm creating is around 5 thousand! It seems to work fine but is there a limitation on the amount of connections the Event Manager can handle?


Cheers
Eric

[leoknipp]

Have you tried to use a dpQueryConnectSingle() with SELECT '_alert_hdl.._act_state'?
I did not test it but probably you will get the same result as when doing a dpConnect.

Doing 5.000 dpConnects() should not be a problem.
More interesting is how often the values/attributes will change which you have connected.

Best Regards
Leopold Knipp
Senior Support Specialist

[emaddocks]

Using dpQueryConnectSingle() without the 'ALERT' in the SELECT statement does actually work for the _act_state* values but not for _ack_user and _direction values.

Seems like in most alert handling cases it's actually better to use just a 'SELECT' query rather than a 'SELECT ALERT' query.

Thanks for your help on this one.


Cheers
Eric

[adaneau]

Hi Eric,

Most likely it should be enough.

If connected to act_state you'll get the event ACK and thus you just need to gather at this moment username (direction is also part of act_state) using alertGet.

BR
Alexandre