iotagent-node-lib 2.15.1 → 2.19.0

package/.github/workflows/ci.yml

@@ -6,6 +6,7 @@ name: CI
   pull_request:
     branches:
       - master
+  workflow_dispatch:
 jobs:
   lint-markdown:
     name: Lint Markdown
@@ -50,9 +51,9 @@ jobs:
     strategy:
       matrix:
         node-version:
-          - 10.x
           - 12.x
           - 14.x
+          - 16.x
     steps:
       - name: Git checkout
         uses: actions/checkout@v2
@@ -88,3 +89,18 @@ jobs:
         uses: coverallsapp/github-action@master
         with:
           github-token: ${{ secrets.GITHUB_TOKEN }}
+
+  dispatch:
+    needs: unit-test
+    if: ${{ github.ref == 'refs/heads/master'  && github.event_name == 'push' }}
+    strategy:
+      matrix:
+        repo: ['telefonicaid/iotagent-ul', 'telefonicaid/sigfox-iotagent', 'telefonicaid/iotagent-json', 'telefonicaid/lightweightm2m-iotagent', 'telefonicaid/iotagent-manager']
+    runs-on: ubuntu-latest
+    steps:
+      - name: Repository Dispatch
+        uses: peter-evans/repository-dispatch@v1
+        with:
+          token: ${{ secrets.REPO_ACCESS_TOKEN }}
+          repository: ${{ matrix.repo }}
+          event-type: lib-update

package/.readthedocs.yml

@@ -0,0 +1,7 @@
+version: 2
+
+mkdocs:
+  configuration: mkdocs.yml
+
+python:
+  version: 3.6

package/CHANGES_NEXT_RELEASE

@@ -1 +0,0 @@
-

package/README.md

@@ -8,6 +8,7 @@
 [![CI](https://github.com/telefonicaid/iotagent-node-lib/workflows/CI/badge.svg)](https://github.com/telefonicaid/iotagent-node-lib/actions?query=workflow%3ACI)
 [![Coverage Status](https://coveralls.io/repos/github/telefonicaid/iotagent-node-lib/badge.svg?branch=master)](https://coveralls.io/github/telefonicaid/iotagent-node-lib?branch=master)
 ![Status](https://nexus.lab.fiware.org/static/badges/statuses/iot-node-lib.svg)
+[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/4671/badge)](https://bestpractices.coreinfrastructure.org/projects/4671)
 
 This project aims to provide a Node.js module to enable IoT Agent developers to build custom agents for their devices
 that can easily connect to NGSI Context Brokers (such as [Orion](https://github.com/telefonicaid/fiware-orion)).

package/doc/Contribution.md

@@ -1,6 +1,65 @@
 # Contribution Guidelines
 
-==================
+## Ground rules & expectations
+
+Before we get started, here are a few things we expect from you (and that you should expect from others):
+
+* Be kind and thoughtful in your conversations around this project. We all come from different backgrounds and
+  projects, which means we likely have different perspectives on "how open source is done." Try to listen to others
+  rather than convince them that your way is correct.
+* Please ensure that your contribution passes all tests. If there are test failures, you will need to address them
+  before we can merge your contribution.
+* When adding content, please consider if it is widely valuable. Please don't add references or links to things you or
+  your employer have created as others will do so if they appreciate it.
+* When reporting a vulnerability on the software, please, put in contact with IoT Agent Node Lib repository maintainers in order to discuss it 
+  in a private way.
+
+## How to contribute
+
+If you'd like to contribute, start by searching through the [issues](https://github.com/telefonicaid/iotagent-node-lib/issues) and
+[pull requests](https://github.com/telefonicaid/iotagent-node-lib/pulls) to see whether someone else has raised a similar idea or
+question.
+
+If you don't see your idea listed, and you think it fits into the goals of this guide, do one of the following:
+
+-   **If your contribution is minor,** such as a typo fix, open a pull request.
+-   **If your contribution is major,** such as a new guide, start by opening an issue first. That way, other people can
+    weigh in on the discussion before you do any work.
+
+### Pull Request protocol
+
+As explained in ([FIWARE Contribution Requirements](https://fiware-requirements.readthedocs.io/en/latest)) 
+contributions are done using a pull request (PR). The detailed "protocol" used in such PR is described below:
+
+* Direct commits to master branch (even single-line modifications) are not allowed. Every modification has to come as a PR
+* In case the PR is implementing/fixing a numbered issue, the issue number has to be referenced in the body of the PR at creation time
+* Anybody is welcome to provide comments to the PR (either direct comments or using the review feature offered by Github)
+* Use *code line comments* instead of *general comments*, for traceability reasons (see comments lifecycle below)
+* Comments lifecycle
+  * Comment is created, initiating a *comment thread*
+  * New comments can be added as responses to the original one, starting a discussion
+  * After discussion, the comment thread ends in one of the following ways:
+    * `Fixed in <commit hash>` in case the discussion involves a fix in the PR branch (which commit hash is 
+       included as reference)
+    * `NTC`, if finally nothing needs to be done (NTC = Nothing To Change)
+ * PR can be merged when the following conditions are met:
+    * All comment threads are closed
+    * All the participants in the discussion have provided a `LGTM` general comment (LGTM = Looks good to me)
+ * Self-merging is not allowed (except in rare and justified circumstances)
+
+Some additional remarks to take into account when contributing with new PRs:
+
+* PR must include not only code contributions, but their corresponding pieces of documentation (new or modifications to existing one) and tests
+* PR modifications must pass full regression based on existing test (unit, functional, memory, e2e) in addition to whichever new test added due to the new functionality
+* PR should be of an appropriated size that makes review achievable. Too large PRs could be closed with a "please, redo the work in smaller pieces" without any further discussing
+
+## Community
+
+Discussions about the Open Source Guides take place on this repository's
+[Issues](https://github.com/telefonicaid/iotagent-node-lib/issues) and [Pull Requests](https://github.com/telefonicaid/iotagent-node-lib/pulls)
+sections. Anybody is welcome to join these conversations.
+
+Wherever possible, do not take these conversations to private channels, including contacting the maintainers directly.
 
 ## Overview
 

package/doc/advanced-topics.md

@@ -1,12 +1,36 @@
 ## Advanced Topics
 
+-   [Secured access to the Context Broker](#secured-access-to-the-context-broker)
+-   [NGSI-LD `GeoProperty` support](#ngsi-ld-geoproperty-support)
+-   [Metadata support](#metadata-support)
+    -   [NGSI LD data and metadata considerations](#ngsi-ld-data-and-metadata-considerations)
+-   [NGSI-LD Linked Data support](#ngsi-ld-linked-data-support)
+-   [Autoprovision configuration (autoprovision)](#autoprovision-configuration-autoprovision)
+-   [Explicitly defined attributes (explicitAttrs)](#explicitly-defined-attributes-explicitattrs)
+-   [Configuring operation to persist the data in Context Broker (appendMode)](#configuring-operation-to-persist-the-data-in-context-broker-appendmode)
+-   [Data mapping plugins](#data-mapping-plugins)
+    -   [Development](#development)
+    -   [Provided plugins](#provided-plugins)
+        -   [Timestamp Compression plugin (compressTimestamp)](#timestamp-compression-plugin-compresstimestamp)
+        -   [Attribute Alias plugin (attributeAlias)](#attribute-alias-plugin-attributealias)
+        -   [Event plugin (addEvents)](#event-plugin-addevents)
+        -   [Timestamp Processing Plugin (timestampProcess)](#timestamp-processing-plugin-timestampprocess)
+        -   [Expression Translation plugin (expressionTransformation)](#expression-translation-plugin-expressiontransformation)
+        -   [Multientity plugin (multiEntity)](#multientity-plugin-multientity)
+        -   [Bidirectionality plugin (bidirectional)](#bidirectionality-plugin-bidirectional)
+    -   [Autoprovision configuration (autoprovision)](#autoprovision-configuration-autoprovision)
+    -   [Explicitly defined attributes (explicitAttrs)](#explicitly-defined-attributes-explicitattrs)
+    -   [Configuring operation to persist the data in Context Broker (appendMode)](#configuring-operation-to-persist-the-data-in-context-broker-appendmode)
+-   [Old IoTAgent data migration](#old-iotagent-data-migration)
+
 ### Secured access to the Context Broker
 
 For access to instances of the Context Broker secured with a
 [PEP Proxy](https://github.com/telefonicaid/fiware-orion-pep), an authentication mechanism based in Keystone Trust
-tokens is provided. A Trust token is a long-term token that can be issued by any user to give another user permissions
-to impersonate him with a given role in a given project. Such impersonation itself is in turn based on a short-term
-access token.
+tokens is provided. A trust token is a way of Keystone to allow an user delegates a role to another user for a
+subservice. It is a long-term token that can be issued by any user to give another user permissions to impersonate him
+with a given role in a given project (subservice). Such impersonation itself is in turn based on a short-term access
+token.
 
 For the authentication mechanisms to work, the `authentication` attribute in the configuration has to be fully
 configured, and the `authentication.enabled` subattribute should have the value `true`.
@@ -46,12 +70,20 @@ curl http://${KEYSTONE_HOST}/v3/OS-TRUST/trusts \
 Apart from the generation of the trust, the use of secured Context Brokers should be transparent to the user of the IoT
 Agent.
 
-### GeoJSON support (this only applies for NGSI-LD, not for NGSIv1 and NGSIv2)
+Complete info on Keystone trust tokens could be found at:
+
+-   [Trusts concept](https://docs.openstack.org/keystone/stein/user/trusts)
+-   [Trusts API](https://docs.openstack.org/keystone/stein/api_curl_examples.html#post-v3-os-trust-trusts)
+
+### NGSI-LD `GeoProperty` support
 
-The defined `type` of any GeoJSON attribute can be any set to any of the standard NGSI-v2 GeoJSON types - (e.g.
-`geo:json`, `geo:point`). NGSI-LD formats such as `GeoProperty`, `Point` and `LineString` are also accepted `type`
-values. If the latitude and longitude are received as separate measures, the
-[expression language](expressionLanguage.md) can be used to concatenate them.
+For NGSI-LD only, the defined `type` of any GeoJSON attribute can be any set using any of the standard NGSI-v2 GeoJSON
+types - (e.g. `geo:json`, `geo:point`). NGSI-LD formats such as `GeoProperty`, `Point` and `LineString` are also
+accepted `type` values. If the latitude and longitude are received as separate measures, the JEXL or legacy
+[expression language](expressionLanguage.md) can be used to concatenate them into GeoJSON objects an array of tuples or
+a string as shown
+
+#### Legacy - encode as String
 
 ```json
 {
@@ -69,8 +101,30 @@ values. If the latitude and longitude are received as separate measures, the
 }
 ```
 
-For `attributes` and `static_attributes` which need to be formatted as GeoJSON values, three separate input formats are
-accepted. Provided the `type` is provisioned correctly, the `value` may be defined using any of the following formats:
+#### JEXL - encode as GeoJSON
+
+```json
+{
+    "entity_type": "GPS",
+    "resource":    "/iot/d",
+    "protocol":    "PDI-IoTA-JSON",
+    "expressionLanguage": "jexl",
+..etc
+    "attributes": [
+        {
+            "name": "location",
+            "type": "geo:json",
+            "expression": "{coordinates: [longitude,latitude], type: 'Point'}"
+        }
+    ]
+}
+```
+
+JEXL can be used to create GeoJSON objects directly. The Legacy expression language does not support GeoJSON. However,
+there is a workaround specifically for NGSI-LD Entities which always require `location` to be encoded as GeoJSON. For
+`attributes` and `static_attributes` which need to be formatted as GeoJSON values, three separate input formats are
+currently accepted. Provided the `type` is provisioned correctly, the `value` may be defined using any of the following
+formats:
 
 -   a comma delimited string
 
@@ -237,6 +291,73 @@ updated as shown:
 }
 ```
 
+### Autoprovision configuration (autoprovision)
+
+By default, when a measure arrives to the IoTAgent, if the `device_id` does not match with an existing one, then, the
+IoTA creates a new device and a new entity according to the group config. Defining the field `autoprovision` to `false`
+when provisioning the device group, the IoTA to reject the measure at the southbound, allowing only to persist the data
+to devices that are already provisioned. It makes no sense to use this field in device provisioning since it is intended
+to avoid provisioning devices (and for it to be effective, it would have to be provisional).
+
+### Explicitly defined attributes (explicitAttrs)
+
+If a given measure element (object_id) is not defined in the mappings of the device or group provision, the measure is
+stored in the Context Broker by adding a new attribute to the entity with the same name of the undefined measure
+element. By adding the field `explicitAttrs` with `true` value to device or group provision, the IoTAgent rejects the
+measure elements that are not defined in the mappings of device or group provision, persisting only the one defined in
+the mappings of the provision. If `explicitAttrs` is provided both at device and group level, the device level takes
+precedence. Additionally `explicitAttrs` can be used to define which meassures defined in JSON/JEXL array will be
+propagated to NGSI interface.
+
+The different possibilities are summarized below:
+
+Case 1 (default):
+
+```
+"explicitAttrs": false
+```
+
+every measure will be propagated to NGSI interface.
+
+Case 2:
+
+```
+"explicitAttrs": true
+```
+
+just measures defined in active, static (plus conditionally TimeInstant) will be propagated to NGSI interface.
+
+Case 3:
+
+```
+"explicitAttrs": "['attr1','atrr2']"
+```
+
+just measures defined in the array will be will be propagated to NGSI interface (note that in this case the value of
+`explicitAttrs` is not a JSON but a string that looks likes a JSON).
+
+Case 4:
+
+```
+"explicitAtttr": "<JEXL expression resulting in bool or array>"
+```
+
+depending on the JEXL expression evaluation:
+
+-   If it evaluates to `true` every measure will be propagated to NGSI interface (as in case 1)
+-   If it evaluates to `false` just measures defined in active, static (plus conditionally TimeInstant) will be
+    propagated to NGSI interface (as in case 2)
+-   If it evaluates to an array just measures defined in the array will be will be propagated to NGSI interface (as in
+    case 3)
+
+### Configuring operation to persist the data in Context Broker (appendMode)
+
+This is a flag that can be enabled by activating the parameter `appendMode` in the configuration file or by using the
+`IOTA_APPEND_MODE` environment variable (more info
+[here](https://github.com/telefonicaid/iotagent-node-lib/blob/master/doc/installationguide.md)). If this flag is
+activated, the update requests to the Context Broker will be performed always with APPEND type, instead of the default
+UPDATE. This have implications in the use of attributes with Context Providers, so this flag should be used with care.
+
 ### Data mapping plugins
 
 The IoT Agent Library provides a plugin mechanism in order to facilitate reusing code that makes small transformations
@@ -320,8 +441,8 @@ events in the IoT Agent with the configured type name will be marked as events.
 
 ##### Timestamp Processing Plugin (timestampProcess)
 
-This plugin processes the entity attributes looking for a `TimeInstant` attribute. If one is found, for NGSI-v1/NGSIv2,
-the plugin adds a `TimeInstant` attribute as metadata for every other attribute in the same request. With NGSI-LD, the
+This plugin processes the entity attributes looking for a `TimeInstant` attribute. If one is found, for NGSIv2, the
+plugin adds a `TimeInstant` attribute as metadata for every other attribute in the same request. With NGSI-LD, the
 Standard `observedAt` property-of-a-property is used instead.
 
 ##### Expression Translation plugin (expressionTransformation)
@@ -385,14 +506,15 @@ When a device is provisioned with bidirectional attributes, the IoTAgent subscri
 change notification for that attribute arrives to the IoTA, it applies the transformation defined in the device
 provisioning payload to the notification, and calls the underlying notification handler with the transformed entity.
 
-The following `attributes` section shows an example of the plugin configuration:
+The following `attributes` section shows an example of the plugin configuration (using IOTA_AUTOCAST=false to avoid
+translation from geo:point to geo:json)
 
 ```json
       "attributes": [
         {
           "name":"location",
           "type":"geo:point",
-          "expression": "${latitude}, ${longitude}",
+          "expression": "${@latitude}, ${@longitude}",
           "reverse": [
             {
               "object_id":"longitude",

package/doc/api.md

@@ -75,25 +75,26 @@ information configured:
 The table below shows the information held in the service group provisioning resource. The table also contains the
 correspondence between the API resource fields and the same fields in the database model.
 
-| Payload Field         | DB Field             | Definition                                                                                                                                                                                                                                                                |
-| --------------------- | -------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `service`             | `service`            | Service of the devices of this type                                                                                                                                                                                                                                       |
-| `subservice`          | `subservice`         | Subservice of the devices of this type.                                                                                                                                                                                                                                   |
-| `resource`            | `resource`           | string representing the Southbound resource that will be used to assign a type to a device (e.g.: pathname in the southbound port).                                                                                                                                       |
-| `apikey`              | `apikey`             | API Key string.                                                                                                                                                                                                                                                           |
-| `timestamp`           | `timestamp`          | Optional flag about whether or not to add the `TimeInstant` attribute to the device entity created, as well as a `TimeInstant` metadata to each attribute, with the current timestamp. With NGSI-LD, the Standard `observedAt` property-of-a-property is created instead. | true |
-| `entity_type`         | `entity_type`        | name of the Entity `type` to assign to the group.                                                                                                                                                                                                                         |
-| `trust`               | `trust`              | trust token to use for secured access to the Context Broker for this type of devices (optional; only needed for secured scenarios).                                                                                                                                       |
-| `cbHost`              | `cbHost`             | Context Broker connection information. This options can be used to override the global ones for specific types of devices.                                                                                                                                                |
-| `lazy`                | `lazy`               | list of common lazy attributes of the device. For each attribute, its `name` and `type` must be provided.                                                                                                                                                                 |
-| `commands`            | `commands`           | list of common commands attributes of the device. For each attribute, its `name` and `type` must be provided, additional `metadata` is optional.                                                                                                                          |
-| `attributes`          | `attributes`         | list of common active attributes of the device. For each attribute, its `name` and `type` must be provided, additional `metadata` is optional.                                                                                                                            |
-| `static_attributes`   | `staticAttributes`   | this attributes will be added to all the entities of this group 'as is', additional `metadata` is optional.                                                                                                                                                               |
-| `internal_attributes` | `internalAttributes` | optional section with free format, to allow specific IoT Agents to store information along with the devices in the Device Registry.                                                                                                                                       |
-| `expressionLanguage`  | `expresionLanguage`  | optional boolean value, to set expression language used to compute expressions, possible values are: legacy or jexl. When not set or wrongly set, `legacy` is used as default value.                                                                                      |
-| `explicitAttrs`       | `explicitAttrs`      | optional boolean value, to support selective ignore of measures so that IOTA doesn’t progress. If not specified default is `false`.                                                                                                                                       |
-| `ngsiVersion`         | `ngsiVersion`        | optional string value used in mixed mode to switch between **NGSI-v2** and **NGSI-LD** payloads. Possible values are: `v2` or `ld`. The default is `v2`. When not running in mixed mode, this field is ignored.
-| `defaultEntityNameConjunction` | `defaultEntityNameConjunction` | optional string value to set default conjunction string used to compose a default `entity_name` when is not provided at device provisioning time.                                                                                             |
+| Payload Field                  | DB Field                       | Definition                                                                                                                                                                                                                                                                |
+| ------------------------------ | ------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `service`                      | `service`                      | Service of the devices of this type                                                                                                                                                                                                                                       |
+| `subservice`                   | `subservice`                   | Subservice of the devices of this type.                                                                                                                                                                                                                                   |
+| `resource`                     | `resource`                     | string representing the Southbound resource that will be used to assign a type to a device (e.g.: pathname in the southbound port).                                                                                                                                       |
+| `apikey`                       | `apikey`                       | API Key string.                                                                                                                                                                                                                                                           |
+| `timestamp`                    | `timestamp`                    | Optional flag about whether or not to add the `TimeInstant` attribute to the device entity created, as well as a `TimeInstant` metadata to each attribute, with the current timestamp. With NGSI-LD, the Standard `observedAt` property-of-a-property is created instead. | true |
+| `entity_type`                  | `entity_type`                  | name of the Entity `type` to assign to the group.                                                                                                                                                                                                                         |
+| `trust`                        | `trust`                        | trust token to use for secured access to the Context Broker for this type of devices (optional; only needed for secured scenarios).                                                                                                                                       |
+| `cbHost`                       | `cbHost`                       | Context Broker connection information. This options can be used to override the global ones for specific types of devices.                                                                                                                                                |
+| `lazy`                         | `lazy`                         | list of common lazy attributes of the device. For each attribute, its `name` and `type` must be provided.                                                                                                                                                                 |
+| `commands`                     | `commands`                     | list of common commands attributes of the device. For each attribute, its `name` and `type` must be provided, additional `metadata` is optional.                                                                                                                          |
+| `attributes`                   | `attributes`                   | list of common active attributes of the device. For each attribute, its `name` and `type` must be provided, additional `metadata` is optional.                                                                                                                            |
+| `static_attributes`            | `staticAttributes`             | this attributes will be added to all the entities of this group 'as is', additional `metadata` is optional.                                                                                                                                                               |
+| `internal_attributes`          | `internalAttributes`           | optional section with free format, to allow specific IoT Agents to store information along with the devices in the Device Registry.                                                                                                                                       |
+| `expressionLanguage`           | `expresionLanguage`            | optional boolean value, to set expression language used to compute expressions, possible values are: legacy or jexl. When not set or wrongly set, `legacy` is used as default value.                                                                                      |
+| `explicitAttrs`                | `explicitAttrs`                | optional field to support selective ignore of measures so that IOTA doesn’t progress. See details in [specific section](advanced-topics.md#explicitly-defined-attributes-explicitattrs)                                                                                   |
+| `ngsiVersion`                  | `ngsiVersion`                  | optional string value used in mixed mode to switch between **NGSI-v2** and **NGSI-LD** payloads. Possible values are: `v2` or `ld`. The default is `v2`. When not running in mixed mode, this field is ignored.                                                           |
+| `defaultEntityNameConjunction` | `defaultEntityNameConjunction` | optional string value to set default conjunction string used to compose a default `entity_name` when is not provided at device provisioning time.                                                                                                                         |
+| `autoprovision`                | `autoprovision`                | optional boolean: If `false`, autoprovisioned devices (i.e. devices that are not created with an explicit provision operation but when the first measure arrives) are not allowed in this group. Default (in the case of omitting the field) is `true`.                   |
 
 ### Service Group Endpoint
 
@@ -202,6 +203,21 @@ outgoing requests).
 Note that there is a 1:1 correspondence between payload fields and DB fields (but using a different capitalization, e.g.
 `service_path` vs. `servicePath`).
 
+### Relationship between service groups and devices
+
+Devices may be associated to exisiting service groups (or not) based in `apiKey` matching or `type` matching (in the
+case `apiKey` matching fails). For instance, let's consider a situation in which a service group has been provisioned
+with `type=X`/`apiKey=111` and no other service group has been provisioned.
+
+-   IoT Agent receives an anonymous measure with `apiKey=111`. The matching `apiKey` means the entity inherits from
+    service group. Device entity has `type=X` and `apiKey=111`
+-   IoT Agent receives a provisioning request for an explicit device of `type=Y`/`apiKey=111`. The matching `apiKey`
+    means the entity inherits from service group but type is overridden. Device entity has `type=Y` and `apiKey=111`
+-   IoT Agent receives a provisioning request for an explicit device of `type=X`/`apiKey=222`. The matching `type` means
+    the entity inherits from service group but `apiKey` is overridden. Device entity has `type=X` and `apiKey=222`.
+-   IoT Agent receives a provisioning request for an explicit device of `type=Y`/`apiKey=222`. No matching. Device
+    entity has `type=Y` and `apiKey=222` and no service group.
+
 ### Device model
 
 The table below shows the information held in the Device resource. The table also contains the correspondence between
@@ -226,8 +242,8 @@ the API resource fields and the same fields in the database model.
 | `internal_attributes` | `internalAttributes` | List of internal attributes with free format for specific IoT Agent configuration                                                                                                                                                                                         | LWM2M mappings from object URIs to attributes |
 | `static_attributes`   | `staticAttributes`   | List of static attributes to append to the entity. All the updateContext requests to the CB will have this set of attributes appended.                                                                                                                                    | `[ { "name": "attr_name", "type": "Text" } ]` |
 | `expressionLanguage`  | `expresionLanguage`  | optional boolean value, to set expression language used to compute expressions, possible values are: legacy or jexl. When not set or wrongly set, legacy is used as default value.                                                                                        |
-| `explicitAttrs`       | `explicitAttrs`      | Boolean value to support selective ignore of measures for device so that IOTA doesn’t progress. If not specified default is `false`.                                                                                                                                      | `true/false`                              |
-| `ngsiVersion`         | `ngsiVersion`        | optional string value used in mixed mode to switch between **NGSI-v2** and **NGSI-LD** payloads. The default is `v2`. When not running in mixed mode, this field is ignored.                                                                                            | `v2/ld`                                   |
+| `explicitAttrs`       | `explicitAttrs`      | optional field to support selective ignore of measures so that IOTA doesn’t progress. See details in [specific section](advanced-topics.md#explicitly-defined-attributes-explicitattrs)                                                                                   | (see details in specific section)             |
+| `ngsiVersion`         | `ngsiVersion`        | optional string value used in mixed mode to switch between **NGSI-v2** and **NGSI-LD** payloads. The default is `v2`. When not running in mixed mode, this field is ignored.                                                                                              | `v2/ld`                                       |
 
 #### Attribute lists
 
@@ -250,7 +266,7 @@ Some transformation plugins also allow the use of the following optional attribu
     be defined as expressions, using the [Expression Language definition](expressionLanguage.md).
 -   **entity_type**: configures the type of an alternative entity.
 -   **reverse**: add bidirectionality expressions to the attribute. See the **bidirectionality** transformation plugin
-    in the [Data Mapping Plugins section](#data-mapping-plugins) for details.
+    in the [Data Mapping Plugins section](advanced-topics.md#bidirectionality-plugin-bidirectional) for details.
 
 See the transformation plugins Section for more details.
 

package/doc/apiary/iotagent.apib

@@ -87,7 +87,7 @@ Fields in JSON object representing a configuration group are:
 |`attributes`            |Mapping for protocol parameters to entity attributes.<br> `object_id` (string, mandatory): protocol parameter to be mapped.<br> `name` (string, mandatory): attribute name to publish.<br> `type`: (string, mandatory): attribute type to publish.|
 |`static_attributes`     |Attributes published as defined.<br> `name` (string, mandatory): attribute name to publish.<br> `type` (string, mandatory): attribute type to publish.<br> `value` (string, mandatory): attribute value to publish.|
 | `timestamp`.           |(optional, boolean): This field indicates if an attribute 'TimeInstant' will be added (true) or not (false). If this field is omitted, the global IotAgent configuration timestamp will be used.|
-| `autoprovision`.       |(optional, boolean): If true, APPEND is used upon measure arrival (thus effectively allowing autoprovisioned devices). If false, UPDATE is used open measure arrival (thus effectively avoiding autoprovisioned devices). This field is optional, so if it omitted then the global IoTAgent appendModel configuration is used.|
+| `autoprovision`.       |(optional, boolean): If `false`, autoprovisioned devices (i.e. devices that are not created with an explicit provision operation but when the first measure arrives) are not allowed in this group. Default (in the case of omitting the field) is `true`.|
 
 Mandatory fields are identified in every operation.
 
@@ -260,7 +260,6 @@ A device is a resource that publish information to IoT Platform and it uses the
 `type` (string, mandatory). It must be 'command'.
 `value` (string, mandatory): command representation depends on protocol.
 - `timestamp`. (optional, boolean): This field indicates if an attribute 'TimeInstant' will be added (true) or not (false). If this field is omitted, the global IotAgent configuration timestamp will be used.
-- `autoprovision`. (optional, boolean): If true, APPEND is used upon measure arrival (thus effectively allowing autoprovisioned devices). If false, UPDATE is used open measure arrival (thus effectively avoiding autoprovisioned devices). This field is optional, so if it omitted then the global IoTAgent appendModel configuration is used.
 
 Mandatory fields are identified in every operation.
 
@@ -444,4 +443,3 @@ If specific device is not found, we work as deleted.
 
 
 
-

package/doc/architecture.md

@@ -214,11 +214,11 @@ device to a command update to the device.
 As part of the device to entity mapping process the IoT Agent creates and updates automatically a special timestamp.
 This timestamp is represented as two different properties of the mapped entity::
 
--   With NGSIv1/NGSI-v2, an attribute metadata named `TimeInstant` (per dynamic attribute mapped, which captures as an
+-   With NGSI-v2, an attribute metadata named `TimeInstant` (per dynamic attribute mapped, which captures as an
     ISO8601 timestamp when the associated measurement (represented as attribute value) was observed. With NGSI-LD, the
     Standard `observedAt` property-of-a-property is used instead.
 
--   For NGSIv1/NGSI-v2 only, an additional attribute `TimeInstant` is added to the entity which captures as an ISO8601
+-   For NGSI-v2 only, an additional attribute `TimeInstant` is added to the entity which captures as an ISO8601
     timestamp when the last measurement received from the device was observed.
 
 If no information about the measurement timestamp is received by the IoT Agent, the arrival time of the measurement will

package/doc/config-basic-example.js

@@ -14,7 +14,6 @@ var config = {
     service: 'howtoService',
     subservice: '/howto',
     providerUrl: 'http://localhost:4041',
-    deviceRegistrationDuration: 'P1M',
     defaultType: 'Thing'
 };
 

package/doc/deprecated.md

@@ -16,7 +16,7 @@ A list of deprecated features and the version in which they were deprecated foll
 -   Support to Node.js v4 in iotagent-node-lib 2.8.1 (finally removed in 2.9.0)
 -   Support to Node.js v6 in iotagent-node-lib 2.9.0 (finally removed in 2.10.0)
 -   Support to Node.js v8 in iotagent-node-lib 2.12.0 (finally removed in 2.13.0)
--   Support to Node.js v10 in iotagent-node-lib 2.15.0.
+-   Support to Node.js v10 in iotagent-node-lib 2.15.0 (finally removed in 2.16.0)
 
 The use of Node.js v12 is highly recommended.
 
@@ -42,4 +42,4 @@ The following table provides information about the last iotagent-node-lib versio
 | Support to Node.js v4  | 2.8.1                                                 | December 19th, 2018                 |
 | Support to Node.js v6  | 2.9.0                                                 | May 22nd, 2019                      |
 | Support to Node.js v8  | 2.12.0                                                | April 7th, 2020                    |
-| Support to Node.js v10 | Not defined but it will completed before May 2021     | Not yet defined               |
+| Support to Node.js v10 | 2.15.0   | February 18th, 2021                |

package/doc/development.md

@@ -27,15 +27,15 @@ The following sections show the available options in detail.
 
 ### Environment requirements
 
-A [MongoDB](https://www.mongodb.com/) 3.2+ instance is required to run tests.
-You can deploy one by using the commodity `docker-compose-dev.yml`:
+A [MongoDB](https://www.mongodb.com/) 3.2+ instance is required to run tests. You can deploy one by using the commodity
+`docker-compose-dev.yml`:
 
 ```
 docker-compose -f docker-compose-dev.yml up -d
 ```
 
-To run docker compose you will need [docker](https://docs.docker.com/get-docker/)
-and [docker-compose](https://docs.docker.com/compose/install/).
+To run docker compose you will need [docker](https://docs.docker.com/get-docker/) and
+[docker-compose](https://docs.docker.com/compose/install/).
 
 ### Testing
 
@@ -51,6 +51,13 @@ To run tests, type
 npm test
 ```
 
+There are additional targets starting with `test:` prefix to run specific test subsets isolatedly. For instance, the
+`test:expressions` target runs the subset of tests related with expression language feature:
+
+```bash
+npm run test:expressions
+```
+
 ### Debug Test
 
 To debug the code while running run tests, type
@@ -59,8 +66,8 @@ To debug the code while running run tests, type
 npm run test:debug
 ```
 
-In the console the link to the debugger will be provided. You can connect
-to it via Chrome, for example, by opening the following url: ```chrome://inspect```.
+In the console the link to the debugger will be provided. You can connect to it via Chrome, for example, by opening the
+following url: `chrome://inspect`.
 
 Additional debug clients are listed on [node.js](https://nodejs.org/en/docs/guides/debugging-getting-started/).