...
These items are suggestion for Delhi or later releases that have not yet been fully vetted or voted on by the TSC, but will be reviewed as part of an upcoming meeting. Items in this list may be moved to the roadmap for other releases or discarded entirely.
- The EdgeX configuration today is flat - meaning a single layer of key/value pairs with no groups or other structure. Configuration should, in the future, be categorized and grouped under a sub-structure where possible to simplify the exploration update of and updating the config. For example, all properies related to MongoDB connection (host, username, password, etc) would be grouped under a MongoDB configuration structure.
- Downsampling: It is mentioned that the device service may receive from the device new unattended readings (e.g. in a pub/sub type of scenario). In this case, there should be a setting to specify whether we accept all readings or we decide to downsample because the source is pumping data too fast. This is actually a very common scenario when you deal with high frequency sensor packages.
Command: in order to protect the device from harmful commands, there should be the possibility to set a Min and Max limit for the value that is accepted on every single command. in fact the command service today is rather a hollow simple proxy, but in the future we very much envisioned adding additional security, caching to avoid having to hit the DS when unnecessary, and even grouping command requests for better resource conservation (especially for devices like BLE that get woken up when you hit them).
Data Transformation: This is something we have always considered as a potential in EdgeX – that of a filter, even a small transformation engine between device services and core data. Not a full blown export, but something that serves in a similar fashion and was common across services. We even thought about making it some type of quick CEP/rules engine feeder for those decisions that can’t wait to go through the rest of the layers.