Skip to content

Custom configuration file

Anthony Pauthonnier edited this page Jan 26, 2023 · 1 revision

Custom configuration file

List of existing configuration files
Place the file in /data/solidsense/config/SolidSense-conf-custom.yml
Example : wget https://images.solidsense.io/SolidSense/custom_yml/SolidSense-conf-custom-wirepas-for-N6.yml -O /data/solidsense/config/SolidSense-conf-custom.yml

Structure of the Yaml configuration file

The file includes two main sections:

The 'gateway' section in which global variables can be defined

gateway:

    snapshot_0: snapshot_0.xml #this is the template snapshot do not change it unless full test
    #
    # set of global variables (for convenience and example)
    #
    MQTT_BROKER: YOUR_MQTT_URL
    MQTT_PORT: 1883
    MQTT_USER: YOUR_USER
    MQTT_PASSWORD: YOUR_PASSWORD

The 'services' section that is a list of 'service' that have the following structure

- service:
    type: WirepasSink
    name: sink1
    state: active
    parameters:
        configuration: WirepasSinkConfigurationService
        plugin: WirepasConfigurationService.dp
        plugin_name: WirepasConfigurationService
        system: wirepasSink1
        port: ttymxc1 # physical port
        start: true

    variables:
        NETWORK_ID: $WP_TEST_ID
        NETWORK_CHANNEL: $WP_TEST_CHANNEL
        ADDRESS: $UNIQUE_ADDRESS0
    properties:
        sinkAddress: $ADDRESS
        networkChannel: $NETWORK_CHANNEL
        networkAddress: $NETWORK_ID
        sinkName: $service_name

Services definition

Each 'service' has the following possible parameters

  • 'type': the service class as defined by the SolidSense provisioning system
  • 'name': the internal name of the service. For network interfaces it shall be identical to the device name
  • 'state': the state of the service after provisioning
#   disabled    the service will not be configured and and started
#   auto        the service is configured but the start and activation is done by another process or context dependant
#   interactive the service configuration is to be done via Kura
#   active      the service is configured and activared during provisioning
  • 'override': If true, then the existing default configuration is ignored and the service is refined from scratch, if false then all existing configuration is kept and only the parameters specified in the file are modified.
  • 'parameters'. This is a set of values that are used to configure the service.
  • 'variables'. List of local variable definitions
  • 'properties': This is the list of the Kura properties that are set during the provisioning stage and written in the snapshot_0.xml file. Only modified or additional properties needs to be defined in the file otherwise default values from the baseline snapshot_0.xml file are used.

Among parameters some a class specific but some others are generic, in particular for all services from the KuraService class and subclasses.

  • 'configuration' : Name of the 'configuration' XML block in Snapshot_0 file. It can be prefixed by “org.eclipse.kura..” This prefix is to be ignored.
  • 'plugin' : when the service requires a dynamic plugin add-on in Kura, this is the file name of the compiled dp. (shall be in: /opt/eclipse/kura/packages). Versions suffix are not taken into account.
  • 'plugin_name' : As a dynamic plugin file can include several services, this is the name of the class (in Java) associated with the service
  • 'prefix' : this is the prefix used for properties. If no prefix is defined, then the full property name is to be explicitly given for the property
  • 'system': systemd service associated with the service