The following plugins currently only support Cumulocity as a backend, and therefore some Cumulocity specific logic has crept into them
c8y-configuration-plugin
c8y-log-plugin
~c8y-firmware-plugin~
The goal is to make all plugins agnostic so that users can adapt them to the cloud of their preference.
Afterwards the plugins can be renamed to:
[x] tedge-configuration-plugin
[x] tedge-log-plugin
[x] tedge-log-plugin - Task moved to #61
Overview
Move Cumulocity specific logic out of each plugin and to the tedge-mapper
Create a generic interface for plugins which can be used by plugins to set/get configuration related to the plugin
Create a MQTT topic/payload structure to be the public facing tedge interface to trigger alarms (e.g. tedge/command/)
Custom operation should support a message agnostic format
Allow triggering of tedge commands locally
API to download/upload binary information
Open questions
How can cloud specific actions like download or upload binaries be used in a generic fashion inside tedge* plugins (e.g. how to get the token to download the url from Cumulocity). It could be solved by #45
Out of Scope
Reusing the same plugins as child device connectors. This will be covered by a different ticket.
The following plugins currently only support Cumulocity as a backend, and therefore some Cumulocity specific logic has crept into them
c8y-configuration-pluginc8y-log-pluginThe goal is to make all plugins agnostic so that users can adapt them to the cloud of their preference.
Afterwards the plugins can be renamed to:
tedge-configuration-plugintedge-log-plugintedge-log-plugin- Task moved to #61Overview
tedge/command/)Open questions
Out of Scope