A customer has about 60 different possible configurations types for a device type and he wants to be able to update those configs on ad-hoc basis.
I was looking at our documentation and thought that potentially the best options would be to
Define a new config snapshot and the configuration file would contain all the possible configs.
Or use or c8y_DownloadConfigFile property which seems to allow sending a file to the device
However, I am facing several issues.
With number 1, once I have configured my config snapshot, I cannot find a way to find this config in the Configuration of my device; so basically how do you send an Operation using a defined config snapshot ? (with possibility to edit the config)
We have three different ways to implement configuration for devices: Text based, legacy file based, and typed file based. For a use case with more than one configuration type in a device only the last one will work as it allows management of separate configuration files based on a type. You can find details about how all of these should be implemented on a device here: [Device management library - Cumulocity IoT Guides](Device management library - configuration).
In your specific case problem number 1 seems to be caused by incorrect or incomplete declarations in the device managed object. Please ensure that the fragments c8y_SupportedConfigurationsc8y_SupportedOperations are entered as documented and respective fragments for the configuration type in the format c8y_Configuration_<config type> are added.
Regarding problem number 2: Please remember that c8y_SupportedOperations is defined as an array of strings. Please only add the operation fragment type strings there. The c8y_SupportedConfigurations belongs on the top level, not nested in something else.
In parallel the text-based configuration is used, that’s the reason you see two tabs. This can be achieved by setting the c8y_Configuration fragment on root level:
So you can use file-based (type) and text-based configuration in parallel if the agent supports that.
I can now see the Configurations menu. However, I still do not have the button to send the configuration to the device (my url binaries is correct). I thought by adding the c8y_DownloadConfigFile I would be able to see the button?
Also, it now offers me the 2 configurations snapshot i created for my device type. But it seems i cannot update the values of the configurations before sending them? (maybe that s because i dont have a send button)
The c8y_SupportedOperations fragment should contain the fragment types of all supported operations. The configuration type is not relevant here those belong in the c8y_SupportedConfigurations fragment. The two operations relevant for typed file based configuration are c8y_UploadConfigFile (Device management library - Cumulocity IoT Guides) for devices to upload their current configuration status to the platform and c8y_DownloadConfigFile (Device management library - Cumulocity IoT Guides) for devices to download a configuration from the platform and install it. Note that these are named from a device perspective. In the UI the c8y_DownloadConfigFile operation enables the upload to device button and the c8y_DownloadConfigFile operation enables the download from device button. Your c8y_SupportedOperations fragment should look like this:
For typed file-based configuration the c8y_DownloadConfigFile is not relevant in the device’s managed object. There is the c8y_Configuration_<config type> fragment which a device should set when it has downloaded and installed a configuration file. It contains information when and from where a config file was installed. See here for details: Device management library - Cumulocity IoT Guides. If you are interested in previewing the installed configuration then the device must create an event and attach the configuration file as event binary as described here: Device management library - Cumulocity IoT Guides
We do not offer any way to edit these files in our UI. Editing configuration files must be done externally (e.g. with a text editing program locally on your computer) before the configuration file is uploaded to the platform.
Ok so in my case I dont want a device to send a configuration file to the platform. I only want for the platform to upload a config file to the device.
So basically I m only interested into the c8y_DownloadConfigFile
I was expecting for the user to:
define a configuration with multiple param and values
create an operation to send those configs to the device
for the device to update its config with the newest values and set to SUCCESSFUL
If I try to only use c8y_DownloadConfigFile then I dont have the button to send the config to the devices. I believe, this is because the platform expects for the configuration file to be sent by the c8y_UploadConfigFile first.
For example, here,
While my binary exist at the specified url, the UI does not offer me to send this config file to the device.
I believe i would need to add the c8y_UploadConfigFile , and then for the device to send the agent_conf file via an event with binaries; is that correct? If this is the case, I do not understand why we need to have a fragment url in c8y_DownloadConfigFile if this url is actually not being used?
Coming back to your last comment; is not the point of offering a configuration menu in our UI is to allow for a user to change those configurations? If we cannot edit the configurations in the UI, then he must always do it locally in another program which does not seem very user friendly. Does it also mean the user needs to have a role giving him access to the file repository menu in the Admin app?
As far as I understood this is what you want achieve.
A few additional comments:
As I wrote earlier: The c8y_DownloadConfigFile fragment in a managed object is not relevant for typed file-based configuration. c8y_DownloadConfigFile is the fragment type of the OPERATION to install a configuration. A device can announce its capability to handle such operations by including it in its c8y_SupportedOperations fragment. The c8y_DownloadConfigFile fragment in the device managed object is only relevant for legacy file-based configuration. There it is used for devices to communicate their current status of installed configuration to the platform. For typed file-based configuration this is handled with the c8y_Configuration_<config type> fragment I also mentioned in an earlier post.
The point of the configuration functionality is to monitor and manage configuration installed on devices. Editing or creating the file content in our UI is not intended. In fact devices are often quite particular about the format of such files. Devices may require specific encoding, specific line or file delimiters, or even specific spacing. This often goes beyond any standards for typical configuration files and thus becomes unmanageable for us in a generic way. Configuration files are created much more conveniently in device specific tooling. Users that want to upload configuration files to the platform must of course have the respective permissions to create the necessary binaries.