Enhancements for Device Services
- Implement dynamic discovery using Provision Watchers
- REST request/response types to be refined as necessary in line with the v2 rework in the core
- Provide clean API for query parameters
- Currently passing entire query string as an extra Attribute
- Make more configuration dynamic (ideally, all of it)
- Including the driver-specific configuration
- Implement command chaining (deviceCommand contains other deviceCommands)
- Allow driver to manage device operational state
- Allow driver to feed back meaningful error information (not just ok/fail) from get/set handlers
- Implement minimum/maximum restrictions on actuation parameters
Testing
- Build-out of blackbox test suite
- Define process for self-certification of device services
- Currently estimated (For Fuji version) N.E.T. January 2020, but any Fuji slippage will push this back
Enhancements for Core EdgeX
- Remove legacy fields in metadata
- ProvisionWatcher: OperatingState
- PropertyValue: Precision, Size
- ResourceOperation: Resource, Object
- ProfileProperty: Units becomes String
- Reduce boilerplate in coreCommands
- All it really needs for each command is the name and whether it's get, set, or both?
- Readings will need to contain type information (ValueDescriptors are going away)
Add field in Event to store query parameters that were used when it was generated- No, we don't support use of QPs to hold extra addressing information
Other discussion topics (for Phoenix F2F)
Load Management in Device Services
Sources of demand
- Device producing data autonomously
- REST 'device' endpoint
- AutoEvents
Shedding demand
For autonomous and REST-driven data, we can feed back errors to the caller, eg 503 unavailable.
For AutoEvents we could apply a scaling factor to the intervals?
Load monitoring
Monitor the number of simultaneous calls to get/put handlers?
Serialize Event submission and monitor the queue length?
Compare time taken to process an AutoEvent with its specified interval?