Would you consider making internal/llrp an exported package?

I would consider it the reference implementation of LLRP in go.
https://github.com/iomz/go-llrp has been unmaintained for a while.

Clean up main repository README.md

• reference to holding repo for LLRP app service
• Reference older version APIs in Swagger

It's unclear from the top-level README.md file whether or not this device service supports TLS when communicating with a reader.

The latest RFID specification includes a section titled "Security in TCP Transport" which indicates that both server and client TLS authentication are possible...

Note - this issue is being reported as of the initial untagged version of the service, after it's recent promotion from holding.

Consul mode - set logging mode "DEBUG"
Start tag reading after device discovery - below the failed log message.

edgex-device-rfid-llrp | level=DEBUG ts=2022-04-06T23:26:58.797373245Z app=device-rfid-llrp source=transform.go:96 msg="failed to read ResourceOperation: failed to find ResourceOpertaion with DeviceResource ROAccessReport in Profile LLRP-Impinj-Profile"
In DEBUG logging mode - this failed msg keep logging in console at start reading from app service.

🐞 Bug Report

Affected Services [REQUIRED]

Is this a regression? Maybe, did not see issue in Levski

Description and Minimal Reproduction [REQUIRED]

Start Simulator
Start service
Restart the service
Service will panic when incrementing EventsSent metric because it is nil

Last portion of Driver Initialize needs to be moved to Driver Start so SDK can complete it initialization, i.e. create metric counter

Anything else relevant?

The auto-configure script uses curl to make HTTP requests. The curl package is staged in the snap's auto-configure part but not included in the final snap package.

This is because lines 133-134 specifies a list of that needs to be staged and curl is not included.

🐞 Bug Report

Affected Services [REQUIRED]

Is this a regression?

No. The snap hasn't had a stable release.

Description and Minimal Reproduction [REQUIRED]

$ snap install edgex-device-rfid-llrp --edge
edgex-device-rfid-llrp (edge) 2.1.0-dev.15 from Canonical✓ installed
$ edgex-device-rfid-llrp.auto-configure
Dependencies Check: ...
Failed! Please install curl in order to use this script!

🔥 Exception or Error

🌍 Your Environment

Deployment Environment:
Snap

EdgeX Version [REQUIRED]:
2.1.0-dev.15

Anything else relevant?

Readme - https://github.com/edgexfoundry/device-rfid-llrp-go#example-scripts

Folder path " device-rfid-llrp-go/examples/
Script files - command.sh, example.sh, data.sh

Issue:
Script files - example.sh, command.sh, data.sh - mainly used for Add/enable/Disable/Delete RO Sepc - and check device config and capabilities, read data etc.

This files are not executing due json tags name are changed. command to check all supported device commands are available- "curl http://0.0.0.0:59882/api/v2/device/all | jq ."

🚀 Tech Debt

Relevant Package [REQUIRED]

Description [REQUIRED]

Describe the solution you'd like

https://github.com/edgexfoundry/device-rfid-llrp-go/blob/main/internal/driver/driver.go#L712-L713

Note the folder name the SDK uses is provisionwatchers, so the provision_watchers folder must be renamed.

Describe alternatives you've considered

See edgexfoundry/go-mod-bootstrap#302

While developing this device service many bugs were found in the EdgeX Device SDK Go, which have all been marked as addressed. This issue is to remove any workarounds that are no longer needed when using EdgeX Hanoi release.

Issues:
edgexfoundry/device-sdk-go#598
edgexfoundry/device-sdk-go#606
edgexfoundry/device-sdk-go#598
edgexfoundry/device-sdk-go#609

Workarounds:

🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑

Hi everyone, I'm using this device service for reading EPC tags data from different RFID readers. I'm having many problems with Zebra FX7500 reader with two antennas attached(number 1 and 4).
I'm sending a ROSpec.json file attached below, using the command.sh script located in the examples folder.

{
    "ROSpecID": 1,
    "Priority": 0,
    "ROSpecCurrentState": 0,
    "ROBoundarySpec": {
        "StartTrigger": {
            "Trigger": 1,
            "PeriodicTrigger": null,
            "GPITrigger": null
        },
        "StopTrigger": {
            "Trigger": 1,
            "DurationTriggerValue": 500,
            "GPITriggerValue": null
        }
    },
    "AISpecs": [
        {
            "AntennaIDs": [
                0
            ],
            "StopTrigger": {
                "Trigger": 0,
                "DurationTriggerValue": 0,
                "GPITrigger": null,
                "TagObservationTrigger": null
            },
            "InventoryParameterSpecs": [
                {
                    "InventoryParameterSpecID": 1,
                    "AirProtocolID": 1,
                    "AntennaConfigurations": null,
                    "Custom": null
                }
            ],
            "Custom": null
        }
    ],
    "RFSurveySpecs": null,
    "Custom": null,
    "LoopSpec": null,
    "ROReportSpec": {
        "Trigger": 2,
        "N": 0,
        "TagReportContentSelector": {
            "EnableROSpecID": true,
            "EnableSpecIndex": true,
            "EnableInventoryParamSpecID": true,
            "EnableAntennaID": true,
            "EnableChannelIndex": true,
            "EnablePeakRSSI": true,
            "EnableFirstSeenTimestamp": true,
            "EnableLastSeenTimestamp": true,
            "EnableTagSeenCount": true,
            "EnableAccessSpecID": true,
            "C1G2EPCMemorySelectors": {
                "CRCEnabled": true,
                "PCBitsEnabled": true
            },
            "Custom": null
        },
        "Custom": null
    }
}

In particular in the first terminal I'm launching the device-rfid-llrp-go service and in the second one I'm giving these commands:
1)./command.sh add ROSpec ROSpec.json
2)./command.sh enable ROSpec 1

After that I read all different EPC tags in the first terminal, however the problem is when I kill the execution and I relaunch the device service. In this case I don't read any tags and I'll read them again only after I'll restart the reader using its interface webpage. Can anyone give me a hand to solve this issue?

🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑

When an existing non-connected device is discovered under a different IP Address, the address is updated in EdgeX, but the device service attempts to connect to it using the old IP Address. Issue is resolved after restarting the service to get the latest IP from Core Metadata.

Logs:

level=INFO ts=2021-06-09T17:42:56.355155912Z app=edgex-device-rfid-llrp source=driver.go:789 msg="Discover was called."                                                                                                
...
level=INFO ts=2021-06-09T17:42:56.362965848Z app=edgex-device-rfid-llrp source=discover.go:389 host=10.0.0.112 port=5084 msg="Attempting to connect to potential LLRP device..."                                       
...                                      
level=INFO ts=2021-06-09T17:42:56.384388542Z app=edgex-device-rfid-llrp source=discover.go:395 host=10.0.0.112 port=5084 msg="Connection initiated successfully."                                                      
level=INFO ts=2021-06-09T17:42:56.384452862Z app=edgex-device-rfid-llrp source=discover.go:427 msg="Discovered device: &{deviceName:SpeedwayR-10-EF-18 host:10.0.0.112 port:5084 vendor:25882 model:2001002}"          
level=INFO ts=2021-06-09T17:42:56.384624032Z app=edgex-device-rfid-llrp source=discover.go:235 oldInfo="map[host:192.168.0.112 port:5084]" discoveredInfo="&{deviceName:SpeedwayR-10-EF-18 host:10.0.0.112 port:5084 ve
ndor:25882 model:2001002}" msg="Existing device has been discovered with a different network address."     
level=DEBUG ts=2021-06-09T17:42:56.384659789Z app=edgex-device-rfid-llrp source=manageddevices.go:127 msg="Updating managed Device: : SpeedwayR-10-EF-18\n"                                                            
level=INFO ts=2021-06-09T17:42:58.358526671Z app=edgex-device-rfid-llrp source=driver.go:842 msg="Discovered 0 new devices in 2.003289609s."                                                                           
level=DEBUG ts=2021-06-09T17:42:58.358622488Z app=edgex-device-rfid-llrp source=async.go:164 msg="Filtered device addition finished"                                                                                   
level=ERROR ts=2021-06-09T17:43:26.354557118Z app=edgex-device-rfid-llrp source=device.go:141 error="dial tcp 192.168.0.112:5084: i/o timeout" address=192.168.0.112:5084 device=SpeedwayR-10-EF-18 msg="Failed to dial
 Reader."

The latest tag is v1.0.1-dev.7 but the development is now done towards or beyond v2.

Shouldn't we have dev tags for v2 instead?

The device-rfid service currently requires manual configuration of a configuration setting named Driver.DiscoverySubnets before device discovery can be triggered. It's possible to provide this configuration via environment variable override, or by providing a custom configuration.toml file. The service also provides a script called auto-configure.sh which can be used to automatically populate this setting.

The default discovery interval for the service is set to 1 hour, so the current recommendation is to manually trigger discovery after the script has been successfully run.

This issue is a feature request to add support for automatically triggering discovery when Consul notifies the service that the setting has been changed.

This issue is being reported against the initial version of this device service (as it was just recently accepted by the project) as of June '21.

Please refer to the Device Discovery section of the service's README file for more details.

Snaps need to be reworked to release the service for Jakarta

Should enable golangci-lint with default linters + gosec.

See edgexfoundry/edgex-go#3565

edgexfoundry/edgex-go#3880

I started noticing that the time to retry reader connections was becoming increasingly long the more times you connect/disconnect cycle the readers without restarting the device service.

I added extra printouts to the following code in order to track it down a little better

Snippet of interest which shows what i am referring to:

2021/06/29 16:53:42 retry attempt: 5, wait: 2m5s
level=DEBUG ts=2021-06-29T23:55:47.365787007Z app=edgex-device-rfid-llrp source=device.go:151 device=SpeedwayR-11-25-D6 msg="Attempting LLRP Client connection."
level=INFO ts=2021-06-29T23:55:47.366315604Z app=edgex-device-rfid-llrp source=device.go:470 device=SpeedwayR-11-25-D6 msg="Device connection restored."
...
level=ERROR ts=2021-06-29T23:56:45.720013566Z app=edgex-device-rfid-llrp source=device.go:166 error="failed to get next message: failed to read header: EOF" device=SpeedwayR-11-25-D6 msg="Client disconnected unexpectedly."
2021/06/29 16:56:45 retry attempt: 1, wait: 0s
level=DEBUG ts=2021-06-29T23:56:45.720256459Z app=edgex-device-rfid-llrp source=device.go:139 address=10.0.0.53:5084 device=SpeedwayR-11-25-D6 msg="Attempting to dial Reader."
level=ERROR ts=2021-06-29T23:56:45.720555502Z app=edgex-device-rfid-llrp source=device.go:144 error="dial tcp 10.0.0.53:5084: connect: connection refused" address=10.0.0.53:5084 device=SpeedwayR-11-25-D6 msg="Failed to dial Reader."
2021/06/29 16:56:45 retry attempt: 6, wait: 3m15s

Explanation:

• Notice that 2 mins go by waiting for attempt 5 (retry.Slow), when it is able to successfully reconnect.

• A little while later the connection is dropped and immediately, the retry.Quick attempts to reconnect and fails (retry attempt: 1, wait: 0s).

• After this the retry.Slow waits for attempt 6 for over 3 minutes.

  • Because the connection was restored after attempt 5, the retry.Slow should be reset back to attempt 1, or at least the back-off time should be reset.

Full log here

This below command to check all available commands for core-command service but "AddROSpec" not available.
curl http://0.0.0.0:59882/api/v2/device/name/SpeedwayR-11-43-62 | jq '.deviceCoreCommand | .coreCommands[].name'

After discovering a new LLRP reader, the device service does not create a new connection to this device. A restart of the service is required.

Also the device cache is not updated to reflect this new device, so it will continue to be discovered only to be rejected by core-metadata as being a duplicate device.

This is potentially related to the workaround for adding new devices due to previous concerns with provision watchers.

🐞 Bug Report

Affected Services [REQUIRED]

/version endpoint

Is this a regression?

No, think it have been like this a along. Need to also be fixed in Jakarta

Description and Minimal Reproduction [REQUIRED]

run device-snmp
hit localhost:59989/api/v2/version
which result in the following response:

{
    "apiVersion": "v2",
    "version": "to be replaced by makefile",
    "serviceName": "device-rfid-llrp",
    "sdk_version": "0.0.0"
}

Service Version is hard coded to 1.0.0
SDK version is never set

🔥 Exception or Error

🌍 Your Environment

Deployment Environment:

EdgeX Version [REQUIRED]:

Anything else relevant?

While reviewing a new PR for triggering discovery when config changes I ran into the following problem while testing.

When I build the latest version of device-rfid-llrp and run it against the latest/stable edgexfoundry snap, the device service is reporting that it cannot register to the registry because service information is not set.

Steps to reproduce:

1. Install edgexfoundry from latest/stable channel (i.e. Hanoi)

$ sudo snap install edgexfoundry

2. Build this device service (note, it seems this service has already been updated to use go 1.16 even though it hasn't been fully updated to use V2 yet).

3. Run the service:

$ ./cmd/device-rfid-llrp-go --cp=consul.http://localhost:8500 --registry --confdir=./cmd/res
level=INFO ts=2021-06-15T17:37:57.568201468Z app=edgex-device-rfid-llrp source=config.go:193 msg="Loaded configuration from ./cmd/res/configuration.toml"
level=INFO ts=2021-06-15T17:37:57.569435976Z app=edgex-device-rfid-llrp source=config.go:168 msg="Using Configuration provider (consul) from: http://localhost:8500 with base path of edgex/devices/1.0/edgex-device-rfid-llrp"
level=INFO ts=2021-06-15T17:37:57.661931575Z app=edgex-device-rfid-llrp source=config.go:304 msg="Configuration has been pushed to into Configuration Provider (0 envVars overrides applied)"
level=INFO ts=2021-06-15T17:37:57.66202106Z app=edgex-device-rfid-llrp source=registry.go:80 msg="Using Registry (consul) from http://localhost:8500"
level=WARN ts=2021-06-15T17:37:57.662972521Z app=edgex-device-rfid-llrp source=registry.go:140 msg="could not register service with Registry: unable to register service with consul: Service information not set"
level=WARN ts=2021-06-15T17:37:58.665509302Z app=edgex-device-rfid-llrp source=registry.go:140 msg="could not register service with Registry: unable to register service with consul: Service information not set"
level=WARN ts=2021-06-15T17:37:59.667690141Z app=edgex-device-rfid-llrp source=registry.go:140 msg="could not register service with Registry: unable to register service with consul: Service information not set"
level=WARN ts=2021-06-15T17:38:00.669953378Z app=edgex-device-rfid-llrp source=registry.go:140 msg="could not register service with Registry: unable to register service with consul: Service information not set"
^Clevel=WARN ts=2021-06-15T17:38:01.672800492Z app=edgex-device-rfid-llrp source=registry.go:140 msg="could not register service with Registry: unable to register service with consul: Service information not set"
level=ERROR ts=2021-06-15T17:38:01.672854758Z app=edgex-device-rfid-llrp source=bootstrap.go:45 msg="aborted RegisterWithRegistry()"

Per Kamakura planning meeting (Nov 21), each device service should provide a HOWTOTEST.md page that describe how to check the base functionality of the device service with real hardware. These tests should be run manually before each release.

Each device service should also provide a WORKSWITH.md page that lists the actual hardware (make, model, web site link, etc.) that the device service has been tested with and known to work with. Provide enough details on the device/sensor so that an adopter would know where to go to get the same device.

Service needs to use Device SDK 2.0.0 and new profile and device definitions.

The following needs to be added to the Service section

  [Service.CORSConfiguration]
  EnableCORS = false
  CORSAllowCredentials = false
  CORSAllowedOrigin = "https://localhost"
  CORSAllowedMethods = "GET, POST, PUT, PATCH, DELETE"
  CORSAllowedHeaders = "Authorization, Accept, Accept-Language, Content-Language, Content-Type, X-Correlation-ID"
  CORSExposeHeaders = "Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified, Pragma, X-Correlation-ID"
  CORSMaxAge = 3600

🚀 Tech Debt

Relevant Package [REQUIRED]

Description [REQUIRED]

Code here is no longer needed now that it is in the Device SDK
https://github.com/edgexfoundry/device-rfid-llrp-go/blob/main/internal/driver/service.go#L16

Describe the solution you'd like

Remove code and refactor usages to use the code from the SDK.

Describe alternatives you've considered

🚀 Feature Request

Relevant Package

Description

reference: edgexfoundry/edgex-go#4602