Device Service - Configuration

Please refer to the general Common Configuration documentation for configuration properties common to all services.

URIs for Device Service Files

When loading device definitions, device profiles, and provision watchers from a URI, the directory field (ie DevicesDir, ProfilesDir, ProvisionWatchersDir) loads an index file instead of a folder name. The contents of the index file will specify the individual files to load by URI by appending the filenames to the URI as shown in the example below. Any authentication specified in the original URI will be used in subsequent URIs. See the URI for Files section for more details.

...
ProfilesDir = "./res/profiles"
DevicesDir = "http://example.com/devices/index.json"
ProvisionWatchersDir = "./res/provisionwatchers"
...

Device Definition URI Example

For device definitions, the index file contains the list of references to device files that contain one or more devices.

[
    "device1.yaml", "device2.yaml"
]
which results in the following URIs:
http://example.com/devices/device1.yaml
http://example.com/devices/device2.yaml

Device Profile and Provision Watchers URI Example

For device profiles and provision watchers, the index file contains a dictionary of key-value pairs that map the name of the profile or provision watcher to its file. The name is mapped so that the resources are only loaded from a URI if a device profile or provision watcher by that name has not been loaded yet.

{
    "Simple-Device": "Simple-Driver.yaml",
    "Simple-Device2": "Simple-Driver2.yml"
}
which results in the following URIs:
http://example.com/profiles/Simple-Driver.yaml
http://example.com/profiles/Simple-Driver2.yml

Custom Configuration

Device services can have custom configuration in one of two ways. See the table below for details.

Driver:
  MySetting: "My Value"

Secrets

Configuration

All instances of Device Services running in secure mode require a SecretStore to be created for the service by the Security Services. See Configuring Add-on Service for details on configuring a SecretStore to be created for the Device Service. With the use of Redis Pub/Sub as the default EdgeX MessageBus all Device Services need the redisdb known secret added to their SecretStore so they can connect to the Secure EdgeX MessageBus. See the Secure MessageBus documentation for more details.

Each Device Service also has detailed configuration to enable connection to it's exclusive SecretStore

Storing Secrets

Secure Mode

When running an Device Service in secure mode, secrets can be stored in the SecretStore by making an HTTP POST call to the /api/v3/secret API route on the Device Service. The secret data POSTed is stored to the service's secureSecretStore . Once a secret is stored, only the service that added the secret will be able to retrieve it. See the Secret API Reference for more details and example.

Insecure Mode

When running in insecure mode, the secrets are stored and retrieved from the Writable.InsecureSecrets section of the service's configuration.yaml file. Insecure secrets and their paths can be configured as below.

Writable:
  InsecureSecrets:    
    DB:
     SecretName: "redisdb"
     SecretData:
       username: ""
       password: ""
    MQTT:
      SecretName: "credentials"
    SecretData:
       username: "mqtt-user"
       password: "mqtt-password"

Retrieving Secrets

Device Services retrieve secrets from their SecretStore using the SDK API. See Retrieving Secrets for more details using the Go SDK.