ServiceFault (BadNoSubscription , ...) on subscription delete

[jrast]

I'm very new to OPC-UA and this package, so maybe this is a sily question... Hoewever, any help would be apriciated!

I get the following Warning in the console when i try to unsubscribe or delete a subscription:

ServiceFault (BadNoSubscription, diagnostics: DiagnosticInfo(SymbolicId=None, NamespaceURI=None, Locale=None, LocalizedText=None, AdditionalInfo=None, InnerStatusCode=None, InnerDiagnosticInfo=None)) from server received  in response to PublishRequest

I can't post the complete code but here is the relevant section where I create and delete the subscribtion:

class ManagedSubscription:
    def subscribe(self, client, nodes):
        sub = client.create_subscription(
            ua.CreateSubscriptionParameters(
                RequestedPublishingInterval=50.0,
                RequestedLifetimeCount=72000,
                RequestedMaxKeepAliveCount=24000,
                MaxNotificationsPerPublish=10000,
                PublishingEnabled=True,
                Priority=0,
            ),
            self,
        )
        handle = sub.subscribe_data_change(nodes)
        self._sub = sub
        self._handle = handle

    def unsubscribe(self):
        # logging.debug("Delete")
        self._sub.delete()
        self._sub = None
        self._handle = None

# Usage example:
mngr = ManagedSubscription()
mngr.subscribe(client, [node_1, node_2])
# ... some application logic
mngr.unsubscribe()

Is there something wrong with my code? I also tried to unsubscribe before deleting the subscription but I got the same behavior.

[AndreasHeine]

did you use asyncua or python-opcua?

[AndreasHeine]

but i guess you don't unsubscribe the handel's! so there is a publishrequest already send to the server...

[jrast]

I use asyncua. Andreas Heine ***@***.***> schrieb am Di., 15. Feb. 2022, 18:39:

…

did you use asyncua or python-opcua? — Reply to this email directly, view it on GitHub <#805 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABDXQNDNFAMBMFL7PHUBVLU3KFTLANCNFSM5OPFWH2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[AndreasHeine]

e.g.:
https://github.com/AndreasHeine/opcua-tutorial/blob/main/client/subscribe.py

[jrast]

Note that I'm using the sync wrapper for asyncua. But in my first steps I also tried to use the async client (which is currently to hard to integrate into our existing architecture) and I think I got the same errors. But I can double check this later this week.

Does subscription.delete() not unsubscribe automatically?

[AndreasHeine]

delete() sends a request to delete the subscription on serverside!
after closer look at your code:
"RequestedPublishingInterval=50.0" -> is pretty less time for a network call to get a response to
so you have some sort of overlap which can lead to that error too!
in my opinion less then 100ms is stupid (python + networkdelay = ...)
remmeber the publish intervall has nothing to do with the samplerate in the opc ua server with a longer publishinterval you will recv bigger chunks of queued messages but you will not miss valuechanges maybe the response time in you app is a little slower but try 1000ms instead!

edit:
set the queuesize to a proper value!

[jrast]

Ok, I probably missunderstood subscribtions then. I thought of them as a way to get quick response times but if I need to increase the cycle time to 1000ms they are the wrong tool and I am better of with just polling for the values?

[AndreasHeine]

'''
https://reference.opcfoundation.org/v104/Core/docs/Part4/5.13.1/
In simple words:
A OPC UA Subscription works like a "Mailbox" which gets emptied in a defined interval by the Client.
The OPC UA Client sends a publishrequest, the server takes all notifications since the last publishrequest.
and send them in the publishresponse to the client.
If there is no Notification in the "Mailbox" the Client will get a "keep-alive" back.
The OPC UA Client can add "MonitoredItems" to the Subscription which will generate Notifications.
'''

its some sort of longpolling!

[AndreasHeine]

sorry not really... its still request/response (just a callmethodrequest instead of a publishrequest^^)!

[jrast]

Are you shure about this? I created a dummy setup with a server / client (https://gist.github.com/jrast/1befc0f62db27d7ede9985d6b1f7fb8d) where I can see that call_method returns as soon as the method returns in contrast to the subscription which is only executed every period milliseconds. So at least in this case a implementation based on method calls would be much more responsive than waiting for a subscription update.

[AndreasHeine]

a methodcall should not take 2-10 seconds to return!!! would be bad practise... for those cases its better to have a opc ua statemachine which has a result avalible state indicating that the processing is finished

[jrast]

Ouch, learned something again... I'll have a look at the StateMachines.

[AndreasHeine]

So what is the recommeded way to get notified about a server side change as soon as possible?
Our usecase is as such:

Start a process on the Server. This is done by writing a "execute" attribute to true.
Most of these processes are completed within a short time, typically 0.5 - 10 seconds.
Once the process is finished a "done" and "error" (both boolean) attributes are set.
Our application creates a subscription which listens on these attributes to wait until the process step is done.

in a nutshell:
MethodCall to Trigger a Process "OPC UA Spec Part 10 - Programs" https://reference.opcfoundation.org/Core/docs/Part10/4.2.1/ ;) -> ProcessStatemachine goes from Init-State to Processing-State -> ... time passes ... -> ProcessStatemachine goes from Processing-State to Result-Avalible-State -> (Emit OPC UA Event e.g. some kind of "ResultEventType" with the actual result data) also store the last result in a OPC UA Variable e.g. LastResult (just in case you don't want to sub to the event you can sub the Variable) -> ProcessStatemachine goes to Init-State

thats the way i have seen it in other OPC UA Companion Specs. like:
AutoId (https://reference.opcfoundation.org/AutoID/ObjectTypes/)
MachineVision (https://reference.opcfoundation.org/MachineVision/ObjectTypes/)
OPC for Machinery has some similarities with JobManagement and ResultTransfer but that part is not released yet...