iotagent-node-lib 2.19.0 → 2.22.0

package/.nyc_output/processinfo/33364de2-1199-4ec2-b33c-cae063ef8cc4.json

@@ -0,0 +1 @@
+{"parent":null,"pid":78202,"argv":["/home/fermin/.nvm/versions/node/v16.15.0/bin/node","/home/fermin/src/iotagent-node-lib/node_modules/.bin/mocha","--recursive","test/**/*.js","--reporter","spec","--timeout","8000","--ui","bdd","--exit","--color","true"],"execArgv":[],"cwd":"/home/fermin/src/iotagent-node-lib","time":1655738400548,"ppid":78191,"coverageFilename":"/home/fermin/src/iotagent-node-lib/.nyc_output/33364de2-1199-4ec2-b33c-cae063ef8cc4.json","externalId":"","uuid":"33364de2-1199-4ec2-b33c-cae063ef8cc4","files":["/home/fermin/src/iotagent-node-lib/lib/fiware-iotagent-lib.js","/home/fermin/src/iotagent-node-lib/lib/services/ngsi/ngsiService.js","/home/fermin/src/iotagent-node-lib/lib/services/common/domain.js","/home/fermin/src/iotagent-node-lib/lib/constants.js","/home/fermin/src/iotagent-node-lib/lib/errors.js","/home/fermin/src/iotagent-node-lib/lib/commonConfig.js","/home/fermin/src/iotagent-node-lib/lib/services/ngsi/ngsiUtils.js","/home/fermin/src/iotagent-node-lib/lib/services/common/genericMiddleware.js","/home/fermin/src/iotagent-node-lib/lib/model/dbConn.js","/home/fermin/src/iotagent-node-lib/lib/services/common/alarmManagement.js","/home/fermin/src/iotagent-node-lib/lib/services/ngsi/subscriptionService.js","/home/fermin/src/iotagent-node-lib/lib/services/stats/statsRegistry.js","/home/fermin/src/iotagent-node-lib/lib/services/devices/deviceService.js","/home/fermin/src/iotagent-node-lib/lib/services/groups/groupService.js","/home/fermin/src/iotagent-node-lib/lib/services/common/iotManagerService.js","/home/fermin/src/iotagent-node-lib/lib/request-shim.js","/home/fermin/src/iotagent-node-lib/lib/services/devices/registrationUtils.js","/home/fermin/src/iotagent-node-lib/lib/services/northBound/restUtils.js","/home/fermin/src/iotagent-node-lib/lib/services/commands/commandService.js","/home/fermin/src/iotagent-node-lib/lib/services/northBound/northboundServer.js","/home/fermin/src/iotagent-node-lib/lib/services/northBound/contextServer.js","/home/fermin/src/iotagent-node-lib/lib/services/northBound/contextServerUtils.js","/home/fermin/src/iotagent-node-lib/lib/services/northBound/deviceProvisioningServer.js","/home/fermin/src/iotagent-node-lib/lib/services/northBound/deviceGroupAdministrationServer.js","/home/fermin/src/iotagent-node-lib/lib/plugins/compressTimestamp.js","/home/fermin/src/iotagent-node-lib/lib/plugins/pluginUtils.js","/home/fermin/src/iotagent-node-lib/lib/plugins/attributeAlias.js","/home/fermin/src/iotagent-node-lib/lib/plugins/addEvent.js","/home/fermin/src/iotagent-node-lib/lib/plugins/timestampProcessPlugin.js","/home/fermin/src/iotagent-node-lib/lib/plugins/expressionPlugin.js","/home/fermin/src/iotagent-node-lib/lib/plugins/expressionParser.js","/home/fermin/src/iotagent-node-lib/lib/plugins/jexlParser.js","/home/fermin/src/iotagent-node-lib/lib/jexlTranformsMap.js","/home/fermin/src/iotagent-node-lib/lib/plugins/multiEntity.js","/home/fermin/src/iotagent-node-lib/lib/plugins/bidirectionalData.js","/home/fermin/src/iotagent-node-lib/lib/services/groups/groupRegistryMemory.js","/home/fermin/src/iotagent-node-lib/lib/services/common/securityServiceKeystone.js","/home/fermin/src/iotagent-node-lib/lib/services/devices/deviceRegistryMemory.js","/home/fermin/src/iotagent-node-lib/lib/services/commands/commandRegistryMemory.js","/home/fermin/src/iotagent-node-lib/lib/services/devices/devices-NGSI-v2.js","/home/fermin/src/iotagent-node-lib/lib/services/ngsi/entities-NGSI-v2.js","/home/fermin/src/iotagent-node-lib/lib/services/ngsi/subscription-NGSI-v2.js","/home/fermin/src/iotagent-node-lib/lib/services/northBound/contextServer-NGSI-v2.js","/home/fermin/src/iotagent-node-lib/lib/model/Device.js","/home/fermin/src/iotagent-node-lib/lib/model/Group.js","/home/fermin/src/iotagent-node-lib/lib/model/Command.js","/home/fermin/src/iotagent-node-lib/lib/services/devices/deviceRegistryMongoDB.js","/home/fermin/src/iotagent-node-lib/lib/services/groups/groupRegistryMongoDB.js","/home/fermin/src/iotagent-node-lib/lib/services/commands/commandRegistryMongoDB.js","/home/fermin/src/iotagent-node-lib/lib/services/devices/devices-NGSI-LD.js","/home/fermin/src/iotagent-node-lib/lib/services/ngsi/entities-NGSI-LD.js","/home/fermin/src/iotagent-node-lib/lib/services/ngsi/subscription-NGSI-LD.js","/home/fermin/src/iotagent-node-lib/lib/services/northBound/contextServer-NGSI-LD.js","/home/fermin/src/iotagent-node-lib/lib/services/common/securityServiceOAuth2.js","/home/fermin/src/iotagent-node-lib/lib/services/devices/devices-NGSI-mixed.js","/home/fermin/src/iotagent-node-lib/lib/services/ngsi/subscription-NGSI-mixed.js","/home/fermin/src/iotagent-node-lib/lib/services/northBound/contextServer-NGSI-mixed.js","/home/fermin/src/iotagent-node-lib/lib/services/ngsi/entities-NGSI-mixed.js"]}

package/.nyc_output/processinfo/index.json

@@ -0,0 +1 @@
+{"processes":{"33364de2-1199-4ec2-b33c-cae063ef8cc4":{"parent":null,"children":[]}},"files":{"/home/fermin/src/iotagent-node-lib/lib/fiware-iotagent-lib.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/ngsi/ngsiService.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/common/domain.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/constants.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/errors.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/commonConfig.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/ngsi/ngsiUtils.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/common/genericMiddleware.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/model/dbConn.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/common/alarmManagement.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/ngsi/subscriptionService.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/stats/statsRegistry.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/devices/deviceService.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/groups/groupService.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/common/iotManagerService.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/request-shim.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/devices/registrationUtils.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/northBound/restUtils.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/commands/commandService.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/northBound/northboundServer.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/northBound/contextServer.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/northBound/contextServerUtils.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/northBound/deviceProvisioningServer.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/northBound/deviceGroupAdministrationServer.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/plugins/compressTimestamp.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/plugins/pluginUtils.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/plugins/attributeAlias.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/plugins/addEvent.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/plugins/timestampProcessPlugin.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/plugins/expressionPlugin.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/plugins/expressionParser.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/plugins/jexlParser.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/jexlTranformsMap.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/plugins/multiEntity.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/plugins/bidirectionalData.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/groups/groupRegistryMemory.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/common/securityServiceKeystone.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/devices/deviceRegistryMemory.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/commands/commandRegistryMemory.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/devices/devices-NGSI-v2.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/ngsi/entities-NGSI-v2.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/ngsi/subscription-NGSI-v2.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/northBound/contextServer-NGSI-v2.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/model/Device.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/model/Group.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/model/Command.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/devices/deviceRegistryMongoDB.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/groups/groupRegistryMongoDB.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/commands/commandRegistryMongoDB.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/devices/devices-NGSI-LD.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/ngsi/entities-NGSI-LD.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/ngsi/subscription-NGSI-LD.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/northBound/contextServer-NGSI-LD.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/common/securityServiceOAuth2.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/devices/devices-NGSI-mixed.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/ngsi/subscription-NGSI-mixed.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/northBound/contextServer-NGSI-mixed.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"],"/home/fermin/src/iotagent-node-lib/lib/services/ngsi/entities-NGSI-mixed.js":["33364de2-1199-4ec2-b33c-cae063ef8cc4"]},"externalIds":{}}

package/.readthedocs.yml

@@ -4,4 +4,6 @@ mkdocs:
   configuration: mkdocs.yml
 
 python:
-  version: 3.6
+  version: 3.8
+  install:
+    - requirements: doc/requirements.txt

package/CHANGES_NEXT_RELEASE

@@ -0,0 +1 @@
+

package/README.md

@@ -20,7 +20,7 @@ platform (authentication and authorization of the channel) and provide other com
 This project is part of [FIWARE](https://www.fiware.org/). For more information check the FIWARE Catalogue entry for the
 [IoT Agents](https://github.com/Fiware/catalogue/tree/master/iot-agents).
 
-| :books: [Documentation](https://iotagent-node-lib.rtfd.io) | :mortar_board: [Academy](https://fiware-academy.readthedocs.io/en/latest/iot-agents/idas) | :dart: [Roadmap](https://github.com/telefonicaid/iotagent-node-lib/blob/master/docs/roadmap.md) |
+| :books: [Documentation](https://iotagent-node-lib.rtfd.io) | :mortar_board: [Academy](https://fiware-academy.readthedocs.io/en/latest/iot-agents/idas) | :dart: [Roadmap](https://github.com/telefonicaid/iotagent-node-lib/blob/master/doc/roadmap.md) |
 | ---------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
 
 
@@ -72,7 +72,7 @@ IoT Agent
 In order to use the library within your own IoT Agent, you must first you require it before use:
 
 ```javascript
-const iotagentLib = require("iotagent-node-lib");
+const iotagentLib = require('iotagent-node-lib');
 ```
 
 Information about how to configure the Library can be found at the corresponding section of the
@@ -298,64 +298,13 @@ configuration is independent, and can be checked with the `showConfigCb` and `sh
 Their values can be changed with the `configCb` and `configIot` commands respectively. The new configurations will be
 deleted upon startup.
 
-#### Creating specialized testers
-
-The command-line testing tools make use of the
-[command-node Node.js library](https://github.com/telefonicaid/command-shell-lib) for command-line utils. In order to
-help creating testing tools for IoTAgents of specific protocols, all the commands of the library tester are offered as a
-array that can be directly imported into other Command-Line tools, using the following steps:
-
--   Require the `iotagent-node-lib` command-line module in your command-line tool:
-
-```javascript
-var iotaCommands = require("iotagent-node-lib").commandLine;
-```
-
--   Initialize the command-line utils (the initialization function takes two arguments, that will be explained in detail
-    below:
-
-```javascript
-iotaCommands.init(configCb, configIot);
-```
-
--   Add the IOTA Lib commands to your array of commands
-
-```javascript
-commands = commands.concat(commands, iotaCommands.commands);
-```
-
--   Execute the command-line interpreter as usual:
-
-```javascript
-clUtils.initialize(commandLine.commands, "IoT Agent tester> ");
-```
-
-The command-line module makes use of two configuration objects. Both can be shown and edited in the command-line using
-the provided commands, but a default value must be present.
-
-The Context Broker configuration object holds all the information about the Context Broker where the IoT Agent to be
-tested is connected. It MUST contain the following attributes:
-
--   **host**: host where the Context Broker instance is located.
--   **port**: port where the Context Broker instance is listening.
--   **service**: service that will be used in all the NGSI operations.
--   **subservice**: service that will be used in all the NGSI operations.
-
-The IoT Agent configuration object holds information about the IoT Agent that is being tested. It MUST contain the
-following attributes:
-
--   **host**: host where the IoT Agent instance is located.
--   **port**: port where the IoT Agent instance is listening.
--   **service**: service that will be used to group devices and device information.
--   **subservice**: subservice that will be used to group devices and device information.
-
 ---
 
 ## Licence
 
 The IoT Agent Node Library is licensed under [Affero General Public License (GPL) version 3](./LICENSE).
 
-© 2019 Telefonica Investigación y Desarrollo, S.A.U
+© 2022 Telefonica Investigación y Desarrollo, S.A.U
 
 ### Are there any legal issues with AGPL 3.0? Is it safe for me to use?
 
@@ -364,8 +313,8 @@ related with the fact that different people assign different interpretations on
 used in these licenses. Due to this, some people believe that there is a risk in just _using_ software under GPL or AGPL
 licenses (even without _modifying_ it).
 
-For the avoidance of doubt, the owners of this software licensed under an AGPL-3.0 license
-wish to make a clarifying public statement as follows:
+For the avoidance of doubt, the owners of this software licensed under an AGPL-3.0 license wish to make a clarifying
+public statement as follows:
 
 > Please note that software derived as a result of modifying the source code of this software in order to fix a bug or
 > incorporate enhancements is considered a derivative work of the product. Software that merely uses or aggregates (i.e.

package/doc/Contribution.md

@@ -33,7 +33,7 @@ contributions are done using a pull request (PR). The detailed "protocol" used i
 
 * 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)
+* 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*
@@ -142,7 +142,7 @@ point to each of the released versions of the project, they are permanent and th
 
 ## Change log
 
-The project contains a version changelog, called CHANGES_NEXT_RELEASE, that can be found in the root of the project.
+The project contains a version change log, called CHANGES_NEXT_RELEASE, that can be found in the root of the project.
 Whenever a new feature or bug fix is going to be merged with `master`, a new entry should be added to this changelog.
 The new entry should contain the reference number of the issue it is solving (if any).
 
@@ -159,7 +159,7 @@ The process of making a release consists of the following steps:
    new target version (without any sufix), and PR into `master`. Also, in this task, the contents of the Change log are
    copied to the RPM spec.
 2. Create a tag from the last version of `master` named with the version number and push it to the repository.
-3. Create the release in Github, from the created tag. In the description, add the contents of the Change log.
+3. Create the release in GitHub, from the created tag. In the description, add the contents of the Change log.
 4. Create a release branch from the last version of `master` named with the version number.
 5. Create a new task for preparing the next release, adding the sufix `-next` to the current version number (to signal
    this as the development version), and flush the contents of the CHANGES_NEXT_RELEASE file.

package/doc/advanced-topics.md

@@ -21,7 +21,6 @@
     -   [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
 
@@ -198,7 +197,7 @@ e.g.:
 When provisioning devices for an NGSI-LD Context Broker, `type` values should typically correspond to one of the
 following:
 
--   `Property`, `Relationship`, `Geoproperty`
+-   `Property`, `Relationship`, `GeoProperty`, `LanguageProperty`
 -   Native JSON types (e.g. `String`, `Boolean`, `Float` , `Integer` `Number`)
 -   Temporal Properties (e.g. `Datetime`, `Date` , `Time`)
 -   GeoJSON types (e.g `Point`, `LineString`, `Polygon`, `MultiPoint`, `MultiLineString`, `MultiPolygon`)
@@ -306,8 +305,8 @@ stored in the Context Broker by adding a new attribute to the entity with the sa
 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.
+precedence. Additionally `explicitAttrs` can be used to define which meassures (identified by their attribute names, not 
+by their object_id) defined in JSON/JEXL array will be propagated to NGSI interface.
 
 The different possibilities are summarized below:
 
@@ -333,8 +332,8 @@ 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).
+just measures defined in the array (identified by their attribute names, not by their object_id) 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:
 
@@ -347,8 +346,8 @@ 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)
+-   If it evaluates to an array just measures defined in the array (identified by their attribute names, not by their object_id)
+    will be will be propagated to NGSI interface (as in case 3)
 
 ### Configuring operation to persist the data in Context Broker (appendMode)
 
@@ -441,7 +440,7 @@ 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 NGSIv2, the
+This plugin processes the entity attributes looking for a `TimeInstant` attribute. If one is found, for NGSI v2, 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.
 
@@ -539,35 +538,3 @@ subscription payload.
 For each attribute in the `reverse` array, an expression must be defined to calculate its value based on the
 notification attributes. This value will be passed to the underlying protocol with the `object_id` name. Details about
 how the value is then progressed to the device are protocol-specific.
-
-### Old IoTAgent data migration
-
-In order to ease the transition from the old IoTAgent implementation (formerly known as IDAS) to the new Node.js based
-implementations, a data migration tool has been developed. This data migration tool has been integrated as a command in
-the IoTAgent command-line tester.
-
-In order to perform a full migration, follow this steps:
-
--   From the project root, start the command-line tester:
-
-```bash
-    bin/iotAgentTester.js
-```
-
--   Configure the MongoDB host and port, and the origin Database (that holds the data to be migrated):
-
-```bash
-    configMigration localhost 27017 originDB
-```
-
--   Launch the migration, using the special value "\*" as service and subservice
-
-```bash
-    migrate targetDB * *
-```
-
-Some warnings may appear with the "Attribute [_id] was not found for item translation" message during the migration.
-They show the values existing in the original DB that had no translation for the target DB.
-
-If you want to restrict the migration for certain services and subservices, just substitute the `*` value for the
-particular service and subservice you want to use.

package/doc/api.md

@@ -92,6 +92,7 @@ correspondence between the API resource fields and the same fields in the databa
 | `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)                                                                                   |
+| `entityNameExp`                | `entityNameExp`                | optional field to allow use expressions to define entity name, instead default `id` and `type`                                                                                                                                                                            |
 | `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`.                   |
@@ -247,15 +248,15 @@ the API resource fields and the same fields in the database model.
 
 #### Attribute lists
 
-In the device model there are three list of attributes that can be declared: attributes, lazy and commands. All of them
-have the same syntax, an object containing the following attributes:
+In the group/device model there are three list of attributes that can be declared: attributes, lazy and commands. All of
+them have the same syntax, an object containing the following attributes:
 
 -   **object_id** (optional): name of the attribute as coming from the device.
 -   **name** (mandatory): ID of the attribute in the target entity in the Context Broker.
 -   **type** (mandatory): name of the type of the attribute in the target entity.
 -   **metadata** (optional): additional static metadata for the attribute in the target entity. (e.g. `unitCode`)
 
-Some transformation plugins also allow the use of the following optional attributes:
+Some transformation plugins also allow the use of the following optional fields:
 
 -   **expression**: indicates that the value of the target attribute will not be the plain value or the measurement, but
     an expression based on a combination of the reported values. See the
@@ -268,6 +269,16 @@ Some transformation plugins also allow the use of the following optional attribu
 -   **reverse**: add bidirectionality expressions to the attribute. See the **bidirectionality** transformation plugin
     in the [Data Mapping Plugins section](advanced-topics.md#bidirectionality-plugin-bidirectional) for details.
 
+Additionally for commands (which are attributes of type `command`) the following fields are optional:
+
+-   **expression** indicates that the value of the target command will not be the plain value or the command, but an
+    expression based on a combination of the returned values. See the
+    [Expression Language definition](expressionLanguage.md) for details
+-   **payloadType**: indicates how command payload will be transformed before be sent to device. Please have a look to
+    particular IOTAs documentation for allowed values of this field in each case.
+-   **contentType**: `content-type` header used when send command by HTTP transport (ignored in other kinds of
+    transports)
+
 See the transformation plugins Section for more details.
 
 #### Advice on Attribute defintions

package/doc/expressionLanguage.md

@@ -342,6 +342,21 @@ Will now generate the following NGSI v2 payload:
 }
 ```
 
+## Available keys for all Expressions
+
+Apart from measurement transformations (including multientity cases), expressions can be used in the following cases:
+
+-   Default EntityName defined at group level and used for provision and autoprovision of devices
+-   Commands (push and pull)
+-   Endpoint of push http commands
+
+In all of them the following device data is available to all expressions
+
+-   `id`: device ID
+-   `type`: device type
+-   `service`: device service
+-   `subservice`: device subservice
+
 ## JEXL Based Transformations
 
 The recommended expression language for the IoTAgent Library is [JEXL](https://github.com/TomFrost/jexl). To use JEXL,
@@ -474,6 +489,8 @@ Current common transformation set:
 | slice: (arr, init, end)          | `arr.slice(init,end);`                                                                                                  |
 | addset: (arr, x)                 | <code>{ return Array.from((new Set(arr)).add(x)) }</code>                                                               |
 | removeset: (arr, x)              | <code>{ let s = new Set(arr); s.delete(x); return Array.from(s) }</code>                                                |
+| touppercase: (val)               | `String(val).toUpperCase()`                                                                                             |
+| tolowercase: (val)               | `String(val).toLowerCase()`                                                                                             |
 
 You have available this [JEXL interactive playground][99] with all the transformations already loaded, in which you can
 test all the functions described above.

package/doc/northboundinteractions.md

@@ -163,16 +163,15 @@ The equivalent **NGSI-LD** payload is associated to an update operation (PATCH `
 
 ```json
 {
-     "temperature":  {
-          "type": "Property",
-          "value": "23"
-      },
-      "pressure" :{
-          "type": "Property",
-          "value": "720"
-      }
+    "temperature": {
+        "type": "Property",
+        "value": "23"
+    },
+    "pressure": {
+        "type": "Property",
+        "value": "720"
+    }
 }
-
 ```
 
 #### R1 - UpdateContext (response)
@@ -285,7 +284,8 @@ This is an **NGSI-LD** response to `/ngsi-ld/v1/entities/<entity>`
 ```
 
 In this case, the response to the QueryContext is a list of responses, one for each requested entity, indicating whether
-the information has been retrieved successfully (in the HTTP Status code) and the requested Context information in the body of the response.
+the information has been retrieved successfully (in the HTTP Status code) and the requested Context information in the
+body of the response.
 
 Application level errors can be specified for each entity in this payload.
 
@@ -305,7 +305,7 @@ Context Element, but with the request as a whole.
 
 ### Scenario 1: active attributes
 
-![General ](./img/scenario1.png "Scenario 1: active attributes")
+![General ](./img/scenario1.png 'Scenario 1: active attributes')
 
 In this scenario, the interaction is started by the device, that is going to actively send a piece of data to the
 platform. When the IoTAgent receives the data, it sends it to the Context Broker through a P1 request. The Context
@@ -319,7 +319,7 @@ updating process, and can occur at any time (they are to completely different pr
 
 ### Scenario 2: lazy attributes
 
-![General ](./img/scenario2.png "Scenario 2: lazy attributes")
+![General ](./img/scenario2.png 'Scenario 2: lazy attributes')
 
 This scenario requires that the attributes that are going to be requested are marked as provided by the IoT Agent,
 through a registration process (NGSIv9). Examples of this registration process will be provided in the practical section
@@ -345,7 +345,7 @@ queries (and thus P2 and R2 payloads).
 
 ### Scenario 3: commands
 
-![General ](./img/scenario3.png "Scenario 3: commands")
+![General ](./img/scenario3.png 'Scenario 3: commands')
 
 This scenario requires that the attributes that are going to be requested are marked as provided by the IoT Agent,
 through a registration process (NGSIv9). Examples of this registration process will be provided in the practical section
@@ -359,15 +359,26 @@ use three kinds of attributes:
 -   An attribute will be used as the _input attribute_ (the attribute registered in the Context Provider). This input
     attribute can be thought of as a command issued to the IoTAgent (from here the name of the scenario) whose value is
     the set of arguments of the command. Only updateContext operations will be used to interact with this attributes.
+    Typically this attribute is of type `command`.
 
 -   Another attribute will be used as the _result attribute_. This attribute will be updated from the IoTAgent, and its
     value stored in the Context Broker. This attribute will contain the result of the command (this result can be
     information in case the command was a "information retrieval" command or the result of an action if it was an
-    "actuator command"). Typically, the name of this attribute will be the same of the input attribute, with an
-    additional sufix (`_info`).
+    "actuator command"). Initially its value is empty. Typically, the name of this attribute will be the same of the
+    input attribute, with an additional sufix (`_info`) and the type is `commandResult`.
 
 -   Another attribute with the same characteristics as the later will be used to indicate whether the command has ended
-    successfully or whether an error has been reported.
+    successfully or whether an error has been reported. Typically, the name of this attribute will be the same of the
+    input attribute, with an additional sufix (`_status`) and the type is `commandStatus`. The possible values of this
+    attribute are: `ERROR`, `EXPIRED`, `PENDING`, `DELIVERED`, `UNKNOWN` with the following meanings:
+    -   ERROR: There is a kind of error.
+    -   EXPIRED: This meens that pull command has been expired without be delivered to device according with
+        `pollingExpiration` time defined by config.
+    -   PENDING: In a PUSH command means that command has been sent to device but not device has still not respond. In a
+        PULL command means that command has been stored and device still has no ask for it.
+    -   DELIVERED: The command has been delivered to phisical device.
+    -   OK: The command has been delivered and device has respond.
+    -   UNKNOWN: This is the initial value.
 
 In this scenario, the interaction is also initiated by the User. The user starts the scenario by sending an update
 request P1 to the Context Broker, to the input attribute (1). The Context Broker redirects this same payload to the
@@ -835,7 +846,6 @@ The IoT Agent detects the selected attribute is a command, and replies to the Co
 ```json
 [
     {
-
         "type": "device",
         "id": "Dev0001",
         "switch": {
@@ -854,7 +864,6 @@ The Context Broker, forwards the same response to the user, thus replying the or
 ```json
 [
     {
-
         "type": "device",
         "id": "Dev0001",
         "switch": {
@@ -882,11 +891,11 @@ curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -
             "isPattern": "false",
             "id": "Dev0001",
             "switch_info": {
-                "type": "command_info",
+                "type": "commandResult",
                 "value": "Switched successfully!"
             },
             "switch_status": {
-                "type": "command_status",
+                "type": "commandStatus",
                 "value": "OK"
             }
         }
@@ -906,11 +915,11 @@ The Context Broker replies to the IoT Agent with a R1 payload (200 OK):
         "type": "device",
         "id": "Dev0001",
         "switch_info": {
-            "type": "command_info",
+            "type": "commandResult",
             "value": ""
         },
-        "switch_status":  {
-            "type": "command_status",
+        "switch_status": {
+            "type": "commandStatus",
             "value": ""
         }
     }
@@ -936,8 +945,8 @@ curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -
         }
     ],
     "attributes": [
-    	"switch_info",
-    	"switch_status"
+        "switch_info",
+        "switch_status"
     ]
 }' "https://<platform-ip>:10027/v2/op/query"
 ```
@@ -947,20 +956,18 @@ The Context Broker replies with all the desired data, in R2 format (200 OK):
 ```json
 [
     {
-
         "type": "device",
         "id": "Dev0001",
         "switch_info": {
-            "type": "command_info",
+            "type": "commandResult",
             "value": "Switched successfully!"
         },
         "switch_status": {
-            "type": "command_status",
+            "type": "commandStatus",
             "value": "OK"
         }
     }
 ]
-
 ```
 
 ### Scenario 3: commands (error)
@@ -978,11 +985,11 @@ curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -
             "isPattern": "false",
             "id": "Dev0001",
             "switch_info":{
-                "type": "command_info",
+                "type": "commandResult",
                 "value": "The switch could not be switched due to the following error: switch blocked"
             },
             "switch_status":{
-                "type": "command_status",
+                "type": "commandStatus",
                 "value": "ERROR"
             }
         }
@@ -999,11 +1006,11 @@ In this case, the Context Broker reply with the following response (200 OK):
         "type": "device",
         "id": "Dev0001",
         "switch_info": {
-            "type": "command_info",
+            "type": "commandResult",
             "value": ""
         },
         "switch_status": {
-            "type": "command_status",
+            "type": "commandStatus",
             "value": ""
         }
     }

package/doc/operations.md

@@ -99,11 +99,11 @@ The following table shows the alarms that can be raised in the IoTAgent library.
 log starting with the prefix "Raising [%s]:" (where %s is the alarm name). All the alarms are released by an info log
 with the prefix "Releasing [%s]". These texts appear in the `msg=` field of the generic log record format.
 
-| Alarm name  | Severity     | Description                                              |
-| :---------- | :----------- | :------------------------------------------------------- |
-| MONGO-ALARM | **Critical** | Indicates an error in the MongoDB connectivity           |
-| ORION-ALARM | **Critical** | Indicates a persistent error accesing the Context Broker |
-| IOTAM-ALARM | **Critical** | Indicates a persistent error accessing the IoTAM         |
+| Alarm name     | Severity     | Description                                              |
+| :------------- | :----------- | :------------------------------------------------------- |
+| MONGO-ALARM_XX | **Critical** | Indicates an error in the MongoDB connectivity           |
+| ORION-ALARM    | **Critical** | Indicates a persistent error accesing the Context Broker |
+| IOTAM-ALARM    | **Critical** | Indicates a persistent error accessing the IoTAM         |
 
 while the 'Severity' criterium is as follows:
 
@@ -111,6 +111,9 @@ while the 'Severity' criterium is as follows:
 -   **Major** - The system has a problem that degrades the service and must be addressed
 -   **Warning** - It is happening something that must be notified
 
+In order to identify the internal flow which origins a mongo alarm, there is a suffix `_XX` which identifies from `01` to
+`11` each flow.
+
 ## Error naming code
 
 Every error has a code composed of a prefix and an ID, codified with the following table:

package/doc/requirements.txt

@@ -0,0 +1,4 @@
+mkdocs==1.2.3
+Pygments==2.9.0
+Markdown==3.3.4
+jinja2==3.0.0

package/{docs → doc}/roadmap.md

@@ -13,7 +13,7 @@ only, and this section may be revised to provide newer information at any time.
 
 Disclaimer:
 
--   This section has been last updated in March 2020. Please take into account its content could be obsolete.
+-   This section has been last updated in March 2022. Please take into account its content could be obsolete.
 -   Note we develop this software in Agile way, so development plan is continuously under review. Thus, this roadmap has
     to be understood as rough plan of features to be done along time which is fully valid only at the time of writing
     it. This roadmap has not be understood as a commitment on features and/or dates.
@@ -25,19 +25,17 @@ Disclaimer:
 The following list of features are planned to be addressed in the short term, and incorporated in a release of the
 product:
 
--   Selectively ignore measure in the southbound interface (community)
--   JEXL support in expressions (community)
 -   cgroup literal in configuration groups management API (community)
 -   Metadata processing improvements
--   Add MongoDB authentication support
+-   Improve command functionalities (binary data + expression + mapping)
 
 ### Medium term
 
 The following list of features are planned to be addressed in the medium term, typically within the subsequent
 release(s) generated in the next 9 months after the next planned release:
 
--   Support for "delta" measures (i.e. "temperature _increased_ in 5 degress" instead of "temperature _is_ 25")
--   Removal support for NGSIv1 (which currently is deprecated)
+-   Accept JEXL Expressions for entity name in autoprovisioned devices (#1145)
+-   Refactor entities-NGSI-v2.js module (#1166)
 
 ### Long term
 
@@ -48,3 +46,20 @@ us if you wish to get involved in the implementation or influence the roadmap:
 -   Incremental introduccion of ECMAScript6 syntax (previous analysis of which sub-set of interesting aspect we want to
     take)
 -   Use the lightweight ingestion mechanism for connection oriented updates implemented in Context Broker
+-   Add support to other transport protocols (BacNET, Modbus, etc)
+
+### Features already completed
+
+The following list contains all features that were in the roadmap and have already been implemented.
+
+-   Support for "delta" measures (i.e. "temperature _increased_ in 5 degress" instead of "temperature _is_ 25")
+-   Allow to handle binary messages ([iota-ul#530](https://github.com/telefonicaid/iotagent-ul/issues/530))
+-   Removal support for NGSIv1 (#966) ([2.18.0](https://github.com/telefonicaid/iotagent-node-lib/releases/tag/2.18.0))
+-   Selectively ignore measure in the southbound interface
+    ([iotagent-json#416](https://github.com/telefonicaid/iotagent-json/issues/416),
+    [iotagent-ul#372](https://github.com/telefonicaid/iotagent-ul/issues/372))
+    ([2.13.0](https://github.com/telefonicaid/iotagent-node-lib/releases/tag/2.13.0))
+-   JEXL support in expressions (#801, #687, #868)
+    ([2.13.0](https://github.com/telefonicaid/iotagent-node-lib/releases/tag/2.13.0))
+-   Add MongoDB authentication support (#844)
+    ([2.12.0](https://github.com/telefonicaid/iotagent-node-lib/releases/tag/2.12.0))