docs/4_APIs_and_Services/4.5_Message_Signaling/4_AGL_Service_Signal_Composer/2_Configuration.md

   1 ---
   2 edit_link: ''
   3 title: Configuration
   4 origin_url: >-
   5   https://git.automotivelinux.org/apps/agl-service-signal-composer/plain/docs/part-1/2-Configuration.md?h=master
   6 ---
   7
   8 <!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/apis_services/master/agl-service-signal-composer-developer-guides-api-services-book.yml -->
   9
  10 # Configuration
  11
  12 Configuration defines all in **Signal composer** each signals and sources has
  13 to be defined in it. At start, configuration will be searched in default
  14 binding configuration directory which should be _/var/local/lib/afm/applications/signal-composer/VER/etc/_,
  15 VER is the version of **signal composer**.
  16 Binding search for a file name as _init-daemon*.json_. Others files could be
  17 used to split sections and don't have 1 big fat definitions file.
  18
  19 Saying that you have 4 sections to define:
  20
  21 - **metadata**: Main parts and the only one that can't be in a separates
  22  configuration. This must appears in the main configuration file.
  23 - **plugins** (optional): Declare plugins that will be used by *sources* and
  24  *signals* for the subscription and composition.
  25 - **sources**: Declare **low level** signals sources (eg. low-can, gps, mraa,
  26  ...).
  27 - **signals**: Declare signals, virtuals and raw.
  28
  29 ## Metadata
  30
  31 Here we define some metadata about **signal composer** binding. Fields to configure
  32 are :
  33
  34 - **uid**: self-explanatory
  35 - **version** (optional): self-explanatory
  36 - **api** (optional): name that the binding will be initialized to and later
  37  be accessible by **Application Framework**
  38 - **info** (optional): self-explanatory
  39 - **require** (optional): list of required external apis.
  40
  41 ## Plugins
  42
  43 This section is the only which is optional, it is needed if you develop
  44 specifics C/C++ plugins to be used with signal-composer. LUA and API
  45 consumption does not need plugins.
  46
  47 Default path to search for a plugin is in the binding library directory
  48 in a subdirectory _plugins_ _/var/local/lib/afm/applications/signal-composer/VER/lib/plugins_.
  49 Else you could use the environment variable _CONTROL_PLUGIN_PATH_ with a
  50 semicolon separated list of directory.
  51
  52 Fields are:
  53
  54 - **uid**: Define the plugin name. This is that label that will be used on
  55  **sources** and **signals** callbacks.
  56 - **ldpath** (optional): path to the plugin directory
  57 - **info** (optional): self-explanatory
  58 - **basename**: shared library file name **without** the extension.
  59 - **files** (optional): list of additionnals files. **ONLY NAME** or part of
  60  it, without extension. Don't mix up section object with this key, either one
  61  or the other but avoid using both
  62
  63 ## Sources
  64
  65 A source is a **low level** API that will be consume by the **signal composer**
  66 to be able to expose those signals with additionnals treatments, filtering,
  67 thinning,... and create new virtuals signals composed with basic raw signals.
  68
  69 A source is defined with following fields:
  70
  71 - **uid**: An unique identifier name for thatuid source API.
  72 - **api**: Name of the source API.
  73 - **info** (optional): self-explanatory
  74 - **init** (optional): an **action** to take to initialize a source. May you
  75  have  to call a verb from that API, of create a files etc.
  76 - **getSignals** (optional); an **action** to take to get signals from that
  77  source. These callback will be used for each signals defined later in the
  78  **signals** section. Dedicated arguments for each signal could be defined in
  79  **signals**.
  80 - **files** (optional): list of additionnals files. **ONLY NAME** or part of
  81  it, without extension. Don't mix up section object with this key, either one
  82  or the other but avoid using both
  83
  84 ## Signals
  85
  86 A signal definition could be either a **raw** one or a **virtual** one. A
  87  **virtual signal** is a set of existing **raw signals** associated to an
  88  **action** on reception which will compute the value of the signal.
  89
  90 - **uid**: Unique identifier used inside **signal composer**, used to compose
  91  virtual signals.
  92 - **event**: specify a **raw signal** coming from **low level** sources.
  93  Couldn't be used with **depends** field, only one of them is possible.
  94 - **depends**: specify others signals **id** that compose it (eg: heading is
  95  composed with longitude+latitude signals.). Couldn't be used with **event**
  96  field at same time.
  97 - **retention** (optional): retention duration in seconds
  98 - **unit** (optional): Unit used to exprime the signal
  99 - **frequency** (optional): Frequency maximum at which the signal could be
 100  requested or sent. This is a thinning made at **high level** so not best
 101  suited for performance. Used **low level** native filtering capabilities when
 102  possible.
 103 - **getSignalsArgs**: a JSON object used at subscription time. Meant to enabled
 104  filtering capabilities at subscription and to be able to customize in general
 105  a subcription request by signal if needed.
 106 - **onReceived**: an **action** to take when this signal is received!
 107 - **files** (optional): list of additionnals files. **ONLY NAME** or part of
 108  it, without extension. Don't mix up section object with this key, either one
 109  or the other but avoid using both