Allow defining device commands more broadly not limiting them to getter/setter methods only

[fakhir]

🚀 Feature Request

Relevant Package

This feature request relates to the core-metadata and core-command services, specifically relating to limitations of the device commands schema within the device profile.

Description

EdgeX strictly defines device commands in terms of getter/setter functions for value-descriptors. Other clouds, like Azure/AWS, define device commands more broadly in terms of methods (not limited to getters/setters only) which may take multiple parameters. Given that getters and setters are special cases of methods, the EdgeX schema is more restrictive and does not allow a direct mapping into the device command defined by clouds such as Azure/AWS.

For example, if there is an Azure device method such as reboot(delay), which reboots after a certain delay. How will this map to an EdgeX device command -- it wouldn't feel that intuitive to say that this is a delay setter. Or maybe another example can be get_log(date, severity) -- this get method would actually have to be a set method in EdgeX to be able to take two parameters.

Describe the solution you'd like

The solution may require expanding the device profile schema to allow defining methods which may take multiple parameters and which may return certain values.

Describe alternatives you've considered

I've been trying to define a general scheme for mapping Azure methods onto EdgeX methods but haven't been able to come up with a clean way to do this.

[cloudxxx8]

For now, we allow additional URL query parameters to be passed to the Device Service.
This provides the capability to send more argument to the south bound.

[cloudxxx8]

#3753 and #3754 are opened to provide more flexibility.

[fakhir]

Thanks -- these enhancements would allow a cleaner solution to our problem.

Are these enhancements proposed as a short-term workaround? I would just want to confirm whether others feel that there is a problem with the schema here which may need to be addressed more thoroughly in the long-term.

[tonyespy]

@fakhir we actually just discussed this in the Core WG. These enhancements are not planned for the current development release as we're 10 days out from code freeze.

The proper venue for discussing potential changes for future releases will be our next virtual planning meetings scheduled for the first week of November.