Geneva Planning
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?
Harmonized developer experience Application SDK / Device SDK