dpConnect with SELECT ALERT query ignores WHERE statement

[tpjctrl]

For whatever reason a dpConnect configured with a statement that contains SELECT ALERT seems to completely ignore the WHERE statement and also returns the wrong values. Example:

dpQueryConnectSingle("cb",
FALSE,
"",
"SELECT ALERT '_alert_hdl.._act_state', '_alert_hdl.._act_state_range', '_alert_hdl.._value' FROM 'testBool3.VALUE' REMOTE 'SCSM:' WHERE '_alert_hdl.._act_state' == 1 OR '_alert_hdl.._act_state' == 2");

So cb should only get triggered when a CAME unack'd or CAME ack'd alert comes in, but it just fires constantly regardless of whether testBool3.VALUE is set to TRUE or FALSE. On top of this the cb constantly returns the following values:

_alert_hdl.._act_state = 1
_alert_hdl.._act_state_range = 1
_alert_hdl.._value = TRUE

and this is again regardless of whether testBool3.VALUE is set to TRUE or FALSE.

If I remove the entire WHERE statement from the SELECT ALERT then it kind of works ok, although when testBool3.VALUE is set to FALSE, then it returns two sets of values:

WCCOAui1: 2: dyn_anytype 5 items
WCCOAui1: 1: SCSM:testBool3.VALUE (Type: 292 Sys: 1 Dp: 1100504 El: 2 : 0..0)
WCCOAui1: 2: 2023.07.24 11:14:09.596 (0 ) SCSM:testBool3.VALUE:_alert_hdl (Type: 292 Sys: 1 Dp: 1100504 El: 2 : _alert_hdl..0)
WCCOAui1: 3: 0
WCCOAui1: 4: 0
WCCOAui1: 5: FALSE
WCCOAui1: 3: dyn_anytype 5 items
WCCOAui1: 1: SCSM:testBool3.VALUE (Type: 292 Sys: 1 Dp: 1100504 El: 2 : 0..0)
WCCOAui1: 2: 2023.07.24 11:13:44.666 (0 ) SCSM:testBool3.VALUE:_alert_hdl (Type: 292 Sys: 1 Dp: 1100504 El: 2 : _alert_hdl..0)
WCCOAui1: 3: 1
WCCOAui1: 4: 1
WCCOAui1: 5: TRUE

The top one is the current FALSE value but it also returns the previous TRUE state values. If I set testBool3.VALUE to TRUE it only returns the current attributes:

WCCOAui1: 2: dyn_anytype 5 items
WCCOAui1: 1: SCSM:testBool3.VALUE (Type: 292 Sys: 1 Dp: 1100504 El: 2 : 0..0)
WCCOAui1: 2: 2023.07.24 11:14:26.589 (0 ) SCSM:testBool3.VALUE:_alert_hdl (Type: 292 Sys: 1 Dp: 1100504 El: 2 : _alert_hdl..0)
WCCOAui1: 3: 1
WCCOAui1: 4: 1
WCCOAui1: 5: TRUE

Is this by design? and why does it ignore the WHERE statement in the first place which then seems to completely break the function and the values it returns?

[dbindernagel]

I just created a test in an empty project using your query but without the REMOTE part. Boolean DPE with a continuous alert handling (good range: off).
WinCC OA 3.18 P017

1.
Set to TRUE:
WCCOAui1: 3: 1
WCCOAui1: 4: 1
WCCOAui1: 5: TRUE
Set to FALSE:
WCCOAui1: 3: 3
WCCOAui1: 4: 1
WCCOAui1: 5: FALSE

2.
Set to TRUE:
WCCOAui1: 3: 1
WCCOAui1: 4: 1
WCCOAui1: 5: TRUE
<Acknowledge> (no log entry here)
Set to FALSE:
WCCOAui1: 3: 0
WCCOAui1: 4: 0
WCCOAui1: 5: FALSE

Looks fine to me. Maybe a problem with DIST?
Which version do you use?

[tpjctrl]

Thanks for trying, I'm on 3.18 P018 and it's definitely broken there. I also just tried it without the REMOTE statement, so the dpConnect registration looks like this:

main(mapping event)
{
dpQueryConnectSingle("cb",
FALSE,
"",
"SELECT ALERT '_alert_hdl.._act_state', '_alert_hdl.._act_state_range', '_alert_hdl.._value' FROM 'testBool3.VALUE' WHERE '_alert_hdl.._act_state' == 1 OR '_alert_hdl.._act_state' == 2");
}

and this is the cb:

void cb(string s, dyn_dyn_anytype result)
{
DebugN(result);
}

and here's the results after setting the bool to TRUE and then setting it to FALSE a few seconds later.

WCCOAui1:[dyn_dyn_anytype 2 items
WCCOAui1: 1: dyn_anytype 5 items
WCCOAui1: 1: (Type: 0 Sys: 0 Dp: 0 El: 0 : 0..0)
WCCOAui1: 2: (Type: 0 Sys: 0 Dp: 0 El: 0 : 0..0)
WCCOAui1: 3: :_alert_hdl.._act_state (Type: 0 Sys: 0 Dp: 0 El: 0 : _alert_hdl.._act_state)
WCCOAui1: 4: :_alert_hdl.._act_state_range (Type: 0 Sys: 0 Dp: 0 El: 0 : _alert_hdl.._act_state_range)
WCCOAui1: 5: :_alert_hdl.._value (Type: 0 Sys: 0 Dp: 0 El: 0 : _alert_hdl.._value)
WCCOAui1: 2: dyn_anytype 5 items
WCCOAui1: 1: SCSM:testBool3.VALUE (Type: 292 Sys: 1 Dp: 1100504 El: 2 : 0..0)
WCCOAui1: 2: 2023.07.25 13:03:56.477 (0 ) SCSM:testBool3.VALUE:_alert_hdl (Type: 292 Sys: 1 Dp: 1100504 El: 2 : _alert_hdl..0)
WCCOAui1: 3: 1
WCCOAui1: 4: 1
WCCOAui1: 5: TRUE
WCCOAui1:]
WCCOAui1:[dyn_dyn_anytype 2 items
WCCOAui1: 1: dyn_anytype 5 items
WCCOAui1: 1: (Type: 0 Sys: 0 Dp: 0 El: 0 : 0..0)
WCCOAui1: 2: (Type: 0 Sys: 0 Dp: 0 El: 0 : 0..0)
WCCOAui1: 3: :_alert_hdl.._act_state (Type: 0 Sys: 0 Dp: 0 El: 0 : _alert_hdl.._act_state)
WCCOAui1: 4: :_alert_hdl.._act_state_range (Type: 0 Sys: 0 Dp: 0 El: 0 : _alert_hdl.._act_state_range)
WCCOAui1: 5: :_alert_hdl.._value (Type: 0 Sys: 0 Dp: 0 El: 0 : _alert_hdl.._value)
WCCOAui1: 2: dyn_anytype 5 items
WCCOAui1: 1: SCSM:testBool3.VALUE (Type: 292 Sys: 1 Dp: 1100504 El: 2 : 0..0)
WCCOAui1: 2: 2023.07.25 13:03:56.477 (0 ) SCSM:testBool3.VALUE:_alert_hdl (Type: 292 Sys: 1 Dp: 1100504 El: 2 : _alert_hdl..0)
WCCOAui1: 3: 1
WCCOAui1: 4: 1
WCCOAui1: 5: TRUE
WCCOAui1:]

Note that it's basically returning the same info for both transitions, look at the time stamp, even for the TRUE->FALSE transition, it shows data from the initial FALSE -> TRUE transition, so it's basically showing old data...

EDIT: just an additional note, I've got the alerts set to auto ack, ie. if you set a bool to TRUE it alarms, but if you set it to FALSE it automatically clears. Perhaps this is breaking something as it's not standard behaviour?

[gschijndel]

There are the following things that you could try:
1. Remove the 'ALERT' keyword from the query and remove attributes that cannot be queried with dpConnect

Code: Select all

SELECT '_alert_hdl.._act_state,_alert_hdl.._act_state_range,_online.._value' FROM 'testBool3.VALUE' REMOTE 'SCSM:' WHERE '_alert_hdl.._act_state' IN (1,2)

2. Use only attributes that can be queried using a 'SELECT ALERT' query

Code: Select all

// New CAME alerts do not have a partner yet (WENT alerts always have the CAME alert as partner)
SELECT ALERT '_alert_hdl.._direction,_alert_hdl.._value' FROM 'testBool3.VALUE' REMOTE 'SCSM:' WHERE '_alert_hdl.._partner' == 0

[tpjctrl]

Thanks for the reply gschijndel, option 1 is actually what I use now, but then within the callback function I need to additionally pull out the alert value which also seems to not work for multirange alerts for some reason (at least not with AlertGet) - hence the reason for using dpGet and _original.._value which isn't ideal.

As for number 2...hmm yes, I can see what you mean, only _alert_hdl.._value can be pulled using SELECT ALERT, the other two not, so that might explain the odd behaviour.

So now I'm curious why the statement worked for dbindernagel ?

[dbindernagel]

I looked at the reference table for the _alert_hdl before testing to make sure the attributes are valid but I looked at the dpConnect column and not the correct alertConnect one..
https://www.winccoa.com/documentation/W ... t_hdl.html

My guess is that since the attributes are valid for a dpConnect the "ALERT" in the SELECT ALERT is just ignored as if it was not there.

You can try it yourself with a new project (should just take 5 min).
I created a datapoint of DPT with 1 bool DPE and put an alert handling with S7_Alarm class and I put the following code in the initialize of a panel.

Code: Select all

main()
{
  string query = "SELECT ALERT "
                 "'_alert_hdl.._act_state', "
                 "'_alert_hdl.._act_state_range', "
                 "'_alert_hdl.._value' "
                 "FROM "
                 "'testBool3.VALUE' ";
//                  "WHERE "
//                  "'_alert_hdl.._act_state' == 1 "
//                  "OR "
//                  "'_alert_hdl.._act_state' == 2";

  dpQueryConnectSingle("cb",
                       FALSE,
                       "",
                       query);
}

void cb(string s, dyn_dyn_anytype ddaTab)
{
  DebugN(ddaTab);
}

Code: Select all

# ascii dump of database

# DpType
TypeName
ATest.ATest	1#1
	VALUE	23#2

# Datapoint/DpId
DpName	TypeName	ID
testBool3	ATest	589

# AlertValue
Manager/User	ElementName	TypeName	DetailNr	_alert_hdl.._type	_alert_hdl.._l_limit	_alert_hdl.._u_limit	_alert_hdl.._l_incl	_alert_hdl.._u_incl	_alert_hdl.._panel	_alert_hdl.._panel_param	_alert_hdl.._help	_alert_hdl.._min_prio	_alert_hdl.._class	_alert_hdl.._text	_alert_hdl.._active	_alert_hdl.._orig_hdl	_alert_hdl.._ok_range	_alert_hdl.._hyst_type	_alert_hdl.._hyst_time	_alert_hdl.._multi_instance	_alert_hdl.._l_hyst_limit	_alert_hdl.._u_hyst_limit	_alert_hdl.._text1	_alert_hdl.._text0	_alert_hdl.._ack_has_prio	_alert_hdl.._order	_alert_hdl.._dp_pattern	_alert_hdl.._dp_list	_alert_hdl.._prio_pattern	_alert_hdl.._abbr_pattern	_alert_hdl.._ack_deletes	_alert_hdl.._non_ack	_alert_hdl.._came_ack	_alert_hdl.._pair_ack	_alert_hdl.._both_ack	_alert_hdl.._impulse	_alert_hdl.._filter_threshold	_alert_hdl.._went_text	_alert_hdl.._add_text	_alert_hdl.._status64_pattern	_alert_hdl.._neg	_alert_hdl.._status64_match	_alert_hdl.._match	_alert_hdl.._set
UI (1)/0	testBool3.VALUE	ATest		12					""	""	lt:1 LANG:10005 ""	\0	S7_Alarm.		1	1	0	0	01.01.1970 00:00:00.000	0			lt:1 LANG:10005 "Alarm"	lt:1 LANG:10005 "OK"												0								

[leoknipp]

At the _alert_hdl config you have to differ between attributes used for the configuration and the attributes which are set when an alert is generated.

A dpQuery/dpQueryConnectSingle with the keyword SELECT ALERT filters for the generated alerts.
If only a SELECT is used you cannot retrieve alert information. You can only read the configuration attributes for the _alert_hdl config.

If you want to filter for the CAME alerts why do you not use a SELECT ALERT including a WHERE statement which filters for the attribute _alert_hdl.._direction?

Best Regards
Leopold Knipp
Senior Support Specialist