Yeah … interestingly indeed finding the „official way to address something” is some times the most challenging thing. Unfortunately I am so staying away from OPC-UA in general, that I can’t help you with that.
Chris Von: Łukasz Dywicki <l...@code-house.org> Datum: Freitag, 23. August 2024 um 11:20 An: dev@plc4x.apache.org <dev@plc4x.apache.org> Betreff: Re: Progress on OPC UA notifications Event subscriptions at the API level are indeed a perfect match for alarms and alerts. So far we have alarms (event) subscriptions implemented only for S7, which uses special tag syntax, different than regular read/write tags. Here situation is similar, however I don't have any reference material of how official tag syntax looks a like. For s7 there are some pointers coming from official tooling and their syntax (i.e. %DB, %Q). For OPC-UA we have only node (ns=x;i=y). I haven't found so far any example of what syntax people use to subscribe events. There was one scada documentation which allowed to specify attribute id, but its vendor specific. I don't think UA specs advertises anything like that. That's why I'm in the need to define tag syntax which will serve us in initial implementation and let gather community feedback. So OPC UA subscription tag will need to include optional node id and event field for a start. Data type will remain optional, in case user will require explicit type mapping. For now we'll skip attribute id in tag syntax to do not complicate things even more. Best, Łukasz On 23.08.2024 07:26, Christofer Dutz wrote: > Don't we already have "alerts" as a concept in subscriptions? Isn't that > pretty much the same as An event? > > Chris > > > Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> > ________________________________ > From: Łukasz Dywicki <l...@code-house.org> > Sent: Friday, August 23, 2024 2:12:09 AM > To: dev@plc4x.apache.org <dev@plc4x.apache.org> > Subject: Progress on OPC UA notifications > > Hey folks, > I wanted to share, and also source your ideas on tag syntax for OPC UA. > I've managed to add missing messages and a bit of PoC logic to emulate > event subscription. It seems to work, now its time to adjust > subscription handling logic. > > In principle OPC UA specification defines 3 kinds of notifications [1]: > 1) Data Change > 2) Event > 3) Status Change > > These have different calls to submit request and deliver different > information. Before we go deeper, remember that in OPC UA everything is > based on request/response paradigm. There is no push side per say, we > send a publish request to receive notification message. > What our Java driver currently cover is data change, so its more or less > cyclic update / data change. The event notification requires pointing > out what fields of event are interesting (i.e Id, Type, Time, Message), > we then receive them. Still, event notification have to be hooked at > specific NodeId, Milo's examples use Server (ns=0;i=2253) and > EventNotifier (12 / 0x0c) attribute, whereas data change aim Value (13 / > 0x0d) attribute. These of you who are familiar with OPC-UA can see some > similarities due to multiple levels of complexity (object vs its property). > Interesting animal in this zoo is status change which can be used to > receive information about bad signal quality (whatever it means). > > Out of these 3 notification kinds data and status change are pretty much > 1:1 (node id -> value, node id -> status), so each subscribed tag > returns single value. The metadata concept [2] opens possibility to > return more information to caller, including status. > The event notification however is different, because first and foremost, > we subscribe static node id (not sure if it can change), and do not send > node id but browse path which is just a text: > > new SimpleAttributeOperand(nodeId, > Arrays.asList(new QualifiedName(0, new PascalString >>("EventId")<<)), > AttributeId.Value.getValue(), > OpcuaProtocolLogic.NULL_STRING > ) > > Additionally, there might be filter criteria [3] (I didn't try yet), > which can be used to supply more conditions for receiving data. > > Coming to the point - what do you think about defining new tag type for > OPC UA to cover event fields? With this we could use this tag to specify > event fields (browse path), and eventually use tag attributes for criteria: > > .addEventTagAddress("EventId;REAL") > .addEventTagAddress("ns=0;i=2253;EventId;REAL") // same as above > .addEventTagAddress("Time;DATETIME") > .addEventTagAddress("Message;STRING{like=Fatal error}") > > In above example the default subscribe is assumed to be ns=0;i=2253, but > each event tag address would require a path. > > WDYT? > > Best, > Łukasz > > [1] https://reference.opcfoundation.org/Core/Part4/v104/docs/7.20 > [2] https://github.com/apache/plc4x/pull/1725 > [3] https://reference.opcfoundation.org/Core/Part4/v104/docs/7.4.4 >
