ConnectCore Cloud Services setup is provided in the configuration file /etc/cccs.conf:

  • General settings in this file give descriptive information about your device in Remote Manager. You can access this information through the Remote Manager web interface and use it to identify your devices.

  • Connection settings establish the parameters for the connection with Remote Manager, such as enabling reconnection or the time to wait before attempting to reconnect.

  • Service settings allow you to enable file system service, map virtual directories, or identify the path to download the firmware file.

  • System monitor settings manage the status of this feature and the parameters to monitor.

  • Logging settings allow you to establish the logging level.

For more information on how to change the CCCS configuration file, see Customize CCCS configuration.

For more configuration settings, review the cccs.conf configuration file.

See Optimize device data traffic for more information on the configuration required to optimize the device data traffic to reduce the amount of data exchanged.

Device’s client-side certificate settings

Device’s client-side certificate is used as identity certificates in the device. Digi Remote Manager server validates the identity certificate presented by the device during negotiation and, if the server validates the identity certificate, the device is allowed to connect.

To use identity certificates, a device must:

  1. Connect to a URL with client certificate support.

    This is specified in setting url of the cccs.conf file.

  2. Provide a place in its root file system to:

    • store the certificate received from Remote Manager during the first connection

    • read the stored certificate in subsequent connections to Remote Manager

    The certificate path is specified in setting client_cert_path of the cccs.conf file.

When selecting the place to save the received certificate and the URL to connect to bear in mind that:

  • If you change the connection URL from one with client-side certificate support to another without it, your device will no longer be able to communicate with Remote Manager and you must reset the device’s client-side certificate from Remote Manager.

  • If the certificate is corrupted, modified, deleted, or not accessible you must use the Remote Manager interface to reset the device’s client-side certificate.

    This includes:

    • Local or remote firmware updates that remove the client-side certificate.

    • In dual boot systems, client-side certificate only available for one of the banks.

Parameter Value in default configuration file Description



    This URL does not support client-side certificate support.


    This URL is required to utilize the client-side certificate support.

URL is for device communication only. Use for user interaction with Remote Manager.



Absolute path to the device certificate. Must be accessible for read and write.

Only used if url is

The certificate should not be removed or modified. Otherwise the device will not be able to connect to Remote Manager until the certificate is reset.

This means the certificate location:

  • Must not be removed or overwritten during firmware updates

  • Must be accessible for the two banks, rootfs_a and rootfs_b, of dual boot systems.

See Reset the device’s client-side certificate to know how to reset the client-side certificate from Remote Manager interface.

Device type setting

Setting device_type in the cccs.conf file defines the name of the device model. When building your Digi Embedded Yocto project, it is configured with the value of MACHINE variable.

This is an important value when creating and managing Configurations in Remote Manager:

  • A configuration is compatible with one device type.

  • A device type can have multiple associated configurations, but only one of them can be enabled at a time.

See Automate operations with web services for more information about Remote Manager Configurations.

For more information on how to change the device type, see Set the device type.

Firmware version setting

The version reported by your device is used in Remote Manager for Configurations to automatically manage device firmware, settings, and files. See Automate operations with web services.

Setting firmare_version in /etc/cccs.conf determines the firmware version reported to Remote Manager. This value of this setting can be:

  • A version number formed by four numeric values separated by a dot.

    For example:

    firmare_version =
  • Absolute path to an existing file in the system with the version.

    For example:

    firmware_version = "file:///etc/sw-versions"

If the path to a file is specified, its content must meet the follwing requirements:

  1. The version must be in the first line.

  2. The version must be four numeric values separated by a dot.

  3. The first line can contain only the version or follow a property format, where name and value are separated by a white space or a =.

    For example:

    firmware =


If this setting is not defined, or the specified file does not exist, the version is read from /etc/sw-versions.

Services settings

Firmware update service settings

There are two possible firmware update strategies:

  • Buffered update.

    The update package is downloaded to the configured path in firmware_download_path and later used to update the device.

    This strategy is supported for single and dual boot system devices. It is the default for single boot system devices and for dual boot system devices with read-only root file system.

  • On-the-fly update.

    The update package is written directly to the non-active partition while being downloaded.

    This strategy is the default for dual boot system devices with read-write root file system and is not available for single boot system devices.

Parameter Value in default configuration file Description



Absolute directory path to download the update package from Remote Manager.

The value must be an existing directory with writing permissions for single boot systems or if on-the-fly updates are disabled.

You must have enough space in the configured firmware download path for the SWU package.

By default:

  • For dual boot systems:

    • /home/root of the active rootfs block, for read-write root file systems.

    • /mnt/update for read-only root file systems.

  • For single boot systems the update partition, mounted on /mnt/update.

    See Wipe the update partition for information on how to wipe this partition.

If empty or not defined:

  • And on_the_fly is false, firmware update feature is disabled for dual boot systems.

  • Firmware update feature is disabled for single boot systems.



Boolean value to enable/disable on-the-fly updates.

If it is enabled, the service downloads the software update package in chunks and writes them directly to the partition.

By default:

  • For dual boot systems:

    • true for read-write root file systems.

    • false for read-only root file systems.

  • For single boot systems, false.

Only supported in dual boot system devices.

Firmware update service default configuration for read-only root file systems in dual boot devices does not work.

You must change the configuration to either:

  • Enable on-the-fly updates, on_the_fly to true, or

  • Use buffered updates with a firmware_download_path pointing to a writable directory with enough space for update packages.

System monitor service settings

System monitoring allows you to remotely monitor some interfaces and system parameters that determine device health.

By default, the service takes a sample of each monitored parameter and interface every 30 seconds and stores the data temporarily in the device. When there are two stored samples of each monitored parameter, the service uploads all the samples. That is, the device uploads system monitor samples every 60 seconds.

This default behavior can be modified via the ConnectCore Cloud Services (CCCS) configuration file, cccs.conf.

Parameter Value in default configuration file Description



Boolean value to enable/disable the system monitor service.



Frequency in seconds at which the service gathers system information to store in the buffer before uploading.



Number of samples of each channel to store before uploading to Remote Manager.


{ "*" }

List of channels to monitor and upload to Remote Manager.

See cccs.conf for more information.

Data backlog settings

This feature stores the samples locally when it is not possible to upload them. Samples to store include System Monitor and custom samples:

  1. If samples cannot be uploaded, they are saved in the cccs subdirectory located inside the data_backlog_path directory.

    • System Monitor samples:

      • Are stored when there are at least 250 samples.

      • Each file contains 250 data points, the maximum allowed by Digi Remote Manager in one request.

      • If samples cannot be sent nor saved in the configured directory, the maximum number of System Monitor samples in the collection is five times the maximum per request, 1250. Older samples are removed from the collection when this limit is reached.

    • Custom samples:

      • Typed data points:

        • Are stored in a file, with a maximum of 250 samples, immediately after an upload fails.

        • If the collection to send contains more than 250 samples, the rest remains in the collection.

        • If samples cannot be sent nor saved in the configured directory, they remain in the collection. You must create custom code to remove them from the collection.

      • Binary data points:

        • One request contains one binary sample (buffer or file).

        • If a binary sample cannot be sent, it is stored in a file.

  2. The service checks for new stored samples to upload in random intervals between 60 and 120 seconds.

    • If there are stored samples to upload, the oldest stored data is sent. It can be System Monitor or custom samples, typed or binary data points.

    • Only one file is sent per interval.

    • If stored data cannot be sent:

      • Data remain in the same location to retry later.

      • The interval to retry is doubled and increased by a random between 0 and 60 seconds. The maximum interval is 1 hour.

      • When stored data is successfully sent, the interval is restored to a value between 60 and 120 seconds.

  3. The maximum amount of data to store is configured in data_backlog_size setting. After trying to send stored data, the service checks the current size of remaining data:

    • If it is bigger than the configured maximum, the oldest data (System Monitor or custom data) is removed until the size of the remaining data is equal to or less than the maximum configured.

    • If it is equal to or less than than the maximum, it continues.

Parameter Value in default configuration file Description



Absolute path to store data that could not be uploaded to the server including:

  • System Monitor samples

  • Custom samples

Stored data in the backlog is sent when it is possible and removed after being uploaded.

The path must be an existing directory or empty. If it is empty or not defined, this feature is disabled.



Maximum size in KB of the data backlog before the oldest entries are purged.

If size is 0, this feature is disabled.

File system service settings

You can enable or disable the access to the root file system of your devices from Remote Manager web service APIs, as well as the directories that are visible from remote.

By default, this service is enabled and maps the following directories:

  • home maps the contents of /home/root

  • tmp maps the contents of /tmp

  • update maps the contents of /mnt/update (only for single boot system devices)

  • media maps the contents of /run/media

Parameter Value in default configuration file Description



Boolean value to enable/disable file system service.


    vdir {
        name = "home"
        path = "/home/root"

    vdir {
        name = "tmp"
        path = "/tmp"

    vdir {
        name = "update"
        path = "/mnt/update"

    vdir {
        name = "media"
        path = "/run/media"

List of remotely accessible directories.