msg="AutoDiscovery stopped: ProtocolDiscovery not implemented

[sawashar]

Hi, After Running the opcua-go service and the prosys simulation server for opcua Iam getting following logs: level=INFO ts=2022-01-27T11:00:04.56535565Z app=device-opcua source=config.go:373 msg="Loaded service configuration from ./res/configuration.toml" level=INFO ts=2022-01-27T11:00:04.567181102Z app=device-opcua source=config.go:510 msg="Using local configuration from file (0 envVars overrides applied)" level=INFO ts=2022-01-27T11:00:04.567592323Z app=device-opcua source=httpserver.go:123 msg="Web server starting (localhost:59997)" level=INFO ts=2022-01-27T11:00:04.568091574Z app=device-opcua source=messaging.go:69 msg="Setting options for secure MessageBus with AuthMode='usernamepassword' and SecretName='redisdb" level=INFO ts=2022-01-27T11:00:04.56968194Z app=device-opcua source=messaging.go:99 msg="Connected to redis Message Bus @ redis://localhost:6379 publishing on 'edgex/events/device' prefix topic with AuthMode='usernamepassword'" level=INFO ts=2022-01-27T11:00:04.570360547Z app=device-opcua source=init.go:137 msg="Check core-metadata service's status by ping..." level=INFO ts=2022-01-27T11:00:04.571719401Z app=device-opcua source=init.go:56 msg="Service clients initialize successful." level=INFO ts=2022-01-27T11:00:04.572147996Z app=device-opcua source=restrouter.go:47 msg="Registering v2 routes..." level=INFO ts=2022-01-27T11:00:04.577399704Z app=device-opcua source=config.go:223 msg="Skipping use of Configuration Provider for custom configuration: Provider not available" level=INFO ts=2022-01-27T11:00:04.578539535Z app=device-opcua source=config.go:373 msg="Loaded custom configuration from ./res/configuration.toml" level=INFO ts=2022-01-27T11:00:04.579070217Z app=device-opcua source=config.go:282 msg="Loaded custom configuration from file (0 envVars overrides applied)" level=DEBUG ts=2022-01-27T11:00:04.579391199Z app=device-opcua source=driver.go:63 msg="Custom config is: &{{SimulationServer None None {Counter,Random}}}" level=WARN ts=2022-01-27T11:00:04.57966382Z app=device-opcua source=config.go:295 msg="unable to watch custom configuration for changes: Configuration Provider not enabled" level=DEBUG ts=2022-01-27T11:00:04.579935829Z app=device-opcua source=service.go:198 msg="trying to find device service device-opcua" level=INFO ts=2022-01-27T11:00:04.580941665Z app=device-opcua source=service.go:216 msg="device service device-opcua exists, updating it" level=INFO ts=2022-01-27T11:00:04.584254944Z app=device-opcua source=profiles.go:54 msg="Loading pre-defined profiles from /home/sawashar/ireland/device-opcua-go-main/cmd/res/profiles" level=INFO ts=2022-01-27T11:00:04.586400379Z app=device-opcua source=profiles.go:88 msg="Profile OPCUA-Server exists, using the existing one" level=INFO ts=2022-01-27T11:00:04.586885915Z app=device-opcua source=devices.go:49 msg="Loading pre-defined devices from /home/sawashar/ireland/device-opcua-go-main/cmd/res/devices" level=INFO ts=2022-01-27T11:00:04.587216643Z app=device-opcua source=devices.go:85 msg="Device SimulationServer exists, using the existing one" 0s level=INFO ts=2022-01-27T11:00:04.587864262Z app=device-opcua source=autodiscovery.go:39 msg="AutoDiscovery stopped: interval error in configuration" level=INFO ts=2022-01-27T11:00:04.588122482Z app=device-opcua source=autodiscovery.go:43 msg="AutoDiscovery stopped: ProtocolDiscovery not implemented" level=INFO ts=2022-01-27T11:00:04.588359389Z app=device-opcua source=message.go:50 msg="Service dependencies resolved..." level=INFO ts=2022-01-27T11:00:04.588705859Z app=device-opcua source=message.go:51 msg="Starting device-opcua 0.0.0 " level=INFO ts=2022-01-27T11:00:04.588966897Z app=device-opcua source=message.go:55 msg="device opcua started" level=INFO ts=2022-01-27T11:00:04.589212602Z app=device-opcua source=message.go:58 msg="Service started in: 24.475597ms"

Seems like Autodiscovery has stopped and now it not reading any value from server. Can you please help.

[jrtitus]

AutoDiscovery is not necessary to read values. As of now, it is not implemented in this service because the driver does not implement func (d *Driver) Discover().

Can you post your configuration?

[sawashar]

Hi, Okay Thanks. So now the issue is why device service is not getting the values of attributes from OPCUA Server. I am following the same tutorial mentioned in ReadME with default onboarded device and default profile. Following is my configuration.toml and device.toml configuration.txt device.txt Thanks in advance.

[jrtitus]

Well, this is interesting.. 🤔

On one hand, I'm unable to reproduce your issue if I run the service in a container as part of the EdgeX docker-compose file. By tailing the docker log for the device-opcua container I can see values being read matching the values coming from Prosys.

To the end of the services section of this file I added the following:

  device-opcua:
    container_name: edgex-device-opcua
    depends_on:
    - consul
    - data
    - metadata
    environment:
      CLIENTS_CORE_COMMAND_HOST: edgex-core-command
      CLIENTS_CORE_DATA_HOST: edgex-core-data
      CLIENTS_CORE_METADATA_HOST: edgex-core-metadata
      CLIENTS_SUPPORT_NOTIFICATIONS_HOST: edgex-support-notifications
      CLIENTS_SUPPORT_SCHEDULER_HOST: edgex-support-scheduler
      DATABASES_PRIMARY_HOST: edgex-redis
      EDGEX_SECURITY_SECRET_STORE: "false"
      MESSAGEQUEUE_HOST: edgex-redis
      REGISTRY_HOST: edgex-core-consul
      SERVICE_HOST: edgex-device-opcua
    hostname: edgex-device-opcua
    image: edgexfoundry/device-opcua-go:0.0.0-dev
    networks:
      edgex-network: {}
    ports:
    - 127.0.0.1:59997:59997/tcp
    read_only: true
    restart: always
    security_opt:
    - no-new-privileges:true
    user: 2002:2001

On the other hand, I am able to reproduce your issue if I build and run the device-opcua executable while other EdgeX Foundry components are running as containers. Unfortunately I'm not entirely sure why...

Is that how you're running the services as well?

[sawashar]

Yes I am also running the device-opcua executable and getting this issue. Also @jrtitus can you guide with some documentation or sample files on how to invoke and test OPCUA Server methods and also subscribe to some events from OPCUA Server using this device service. It would be great help. Thanks!!

[jrtitus]

Can you guide with some documentation or sample files on how to invoke and test OPCUA Server methods...

There is a section in the README that has some info.

I'm having a bit of trouble with the ProSys simulator at the moment, but I have another simple OPC UA server that I'm testing with based on open62541 and it is working as documented.

If you'd like, for the ProSys simulator you can try this:

1. Turn on Options > Expert Mode

2. Go to the Address Space tab

3. Go to Objects > Server and note the NodeId (i=2253)

4. Inside Server there is the method GetMonitoredItems (i=11492).

5. The attributes configuration for this method in the device profile would be:

   attributes:
    { methodId: "i=11492", objectId: "i=2253" }

6. Making the method call is simply a get command:

   # Assuming you call the deviceCommand GetMonitoredItems in the profile...
   curl localhost:59997/api/v2/device/name/SimulationServer/GetMonitoredItems

If there were any input parameters associated with the method, they would be defined like

attributes:
  { inputMap: [ "in1", "in2", ...etc ] }

It's a very basic implementation, so currently there is no way to make the parameters dynamic.

...and also subscribe to some events from OPCUA Server using this device service

Truthfully, I haven't really looked into subscribing to events using the device service. I assume they would work the same way that other variables do: Define a resource for the variable, specifying the NodeId, in the device profile and add it to the list of Resources in OPCUAServer.Writable section of the service configuration. I also assume that it would be defined as readWrite: "R". Sorry I don't have more information on that.

---

As for an update on the original issue:

I have found that, unlike the containerized version, the executable version of the service does not seem to call to start the subscription listener, which is why we see no data. I thought this would have happened with the call to AddDevice or updateWritableConfig, but the executable version shows the following warning:

   level=WARN ts=2022-01-29T15:48:36.6057235Z app=device-opcua source=config.go:295 msg="unable to watch custom configuration for changes: Configuration Provider not enabled"

...but Consul is configured in the service configuration file. So, I'm not exactly sure what the problem is here. I'll continue to look into it when I have more time.

[jrtitus]

~I know it's been a while but I finally got some time to look at this more. The problem stems from multiple issues.~

~One issue is a misunderstanding on my part of when AddDevice is called. I should be calling startSubscriber() in driver.Initialize(). Putting it in AddDevice was a workaround for this problem. Additionally, this startSubscriber() should be retried until it succeeds, since it needs to handle cache misses in the device service... which leads me to the next issues.~

~The others are a couple issues in edgexfoundry/device-sdk-go:~

~1. https://github.com/edgexfoundry/device-sdk-go/blob/4b1bca24a13eee0fbd94f91607ff04ee351fa403/internal/provision/devices.go#L87-L92~

~First, when a device is not found in the cache, it is added to a slice of devices that are used to create a request to the metadata to add them. However, they are not added to the cache upon success of being added to the metadata, so the subscriptions will always fail when the service is initialized with an empty device cache.~

~2. https://github.com/edgexfoundry/device-sdk-go/blob/4b1bca24a13eee0fbd94f91607ff04ee351fa403/internal/provision/profiles.go#L86-L100~

~Second, this code does not seem to be quite right. It checks to see if the profile exists in the metadata, and if it does, logs that it exists, and checks to see if it exists in the cache and adds it if not found. However, it never adds a new device to the cache if it's not first found in metadata, even after it gets added to metadata in the lines below the loop. Because of this, even if the device is found in the cache, the same issue will be seen when trying to find resources in the cached profiles.~

~I was able to fix this issue locally with the same logic for both devices and profiles: after confirming that the add to metadata was successful, I loop through the new devices/profiles and add each of them to the cache. I will plan on making a PR to both repositories soon to try and resolve this.~

EDIT: After more testing, and a revelation, I can say that all of my comments above were completely and utterly wrong. Please see the comment below.

[jrtitus]

Well, I finally figured it out, and I should have seen it much sooner. 🤦🏻‍♂️

Since core-metadata is running inside a container as part of the compose file, it has no way to communicate over the bridge network back to device-opcua running on the host, so the callback fails. If both core-metadata and device-opcua are running as executables on the host, when device-opcua starts and the device is added to the metadata (device-opcua -> core-metadata), communication succeeds and the callback is triggered (core-metadata -> device-opcua).

So I think this issue can be closed as it is all a matter of configuration.

[jiekechoo]

please upgrade to v3, closed.