edgexfoundry / device-sdk-c Goto Github PK

ProvisionWatchers specify a (potentially wildcarded) mapping between device identifiers and device profile names. This can be used during discovery to automatically determine the correct profile to use for a newly discovered device.
This could be presented to the implementor as a utility function which would return a profile name given a device identity, or by allowing the add-device function to be called without specifying a profile name.

selected via attribute (currently "floatEncoding") on the propertyvalue

Implement a 'binary' data type. This to be marshalled as CBOR: see https://tools.ietf.org/html/rfc7049

See also edgexfoundry/edgex-go#1404

When setting the "origin" timestamp on an event, this should be expressed in nanoseconds. They should also be strictly increasing including in the scenario where we aren't getting real ns resolution.
(ie if new timestamp <= old timestamp, use (old ts + 1) instead. Safe to assume we aren't going to exceed 1 call per nanosecond over any length of time)

We should have something describing what each of the various available configuration options do. And for the current release note which are NYI.
Also remove any that are not used and not going to be used, eg Service/HealthCheck.

Currently we have a hardcoded wait time and retry limit. These should be parameters to start()

As done for Go microservices in https://github.com/edgexfoundry/edgex-go/issues/1014

Add an interface to the registry for retrieval of service endpoints. Implement for Consul. Use this in the SDK instead of getting them from configuration, if the registry is enabled.

See also edgexfoundry/edgex-go#946

See edgexfoundry/go-mod-core-contracts#59 for context.

References to the properties in the above issue need to be changed in device-sdk-c for integration.

The "Service" field of a ScheduleEvent can be used to indicate that it is to be actioned by the device service rather than support-scheduler

Assuming edgexfoundry/go-mod-core-contracts#27
and edgexfoundry/go-mod-core-contracts#40
are implemented, we'll want to rework the json (un)marshalling code for Device.

Provide the /config and /metrics REST endpoints as used by sys-mgmt-agent.
For glibc targets, provide heap metrics using hooks for malloc etc.

See edgexfoundry/edgex-go#1101

Add a callback to the registry interface so that the service may be notified that configuration has changed.
Implement this for consul using blocking queries.
Make the SDK configuration dynamic where practical.

See also edgexfoundry/device-sdk-go#303

• Make type names lowercase in example and documentation, eg. float32 not Float32
• API methods should set *err to EDGEX_OK in all nonerror cases.
• Log when GET handler fails.
• Log CSDK version on startup.

CSDK has the Logging/RemoteURL config setting for both enabling use of the logging service and specifying its location. This is different to other EdgeX services which have Logging/EnableRemote as a boolean switch, and derive the location from [Clients] config or the Registry. The CSDK needs to be aligned on this.

When edgexfoundry/edgex-go#1471 lands, the SDK should no longer be creating valuedescriptors when it uploads Device Profiles. Remove all of the code related to them.

Bitwise operations on unsigned ints -
transformed-value = (original-value & MASK) >> SHIFT

Each integral configuration value is currently typed as int64_t, and clearly this is not always appropriate. Most if not all should be unsigned, and port numbers in particular are 16-bit. This propagates through to some function parameters, eg the port number in edgex_consul_client_register_service().

core-metadata calls on this endpoint to notify the DS of added / deleted / updated devices.
JSON fields are id (the id of the device concerned) and type (in this issue we only address the "DEVICE" type).
Note that the only device updates in scope for Delhi are changes to the administrative state.

Other EdgeX services log:

Service started in: ...
Listening on port: ...

edgex_device_service_start() should do the same.

• "Devices" section should be "Device"
• Schedules and ScheduleEvents should be configured using Array of Tables notation

If the registry/consul is enabled on service startup, try to read initial configuration settings from consul.

In order for this feature to work, the settings for the device service need to be injected into consul via core-config-seed, or some other out-of-band mechanism.

The SDK continues after failures in creation of devices or device profiles. It should instead abandon and return an error code.

IE, edgex_device_commandrequest becomes
{
const char *deviceResourceName;
const edgex_nvpairs *attributes;
const edgex_propertytype type;
}

In addition the device name is to be passed to the get/set functions, as we do in Go.

See also edgexfoundry/device-sdk-go#19
Issue a command with arguments after a device is added or before it is removed.
Commands and arguments defined in the Device configuration as
AddDeviceCmd / AddDeviceArgs and RemoveDeviceCmd / RemoveDeviceArgs
(Arguments in JSON just as they are in a REST request).

Extend the device management API to allow retrieval of individual devices by name or id.
edgex_device_get_device ()
edgex_device_get_device_byname ()

Add the following functions for management of devices and device profiles:

edgex_device_devices()
edgex_device_remove_device()
edgex_device_remove_device_byname()
edgex_device_update_device()

edgex_device_add_profile()
edgex_device_profiles()
edgex_device_remove_profile()
edgex_device_remove_profile_byname()
edgex_device_update_profile()

Update the edgex_device_add_device() function to return the id of the newly created device.

Remove support for [[DeviceList]] [[Schedules]] [[ScheduleEvents]] and [[Watchers]] from the configuration file.
Rename the profilesDir configuration element as provisioningDir
Read files in {provisioningDir}/profiles, {provisioningDir}/devices, {provisioningDir}/schedules etc and populate metadata from them.

If the driver does not fill in the origin field for a reading, the SDK should. Readings can take the same timestamp as their Event.

Assertions are an attribute in a device resource's value PropertyValue which specify a string value which the result is compared against. If the comparison fails, then the result is set to a string of the form “Assertion failed for device resource: , with value: ”, this also has a side-effect of setting the device operatingstate to DISABLED. In the case of the single device /command endpoint, a 500 status code is also returned. If the all form of the /command endpoint is used an assertion failure will return a 200 status, and it's the responsibilty of the client to check each reading for assertion failures.

As assertions are operations on results after they've been transformed into the string to be passed in the Reading, assertions cannot as currently defined, be applied to binary readings which result in an array of bytes vs. a string result in the Reading.

Instead of containing a reference to a device resource (the device resource's name is in the "object" field), a resourceoperation may refer to other (profile) resources. In this case the "resource" field will be set to the name of the profile resource.

See the sample profile DENT.Mod.PS6037.profile.yaml in device-modbus for an example.

As part of the Edinburgh release, there are planned changed to the ScheduleEvent object.

A new owner field is being added which is used to determine what service actually processes the ScheduleEvents as read from Core Metadata.

The existing service field is going to re-named to target, as this more accurately describes the purpose of the field.

The device SDK will now need to query the ScheduleEvents with owner matching its service name if and only if the device service has been configured for internal scheduling. I'm not sure if internal scheduling is controlled via a configuration option. I suppose it also could just be handled by whether or not there are ScheduleEvents with owner=.

Consul support then becomes an implementation of this. The command line option enabling the registry can also specify which implementation to use and its location. eg in a URL: --registry=consul://localhost:8500

Passing the configuration to the device profile init method as const is not helpful
Reporting of schedule interval in the debug configuration dump is broken
Dependency on libm needs to be specified

See also edgexfoundry/device-sdk-go#245

In ResourceOperation, resource->command and object->resource.
Also may need to rework Property Units if they become simplified as proposed.

When obtaining a device profile from core-metadata we should check at least the following:

• Values given for transform parameters should be able to be parsed, and should be of appropriate type (eg a "scale" of "0.1" is okay for floating point readings but not integers).
• Value type names should be recognized.

Errors should cause the current operation to fail.

Change the device profile structs so that elements are stored as int, float, enum etc instead of string, where that is useful for us. For example value types and transform parameters.
Rework the JSON reader/writer accordingly.

More recent revisions of the device service specification call for GET commands on the device endpoint to return EdgeX Events rather than a name-value pair for the reading. The SDK needs to be updated in this regard.

Mappings for set operations are defined separately in the device profile
Transforms should be the reverse operations to the GET versions

If using the registry, unregister ourself from it as part of stopping the service.
See also edgexfoundry/device-sdk-go#217

As of edgexfoundry/edgex-go#1029 deviceResources are no longer called deviceObjects.

If there is no hostname configured, use eg. uname(2) to determine it.

The following transforms to be applied in order if specified for numeric readings:
base – a base value which is raised to the power of the reading value
scale – a multiplicative factor applied to the reading
offset – an additive factor applied to the reading

The current handler for the device endpoint only allows for commands that match resources (the grouping construct in the device profile). A command should also be able to refer directly to a single deviceResource.

The driver may need to be informed of device additions, removals and updates.
We already have a disconnect callback: implement this for device deletions and add callbacks for update and addition.
See edgexfoundry/device-sdk-go#276