diff options
| -rw-r--r-- | book.json | 4 | ||||
| -rw-r--r-- | docs/0-Doc-Revisions.md | 1 | ||||
| -rw-r--r-- | docs/cover.jpg | bin | 260913 -> 259959 bytes | |||
| -rw-r--r-- | docs/cover_small.jpg | bin | 13436 -> 13366 bytes | |||
| -rw-r--r-- | docs/part-1/0_Abstract.md | 3 | ||||
| -rw-r--r-- | docs/part-1/1-Architecture.md | 8 | ||||
| -rw-r--r-- | docs/part-1/2-Configuration.md | 58 | ||||
| -rw-r--r-- | docs/part-1/4-SignalComposerAPI.md | 21 |
8 files changed, 69 insertions, 26 deletions
@@ -5,8 +5,8 @@ "keywords": "AGL, Development, Iotbzh", "author": "IoT.Bzh Team", "website": "http://iot.bzh", - "published": "September 2017", - "version": "4.99-EERC1", + "published": "December 2017", + "version": "4.99-EERC4", "gitbook": "3.2.2", "root": "docs", diff --git a/docs/0-Doc-Revisions.md b/docs/0-Doc-Revisions.md index a2ae277..b496b02 100644 --- a/docs/0-Doc-Revisions.md +++ b/docs/0-Doc-Revisions.md @@ -4,3 +4,4 @@ Document revisions | Date | Version | Designation | Author | |-------------|---------|--------------------------------------|-------------------------| | 19 Sep 2017 | 4.99-EERC1 | Initial release | R. Forlot [ Iot.bzh ] | +| 11 Dec 2017 | 4.99-EERC4 | Update and add subscribe/unsubscribe instructions | R. Forlot [ Iot.bzh ] | diff --git a/docs/cover.jpg b/docs/cover.jpg Binary files differindex 9e98734..ea03df1 100644 --- a/docs/cover.jpg +++ b/docs/cover.jpg diff --git a/docs/cover_small.jpg b/docs/cover_small.jpg Binary files differindex c6b1f92..5fcb1de 100644 --- a/docs/cover_small.jpg +++ b/docs/cover_small.jpg diff --git a/docs/part-1/0_Abstract.md b/docs/part-1/0_Abstract.md index beb610a..04dfcb2 100644 --- a/docs/part-1/0_Abstract.md +++ b/docs/part-1/0_Abstract.md @@ -6,4 +6,5 @@ You will find in this documentation a presentation about Signal Composer architecture. Signal Composer is an Application Framework binding meant to facilitate handling signaling, by compose, divide and create new virtuals signals from RAW signals coming from _low level_ binding that handle read/write, -encode/decode on different protocols that a car could use (CAN, LIN, Ethernet, GPS, i2c, ...). +encode/decode on different protocols that a car could use (CAN, LIN, Ethernet, +GPS, i2c, ...). diff --git a/docs/part-1/1-Architecture.md b/docs/part-1/1-Architecture.md index 2a2417e..57a2927 100644 --- a/docs/part-1/1-Architecture.md +++ b/docs/part-1/1-Architecture.md @@ -22,7 +22,8 @@ Key here are on both layers, **low** and **high**. define signaling composition with simple or complex operation to output value from **raw** signals -A transport plug-in is a shared library that shares a common API to be compatible with **low level** services that is: +A transport plug-in is a shared library that shares a common API to be +compatible with **low level** services that is: - **open/close**: method to open a handle which could be a socket, file or device by example. @@ -50,7 +51,10 @@ Here is a little terminology guide to set the vocabulary: - **action**: a function called at a certain time - **callbacks**: a function called at a certain time - **event**: the raw event that materialize the signal -- **sources**: a binding API name +- **plugins**: a C/C++ code with functions that be called by signal composer + service +- **sources**: an external binding API that generate signals for the signal + composer service - **signals**: an event generated by the **Application Framework** - **virtual signals**: a signal composed of **raw signals** with value calculated by a **callbacks** diff --git a/docs/part-1/2-Configuration.md b/docs/part-1/2-Configuration.md index 1bee688..5e0ca2d 100644 --- a/docs/part-1/2-Configuration.md +++ b/docs/part-1/2-Configuration.md @@ -1,14 +1,19 @@ # Configuration -Configuration defines all in **Signal composer** each signals and sources has to be defined in it. -At start, configuration will be searched in default binding configuration directory which should be -_/var/lib/afm/applications/signal-composer/1.0/etc/_. Binding search for a file name as _init-daemon*.json_. Others files could be used to split sections and don't have 1 big fat definitions file. +Configuration defines all in **Signal composer** each signals and sources has +to be defined in it. At start, configuration will be searched in default +binding configuration directory which should be _/var/lib/afm/applications/signal-composer/1.0/etc/_. +Binding search for a file name as _init-daemon*.json_. Others files could be +used to split sections and don't have 1 big fat definitions file. Saying that you have 4 sections to define: -- **metadata**: Main parts and the only one that can't be in a separates configuration. This must appears in the main configuration file. -- **plugins** (optionnal): Declare plugins that will be used by *sources* and *signals* for the subscription and composition. -- **sources**: Declare **low level** signals sources (eg. low-can, gps, mraa, ...). +- **metadata**: Main parts and the only one that can't be in a separates + configuration. This must appears in the main configuration file. +- **plugins** (optionnal): Declare plugins that will be used by *sources* and + *signals* for the subscription and composition. +- **sources**: Declare **low level** signals sources (eg. low-can, gps, mraa, + ...). - **signals**: Declare signals, virtuals and raw. ## Metadata @@ -16,30 +21,34 @@ Saying that you have 4 sections to define: Here we define some metadata about **signal composer** binding. Fields to configure are : -- **label**: self-explanatory +- **uid**: self-explanatory - **version** (optionnal): self-explanatory -- **api**: name that the binding will be initialized to and later be accessible by **Application Framework** +- **api** (optionnal): name that the binding will be initialized to and later + be accessible by **Application Framework** - **info** (optionnal): self-explanatory - **require** (optionnal): list of required external apis. -- **files** (optionnal): list of additionnals files. **ONLY NAME** or part of it without extension. These - files are loaded to find sections: *plugins*, *sources* and *signals*. ## Plugins -This section is the only which is optionnal, it is needed if you develop specifics C/C++ plugins -to be used with signal-composer. LUA and API consumption does not need plugins. +This section is the only which is optionnal, it is needed if you develop +specifics C/C++ plugins to be used with signal-composer. LUA and API +consumption does not need plugins. -Default path to search for a plugin is in the binding library directory in a subdirectory _plugins_ -_/var/lib/afm/applications/signal-composer/1.0/lib/plugins_. Else you could use the environment variable _CONTROL_PLUGIN_PATH_ with a semicolon separated list of -directory. +Default path to search for a plugin is in the binding library directory +in a subdirectory _plugins_ _/var/lib/afm/applications/signal-composer/1.0/lib/plugins_. +Else you could use the environment variable _CONTROL_PLUGIN_PATH_ with a +semicolon separated list of directory. Fields are: -- **label**: Define the plugin name. This is that label that will be used on **sources** and - **signals** callbacks. -- **version** (optionnal): self-explanatory +- **uid**: Define the plugin name. This is that label that will be used on + **sources** and **signals** callbacks. +- **ldpath** (optionnal): path to the plugin directory - **info** (optionnal): self-explanatory - **basename**: shared library file name **without** the extension. +- **files** (optionnal): list of additionnals files. **ONLY NAME** or part of + it, without extension. Don't mix up section object with this key, either one + or the other but avoid using both ## Sources @@ -49,13 +58,18 @@ thinning,... and create new virtuals signals composed with basic raw signals. A source is defined with following fields: +- **uid**: An unique identifier name for thatuid source API. - **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. - **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 + 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**. +- **files** (optionnal): list of additionnals files. **ONLY NAME** or part of + it, without extension. Don't mix up section object with this key, either one + or the other but avoid using both ## Signals @@ -63,13 +77,14 @@ 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 +- **uid**: 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. +- **retention** (optionnal): retention duration in seconds - **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 @@ -79,3 +94,6 @@ A signal definition could be either a **raw** one or a **virtual** one. A 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! +- **files** (optionnal): list of additionnals files. **ONLY NAME** or part of + it, without extension. Don't mix up section object with this key, either one + or the other but avoid using both diff --git a/docs/part-1/4-SignalComposerAPI.md b/docs/part-1/4-SignalComposerAPI.md index 00dbae4..dc47f01 100644 --- a/docs/part-1/4-SignalComposerAPI.md +++ b/docs/part-1/4-SignalComposerAPI.md @@ -1,5 +1,24 @@ # Signal Composer API +## subscribe/unsubscribe + +Using subscribe you can get update on change for signals you chose and you can +using wildcard to subscribe several signals in the same time. + +```json +signal-composer subscribe {"signal": "rear_left*"} +ON-REPLY 1:signal-composer/subscribe: {"jtype":"afb-reply","request":{"status":"success","uuid":"3d4b743b-7ac6-4d3c-8fce-721107f9dee5"}} +``` + +Then event comes up like the following: + +```json +ON-EVENT signal-composer/257b343e-8ea9-4cd7-8f9e-1904fa77f8f2({"event":"signal-composer\/257b343e-8ea9-4cd7-8f9e-1904fa77f8f2","data":{"uid":"rear_left_door","event":"low-can\/messages.doors.rear_left.open","timestamp":4833910845032292484,"value":false},"jtype":"afb-event"}) +``` + +Unsubscribe happens the same way. When no more signals are holded by the client +then it unsubscribe from the *AGL Application Framework* event handle. + ## get You can get a signal value be requesting the API with the verb *get*: @@ -29,5 +48,5 @@ Verb **loadConf** let you add new files to be able to add new **sources** or **signals**. ```json -signal-composer loadConf {"filepath": "/path/to/your/json/file.json"} +signal-composer loadConf {"file": "/path/to/your/json/file.json"} ``` |
