From 5a611d1db55ce07908e232e5a9afd8843bc1a59c Mon Sep 17 00:00:00 2001 From: Romain Forlot Date: Tue, 19 Sep 2017 19:06:35 +0200 Subject: Documentation format Change-Id: I4feb44fffce727419660c8ac38c77283b52c695d Signed-off-by: Romain Forlot --- book.json | 2 +- docs/part-1/1-Architecture.md | 21 +++++++++++++-------- docs/part-1/2-Configuration.md | 26 ++++++++++++++++---------- docs/part-1/3-Plugins.md | 6 ++++-- docs/part-1/4-SignalComposerAPI.md | 4 ++-- 5 files changed, 36 insertions(+), 23 deletions(-) diff --git a/book.json b/book.json index 3ba5c3d..61c18be 100644 --- a/book.json +++ b/book.json @@ -6,7 +6,7 @@ "author": "IoT.Bzh Team", "website": "http://iot.bzh", "published": "September 2017", - "version": "1.0", + "version": "4.99-EERC1", "gitbook": "3.2.2", "root": "docs", diff --git a/docs/part-1/1-Architecture.md b/docs/part-1/1-Architecture.md index a907882..065d2ec 100644 --- a/docs/part-1/1-Architecture.md +++ b/docs/part-1/1-Architecture.md @@ -8,19 +8,24 @@ Here is a quick picture about the signaling architecture : Key here are on both layer, **low** and **high**. -- **Low level** are in charge of handle a data exchange protocol to decode/encode and retransmit - with an AGL compatible format, most convenient way using **Application Framework** event. These are divised in two parts, which are : +- **Low level** are in charge of handle a data exchange protocol to + decode/encode and retransmit with an AGL compatible format, most convenient + way using **Application Framework** event. These are divised in two parts, + which are : - Transport Layer plug-in that read/write 1 protocol. - Decoding/Encoding part that expose signals and a way to access them. -- **High level signal composer** gathers multiple **low level** signaling sources and creates new - virtuals signals from the **raw** signals defined (eg. signal made from gps latitude and - longitude that calcul the heading of vehicle). It is modular and each signal source should be - handled by specific plugins which take care of get the underlying event from **low level** or - define signaling composition with simple or complex operation to output value from **raw** signals +- **High level signal composer** gathers multiple **low level** signaling + sources and creates new virtuals signals from the **raw** signals defined (eg. + signal made from gps latitude and longitude that calcul the heading of + vehicle). It is modular and each signal source should be handled by specific + plugins which take care of get the underlying event from **low level** or + define signaling composition with simple or complex operation to output value + from **raw** signals There are three main parts with **Signal Composer**: -- Configuration files which could be splitted in differents files. That will define: +- Configuration files which could be splitted in differents files. That will + define: - metadata with name of **signal composer** api name - additionnals configurations files - plugins used if so, **low level** signals sources diff --git a/docs/part-1/2-Configuration.md b/docs/part-1/2-Configuration.md index a68fd62..1bee688 100644 --- a/docs/part-1/2-Configuration.md +++ b/docs/part-1/2-Configuration.md @@ -51,25 +51,31 @@ A source is defined with following fields: - **api**: Name of the source API. - **info** (optionnal): self-explanatory -- **init** (optionnal): an **action** to take to initialize a source. May you have to call a verb from that API, of create a files etc. +- **init** (optionnal): an **action** to take to initialize a source. May you + have to call a verb from that API, of create a files etc. - **getSignals** (optionnal); an **action** to take to get signals from that source. These callback will be used for each signals defined later in the **signals** section. Dedicated arguments for each signal could be defined in **signals**. ## Signals -A signal definition could be either a **raw** one or a **virtual** one. A **virtual signal** is a set of existing **raw signals** associated to an **action** -on reception which will compute the value of the signal. +A signal definition could be either a **raw** one or a **virtual** one. A + **virtual signal** is a set of existing **raw signals** associated to an + **action** on reception which will compute the value of the signal. -- **id**: Unique identifier used inside **signal composer**, used to compose virtual signals. -- **event**: specify a **raw signal** coming from **low level** sources. Couldn't - be used with **depends** field, only one of them is possible. +- **id**: Unique identifier used inside **signal composer**, used to compose + virtual signals. +- **event**: specify a **raw signal** coming from **low level** sources. + Couldn't be used with **depends** field, only one of them is possible. - **depends**: specify others signals **id** that compose it (eg: heading is - composed with longitude+latitude signals.). Couldn't be used with **event** field - at same time. + composed with longitude+latitude signals.). Couldn't be used with **event** + field at same time. - **unit** (optionnal): Unit used to exprime the signal - **frequency** (optionnal): Frequency maximum at which the signal could be - requested or sent. This is a thinning made at **high level** so not best suited for performance. Used **low level** native filtering capabilities when possible. + requested or sent. This is a thinning made at **high level** so not best + suited for performance. Used **low level** native filtering capabilities when + possible. - **getSignalsArgs**: a JSON object used at subscription time. Meant to enabled - filtering capabilities at subscription and to be able to customize in general a subcription request by signal if needed. + filtering capabilities at subscription and to be able to customize in general + a subcription request by signal if needed. - **onReceived**: an **action** to take when this signal is received! diff --git a/docs/part-1/3-Plugins.md b/docs/part-1/3-Plugins.md index 1cfb580..cbc7284 100644 --- a/docs/part-1/3-Plugins.md +++ b/docs/part-1/3-Plugins.md @@ -1,4 +1,6 @@ # Plugins -Plugins are C/C++ shared library that is loaded by the binding to execute some simple routine. Routine could be on reception of a new signal or at sources -initialization time or signal subscription with the respective JSON field **onReceived**, **init** and **getSignals**. +Plugins are C/C++ shared library that is loaded by the binding to execute some +simple routine. Routine could be on reception of a new signal or at sources +initialization time or signal subscription with the respective JSON field +**onReceived**, **init** and **getSignals**. diff --git a/docs/part-1/4-SignalComposerAPI.md b/docs/part-1/4-SignalComposerAPI.md index 6e53800..00dbae4 100644 --- a/docs/part-1/4-SignalComposerAPI.md +++ b/docs/part-1/4-SignalComposerAPI.md @@ -11,8 +11,8 @@ signal-composer get {"signal": "vehicle_speed", "options": {"maximum": 10}} signal-composer get {"signal": "vehicle_speed"} ``` -You apply apply some simple mathematical function by default present in the binding -, by default **last** is used: +You apply apply some simple mathematical function by default present in the +binding, by default **last** is used: - **average**: make an average on X latest seconds. - **minimum**: return the minimum value found in the X latest seconds. -- cgit 1.2.3-korg