Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [milo-dev] Alarm/Event Notifications triggers from OPC server
Yes, it seems the Bad_InternalError you got is some kind of bug or programming error in the Prosys server.

It seems you've already got it, but an example EventFilter might look like this:

EventFilter eventFilter = new EventFilter(
    new SimpleAttributeOperand[]{
        new SimpleAttributeOperand(
            Identifiers.BaseEventType,
            new QualifiedName[]{new QualifiedName(0, "EventId")},
            AttributeId.Value.uid(),
            null),
        new SimpleAttributeOperand(
            Identifiers.BaseEventType,
            new QualifiedName[]{new QualifiedName(0, "Severity")},
            AttributeId.Value.uid(),
            null),
        new SimpleAttributeOperand(
            Identifiers.BaseEventType,
            new QualifiedName[]{new QualifiedName(0, "Time")},
            AttributeId.Value.uid(),
            null),
        new SimpleAttributeOperand(
            Identifiers.BaseEventType,
            new QualifiedName[]{new QualifiedName(0, "Message")},
            AttributeId.Value.uid(),
            null)
    },
    new ContentFilter(null)
);

On Sat, Nov 25, 2017 at 2:22 AM, Isuru Samaraweera <isuru@xxxxxxxx> wrote:
It seems after passing a EventFilter monitoredItem was created successfully.
Spec is not mandating a EventFilter as per my understanding.Might be this server I use mandates an EventFilter

Thanks

On Sat, Nov 25, 2017 at 11:19 AM, Isuru Samaraweera <isuru@xxxxxxxx> wrote:
I created a device node with ns=2;s=MyDevice with EventNotifier set to1 in a OPC server which supports alarms and events.
I am trying to intercept events from client.The code  I used is attached herewith. 

I am getting below error on server when I ran the code.It seems a configuration error on the client.

ServiceFault: Bad_InternalError (0x80020000) "An internal error occurred as a result of a programming or configuration error."
Diagnostic Info: java.lang.IllegalArgumentException: addItem called with EventNotifier, use addEventItme instead 
at com.prosysopc.ua.server.Subscription.addDataItem(Unknown Source)
at com.prosysopc.ua.server.SubscriptionManager.createMonitoredDataItem(Unknown Source)
at com.prosysopc.ua.server.SubscriptionManager.createMonitoredItem(Unknown Source)
at com.prosysopc.ua.server.SubscriptionServiceHandler.createMonitoredItems(Unknown Source)
at com.prosysopc.ua.server.SubscriptionServiceHandler.onCreateMonitoredItems(Unknown Source)



Can you please see what has gone wrong in the attached client code?

Thanks
Isuru

On Sat, Nov 25, 2017 at 12:23 AM, Kevin Herron <kevinherron@xxxxxxxxx> wrote:
Events are only supported in the client SDK right now.

Tentative milestone for support in the server is release 0.3.0.

On Fri, Nov 24, 2017 at 10:41 AM, Isuru Samaraweera <isuru@xxxxxxxx> wrote:
I did all the steps you mention to publish events like Creating objectnode with EventNotifier =1,Client changes etc..
How do we simulate triggering a event?Event triggering is supported by Milo server?
Please clarify

Thanks,
Isuru

On Fri, Nov 24, 2017 at 6:33 PM, Kevin Herron <kevinherron@xxxxxxxxx> wrote:
The SamplingInterval is supposed to be 0 when you subscribe to Events, so I assume you're talking about the PublishingInterval of the subscription.

Yes, there will be a delay, up to as much as the PublishingInterval, before the clients receive the notifications. There's no way around this - it's how subscriptions work in OPC UA. It's like this because schemes where changes are sent immediately don't scale when you have tens of thousands of changes happening. The PublishingInterval allows changes to be "batched" and sent to the client periodically (at the PublishingInterval). The QueueSize parameter when creating a MonitoredItem provides a mechanism to ensure multiple changes happening to an item within the PublishingInterval are not lost.

Perhaps the best thing you can do is create a Subscription you use just for Events with a fast PublishingInterval.



On Thu, Nov 23, 2017 at 9:25 PM, Isuru Samaraweera <isuru@xxxxxxxx> wrote:
For instance Alarm/Events might need to be notified to the client as it happens instead of waiting till PublishRequest arrives from a client after frequency is met.

Please clarify.

On Fri, Nov 24, 2017 at 10:45 AM, Isuru Samaraweera <isuru@xxxxxxxx> wrote:
When subscribing to events through subscription we set up  a sampling interval.
If we set the interval as 5 seconds.Event notifications are also sent out to the client in the same frequency by queuing them in the server instead of as soon as event happens.

Is there anyway events notifications are sentout to the client as the event transpires bypassing PublishRequest/Response which happens in the frequency set up during Subscription?

Thanks,
Isuru




On Fri, Nov 24, 2017 at 12:36 AM, Kevin Herron <kevinherron@xxxxxxxxx> wrote:
Subscribing to events work like this, assuming you have a Subscription already:

1. Find the ObjectNode in the server that is the source of events you're interested in. Its EventNotifier attribute will be set.

2. Create a MonitoredItem, pointing at that EventNotifier attribute, in MonitoringMode.Reporting, optionally specifying an EventFilter. How you define an EventFilter is talked about in part 4 of the spec, section 7.17.3. It's almost like you're building a SQL query with a select and where clause that determines what kinds of events and what fields from those events are delivered.

3. Set an EventConsumer on the UaMonitoredItem you created. That will be the callback invoked when the server delivers events that passed the EventFilter.

You shouldn't need to worry about receiving empty PublishResponses or null NotificationMessages (neither of those things should happen, except an empty PublishResponse when its a KeepAlive). If you're using the OpcUaClient then you don't ever interact directly with PublishRequest/PublishResponse in the first place - the subscription manager takes care of that and you just receive callbacks on the items you create.



On Thu, Nov 23, 2017 at 9:44 AM, Isuru Samaraweera <isuru@xxxxxxxx> wrote:
Hi All,

Normal procedure for receiving notification from server is

1.Create Subscription
2.Create MpnitoringParameters/MonitoredItemCreateRequest
3.createMonitoredItems

Once you do this PublishRequest/Response is used to receive notifications.

If we have to receive specific notifications/alarms instead of all the notifications from the server
The right way is to define a filter(DataChangeFilter,EventFilter etc) of type Extensible Parameter MonitoringFilter along with above 3 steps and
sentout notifications only if filter criteria is met?

If criteria is not met PublishResponse will be sent out with NotificationMessage set to null?

Or Is there a different way for condtionalNotifications/Alarms to be sent out without creating subscriptions,filters and monitoreditems and without sending empty PublishResponses ?

Please clarify.

Thanks,
Isuru

_______________________________________________
milo-dev mailing list
milo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/milo-dev



_______________________________________________
milo-dev mailing list
milo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/milo-dev




_______________________________________________
milo-dev mailing list
milo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/milo-dev



_______________________________________________
milo-dev mailing list
milo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/milo-dev



_______________________________________________
milo-dev mailing list
milo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/milo-dev



_______________________________________________
milo-dev mailing list
milo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/milo-dev




_______________________________________________
milo-dev mailing list
milo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/milo-dev


Back to the top