Log In
Register
Topic RSS
14:16, EEST
February 21, 2014
Offline
Hello,
I’d like to subscribe to condition based events and create a monitoredItem and listener per event. Is there a possibility to create a WhereClause including the conditionTypeId (already included) and the conditionId? While the conditionId is part of the returned eventProperty array (last item), there is no explicit condition property that can be used for whereclause..
Thanks, HU
15:27, EEST
April 3, 2012
Offline
Hi,
The same clause-logic should work for both selecting and filtering, though separately.
Assuming you use the ContentFilterBuilder, e.g. following should work as an example
ContentFilterBuilder fb = new ContentFilterBuilder();
NodeId expectedConditionId = …
fb.add(FilterOperator.Equals, new SimpleAttributeOperand(Identifiers.ConditionType, null, Attributes.NodeId, null), new LiteralOperand(expectedConditionId));
ContentFilter contentFilter = fb.getContentFilter()
EventFilter filter = …
filter.setWhereClause(contentFilter);
That SimpleAttributeOperand is listed at the end of https://reference.opcfoundatio…..00-9/5.5.2. Per my interpretation, it shouldn’t be … anything special as it just follows the normal rules of the SimpleAttributeOperand. A null/empty browsePath selects the alarm node itself and then it is attribute selection for that node. Though, note that in general servers (including our SDK) only support Attributes.NodeId for a null/empty path and then only the Attributes.Value for all others. It is also possible some server specifically wants the Identifiers.ConditionType as the typeId. In my opinion e.g. Identifiers.BaseEventType should work as well since it is just an inheritance check (though, in general only ConditionType and subtypes are real nodes in the address space and all other Events are “one-shot” and not present; even though temporarily they do in our impl before triggering)
9:55, EET
February 21, 2014
Offline
Good day,
I am sorry for not following up earlier, but I was unable to log into my Prosys account.
The whereClause above does not seem to work. When applied, no events at all are received. I also tried to use a LiteralOperand(Variant(expectedConditionId)) with no success.
The challenge is that I am receiving a large number of events using the same type and the same *number* of EventProperties. But there is no guarantee, that all events provide the ConditionId in the “last” or any particular EventProperty
16:32, EET
April 3, 2012
Offline
Just in case there was a misunderstanding, the whole line is “fb.add(FilterOperator.Equals, new SimpleAttributeOperand(Identifiers.ConditionType, null, Attributes.NodeId, null), new LiteralOperand(expectedConditionId));”
SelectClauses and WhereClauses are completely independent. Technically the SimpleAttributeOperand here in the WhereClause does also “select data”, but it is nothing related to the SelectClauses (or their positions), as far as I’m aware.
What the SimpleAttributeOperand does is move BrowsePath steps away from the event node (null/empty path, so it stays in the event instance), then take the NodeId Attribute value. Then the Equals operator compares this with the literal value expectedConditionId. If true, then the Event is sent, if false it is not. If the event is not a ConditionType subtype, then the NodeId Attribute value is null and the equals fails.
Note however that the whole EventFilter system is done server-side. It should work with our SDK servers. But no guarantee “a random server” has implemented it (and probaly we also miss some combinations, the whereclause part is quite complicated).
Just to be sure, you could also try with new QualifiedName[0] instead of null for the browse path parameter, just in case a server likes it better.
1 Guest(s)
