iotagent-node-lib 4.9.0 → 4.10.0

package/.github/workflows/ci.yml

@@ -14,10 +14,10 @@ jobs:
     steps:
       - name: Git checkout
         uses: actions/checkout@v2
-      - name: Use Node.js 16.x
+      - name: Use Node.js 24.x
         uses: actions/setup-node@v1
         with:
-          node-version: 16.x
+          node-version: 24.x
       - name: Run Remark Markdown Linter
         run: |
           npm install
@@ -31,10 +31,10 @@ jobs:
     steps:
       - name: Git checkout
         uses: actions/checkout@v2
-      - name: Use Node.js 16.x
+      - name: Use Node.js 24.x
         uses: actions/setup-node@v1
         with:
-          node-version: 16.x
+          node-version: 24.x
       - name: Run EsLint Node.js Linter
         run: |
           npm install
@@ -51,8 +51,6 @@ jobs:
     strategy:
       matrix:
         node-version:
-          - 16.x
-          - 18.x
           - 20.x
           - 22.x
           - 24.x
@@ -80,10 +78,10 @@ jobs:
     steps:
       - name: Git checkout
         uses: actions/checkout@v2
-      - name: 'Test Coverage with Node.js 16.x'
+      - name: 'Test Coverage with Node.js 24.x'
         uses: actions/setup-node@v1
         with:
-          node-version: 16.x
+          node-version: 24.x
       - run: |
           npm install
           npm run test:coverage

package/Changelog

@@ -1,3 +1,9 @@
+4.10.0 (Oct 6th, 2025)
+
+- Add: command modes (new field cmdMode): legacy, notification and advancedNotification (#1732)
+- Fix: update device with useCBflowControl
+- Set Nodejs 20 as minimum version in packages.json (effectively removing Nodev16 and Nodev18 from supported versions)
+
 4.9.0 (Aug 22nd, 2025)
 
 - Add: support NGSI-LD QueryEntities endpoint for lazy attributes (#1722)

package/config.js

@@ -79,7 +79,8 @@ var config = {
     defaultType: 'Thing',
     expressLimit: '1Mb',
     useCBflowControl: false,
-    storeLastMeasure: false
+    storeLastMeasure: false,
+    cmdMode: 'legacy'
 };
 
 module.exports = config;

package/doc/admin.md

@@ -452,6 +452,17 @@ If this flag is activated, when iotAgent invokes Context Broker will use
 [flowControl option](https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/admin/perf_tuning.md#updates-flow-control-mechanism).
 This flag is overwritten by `useCBflowControl` flag in group or device. This flag is disabled by default.
 
+#### `cmdMode`
+
+Set command mode for the IoTAgent instance (it can be overriden by the `cmdMode` at group or device level). Possible values are:
+
+* `legacy` (used as default if this setting is not defined): IoTAgent commands will use Context Broker registers
+mechanims.
+* `notification`:  IoTAgent commands will use subscriptions to be notified for Context Broker commands.
+* `advancedNotification`: IoTAgent commands will use subscriptions to be notified for Context Broker commands (but in a different way as in `notification` mode)
+
+Have a look to [this document](devel/northboundinteractions.md) for more detail on how this modes work.
+
 ### Configuration using environment variables
 
 Some of the configuration parameters can be overriden with environment variables, to ease the use of those parameters
@@ -517,6 +528,7 @@ overrides.
 | IOTA_EXPRESS_LIMIT                   | `expressLimit`                  |
 | IOTA_STORE_LAST_MEASURE              | `storeLastMeasure`              |
 | IOTA_CB_FLOW_CONTROL                 | `useCBflowControl`              |
+| IOTA_CMD_MODE                        | `cmdMode`                       |
 
 Note:
 

package/doc/api.md

@@ -12,6 +12,7 @@
     -   [Special measures and attributes names](#special-measures-and-attributes-names)
     -   [Device to NGSI Mapping](#device-to-ngsi-mapping)
     -   [Device autoprovision and entity creation](#device-autoprovision-and-entity-creation)
+    -   [Entity creation when `cmdMode` is `notification`](#entity-creation-when-cmdmode-is-notification)
     -   [Entity Name expression support](#entity-name-expression-support)
     -   [Multientity support](#multientity-support)
     -   [Metadata support](#metadata-support)
@@ -257,9 +258,9 @@ Additionally for commands (which are attributes of type `command`) the following
     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)
--   **headers**: extra customer headers used when send command by HTTP transport (ignored in other kinds of
-    transports)
-Check full detail of these fields in [comand-transformations](https://github.com/telefonicaid/iotagent-json/blob/master/docs/usermanual.md#commands-transformations)
+-   **headers**: extra customer headers used when send command by HTTP transport (ignored in other kinds of transports)
+    Check full detail of these fields in
+    [comand-transformations](https://github.com/telefonicaid/iotagent-json/blob/master/docs/usermanual.md#commands-transformations)
 
 Note that, when information coming from devices, this means measures, are not defined neither in the group, nor in the
 device, the IoT agent will store that information into the destination entity using the same attribute name than the
@@ -276,6 +277,31 @@ If for any reason you need the entity at CB before the first measure of the corr
 IOTAgent, you can create it in advance using the Context Broker
 [NGSI v2 API](https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md).
 
+## Entity creation when `cmdMode` is `notification`
+
+Even when an entity should not be created (see [above section](#device-autoprovision-and-entity-creation)), when the device uses `cmdMode` set to `notification` an entity is created. In particular:
+
+* An entity is created at device provision time
+* That entity is created with an attribute corresponding to each commands. The value of that attribute at creation time is `null` (specifying in some way that the command has not been triggered yet). Note that if the attribute doesn't have any command, the entity is not created (even if `cmdMode` is `notification`).
+
+For instance, if device has commands `ping` and `switch` the entity corresponding to that device will be created at provising time with the following attributes:
+
+```
+...
+{
+    "ping": {
+        "type": "command",
+        "value": null
+    },
+    "switch": {
+        "type": "command",
+        "value": null
+    },
+}
+```
+
+**NOTE:** `command` is the usual type for attributes associated to commands, but the one used at provisioning time (`"command": [ ...]` field) will be actually used.
+
 ## Entity Name expression support
 
 By default, the entity name used to persist the device measures in the Context Broker can be defined in the device
@@ -1323,6 +1349,8 @@ as `command` in the [config group](#config-group-datamodel) or in the [device pr
 attributes are created using `command` as attribute type. Also, you can define the protocol you want the commands to be
 sent (HTTP/MQTT) with the `transport` parameter at the provisioning process.
 
+**NOTE**: in `advancedNotification` mode the command is not triggered updating an attribute, but creating a command execution entity. However, this mode has not been implemented yet so details are to be clarified.
+
 For a given device provisioned with a `ping` command defined, any update on this attribute "ping" at the NGSI entity in
 the Context Broker will send a command to your device. For instance, to send the `ping` command with value
 `Ping request` you could use the following operation in the Context Broker API:
@@ -1784,6 +1812,7 @@ Config group is represented by a JSON object with the following fields:
 | `endpoint`                     | ✓        | `string`       |            | Endpoint where the group of device is going to receive commands, if any.                                                                                                                                                                                                                                                                                                                                                            |
 | `storeLastMeasure`             | ✓        | `boolean`      |            | Store in device last measure received. See more info [in this section](admin.md#storelastmeasure). False by default                                                                                                                                                                                                                                                                                                                 |
 | `useCBflowControl`             | ✓        | `boolean`      |            | Use Context Broker flow control. See more info [in this section](admin.md#useCBflowControl). False by default                                                                                                                                                                                                                                                                                                                       |
+| `cmdMode`                      | ✓        | `string`       |            | Command mode that will use iotagent with CB: **legacy**, **notification** and **advancedNotification**. **Legacy** is based on registers. **notification** based on simplified schema of subscriptions. **Legacy** by default. More information on how the different modes work can be found in [the northbound interactions documents](devel/northboundinteractions.md).                                                                                                                                                                                                       |
 
 ### Config group operations
 
@@ -2007,6 +2036,7 @@ the API resource fields and the same fields in the database model.
 | `storeLastMeasure`    | ✓        | `boolean` |            | Store in device last measure received. Useful just for debugging purpose. See more info [in this section](admin.md#storelastmeasure). False by default.                                                                                                                                                                                                                                                                    |
 | `lastMeasure`         | ✓        | `object`  |            | last measure stored on device when `storeLastMeasure` is enabled. See more info [in this section](admin.md#storelastmeasure). This field can be cleared using `{}` in a device update request. In that case, `lastMeasure` is removed from device (until a next measure is received and `lastMesuare` gets created again).                                                                                                 |
 | `useCBflowControl`    | ✓        | `boolean` |            | Use Context Broker flow control. See more info [in this section](admin.md#useCBflowControl). False by default.                                                                                                                                                                                                                                                                                                             |
+| `cmdMode`             | ✓        | `string`  |            | Command mode that will use iotagent with CB: **legacy**, **notification** and **advancedNotification**. **Legacy** is based on registers. **notification** based on simplified schema of subscriptions. **Legacy** by default. More information on how the different modes work can be found in [the northbound interactions documents](devel/northboundinteractions.md).                                                                                                                                                                                              |
 
 ### Device operations
 

package/doc/devel/northboundinteractions.md

@@ -346,6 +346,8 @@ queries (and thus P2 and R2 payloads).
 
 ![General ](./img/scenario3.png 'Scenario 3: commands')
 
+**FIXME:** this scenario describes the registration-based commanding mechanism, which is currently deprecated. It should be reworked
+
 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
 of this document. It's worth mentioning that Orion Context Broker **will not** store locally any data about attributes
@@ -729,55 +731,58 @@ error, that error must follow the NGSI payloads described in the Scenario 1 erro
 
 ### Scenario 3: commands (happy path)
 
-#### Context Provider Registration
+The interactions depend on the command mode (`cmdMode`):
+
+* `legacy`
+* `notification`
+* `advancedNotification`
+
+The way of setting up Context Broker to IotAgent communication and the interaction between Context Broker and IoTAgent when the command is executed depends on the mode (thus specific subsections about it are provided next for the three modes). However, the way in which the command result is provided is the same to all modes (so it is described in a [common section](#result-reporting)).
 
-Scenario 3 relies on the Context Provider mechanism of the Context Broker. For this scenario to work, the IoTAgent must
+#### `legacy` mode
+
+##### Set up Context Broker to IotAgent comunication mechanism
+
+This mode relies on the Context Provider mechanism of the Context Broker. For this scenario to work, the IoTAgent must
 register its commands for each device, with a request like the following:
 
 ```bash
 curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "Fiware-service: workshop" \
   -H "fiware-servicepath:  /iota2ngsi " -H "x-auth-token: <token>" -d '{
-    "contextRegistrations": [
-        {
-            "entities": [
-                {
-                    "type": "device",
-                    "isPattern": "false",
-                    "id": "Dev0001"
-                }
-            ],
-            "attributes": [
-                {
-                    "name": "switch",
-                    "type": "command",
-                    "isDomain": "false"
-                }
-            ],
-            "providingApplication": "http://<target-host>:1026/v1"
-        }
-    ],
-    "duration": "P1M"
+   "dataProvided": {
+     "entities": [
+       {
+         "id": "Dev0001",
+         "type": "Device"
+       }
+     ],
+     "attrs": [ "switch" ]
+   },
+   "provider": {
+     "http": {
+       "url": "<value of the IOTA_PROVIDER_URL>"
+     }
+   }
 }' "https://<platform-ip>:1026/v2/registrations"
 ```
 
-If everything has gone OK, the Context Broker will return the following payload:
+If everything has gone OK, the Context Broker will return 201 Created with the ID of the registration in the `Location` header:
 
-```json
-{
-    "duration": "P1M",
-    "registrationId": "41adf79dc5a0bba830a6f3824"
-}
+```
+HTTP/1.1 201 Created
+Date: ...
+Fiware-Correlator: ...
+Location: /v2/registrations/41adf79dc5a0bba830a6f3824
+Content-Length: 0
 ```
 
 This ID can be used to update the registration in the future.
 
 The registration of the commands is performed once in the lifetime of the Device.
 
-#### Command Execution
+##### Command Execution
 
-##### Based in update (classic way)
-
-Scenario 3 begins with the request for a command from the User to the Context Broker (P1):
+Execution begins with the request for a command from the User to the Context Broker (P1):
 
 ```bash
 curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "Fiware-Service: workshop" \
@@ -785,7 +790,6 @@ curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -
     "entities": [
         {
             "type": "device",
-            "isPattern": "false",
             "id": "Dev0001",
             "switch": {
                 "type": "command",
@@ -793,7 +797,7 @@ curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -
             }
         }
     ],
-    "updateAction": "append"
+    "updateAction": "update"
 } ' "https://<platform-ip>:1026/v2/op/update"
 ```
 
@@ -823,38 +827,154 @@ Fiware-Correlator: 9cae9496-8ec7-11e6-80fc-fa163e734aab
       }
     }
   ],
-  "updateAction" : "append"
+  "updateAction" : "update"
 }
 ```
 
-The IoT Agent detects the selected attribute is a command, and replies to the Context Broker with a 204 OK (without
+The IoT Agent detects the selected attribute is a command, and replies to the Context Broker with a 204 No Content (without
 payload).
 
 This response just indicates that the IoT Agent has received the command successfully, and gives no information about
 the requested information or command execution.
 
-The Context Broker, forwards the same response to the user, thus replying the original request (200 OK):
+The Context Broker, forwards the same response to the user, thus replying the original request with 204 No Content.
 
-```json
-[
-    {
-        "type": "device",
-        "id": "Dev0001",
-        "switch": {
-            "type": "command",
-            "value": ""
+At this point, the command has been issued to the IoTAgent and the User doesn't still know what the result of its
+request will be.
+
+#### `notification` mode
+
+##### Set up Context Broker to IoTAgent comunication mechanism
+
+This mode relies on the notification mechanism of the Context Broker. For this scenario to work, the IoTAgent must
+subscribe its commands for each device, with a request like the following:
+
+```bash
+curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "Fiware-service: workshop" \
+  -H "fiware-servicepath:  /iota2ngsi " -H "x-auth-token: <token>" -d '{
+    "subject": {
+        "entities": [
+            {
+              "type": "device",
+              "id": "Dev0001",
+            }
+        ],
+        "condition": {
+            "attrs": [ "switch" ]
         }
+    },
+    "notification": {
+        "http": {
+            "url": "<value of the IOTA_PROVIDER_URL>/notify"
+        },
+        "attrsFormat": "simplifiedNormalized",
+        "attrs": [ "switch" ]
     }
-]
+}' "https://<platform-ip>:1026/v2/subscriptions"
 ```
 
+If everything has gone OK, the Context Broker will return 201 Created with the ID of the subscription in the `Location` header:
+
+```
+HTTP/1.1 201 Created
+Date: ...
+Fiware-Correlator: ...
+Location: /v2/subscription/60b0cedd497e8b681d40b58e
+Content-Length: 0
+```
+
+This ID can be used to update the subscription in the future.
+
+The subscription of the commands is performed once in the lifetime of the Device.
+
+##### Command Execution
+
+As in the legacy mode, execution begins with the request for a command from the User to the Context Broker (P1):
+
+```bash
+curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "Fiware-Service: workshop" \
+  -H "Fiware-ServicePath:  /iota2ngsi " -H "X-Auth-Token: <token>" -d '{
+    "entities": [
+        {
+            "type": "device",
+            "id": "Dev0001",
+            "switch": {
+                "type": "command",
+                "value": "54, 12"
+            }
+        }
+    ],
+    "updateAction": "update"
+} ' "https://<platform-ip>:1026/v2/op/update"
+```
+
+The Context Broker receives this update and detects that it triggers the subscription, so it
+notifies to the IoT Agent, as follows:
+
+```bash
+POST /notify HTTP/1.1
+Host: <target-host>:<northbound_port>
+Fiware-service: workshop
+Fiware-ServicePath: /iota2ngsi
+Accept: application/json
+Content-length: ...
+Content-type: application/json; charset=utf-8
+Ngsiv2-Attrsformat: simplifiedNormalized
+Fiware-Correlator: 9cae9496-8ec7-11e6-80fc-fa163e734aab
+
+{
+    "id": "Dev0001",
+    "type": "device",
+    "switch": {
+        "type": "command",
+        "value": "54, 12",
+        "metadata": {}
+    }
+}
+```
+
+The IoT Agent detects the selected attribute is a command, and replies to the Context Broker with a 204 OK (without
+payload).
+
+This response just indicates that the IoT Agent has received the command successfully, and gives no information about
+the requested information or command execution.
+
 At this point, the command has been issued to the IoTAgent and the User doesn't still know what the result of its
 request will be.
 
-##### Based in notification (new way)
+#### `advancedNotification` mode
+
+##### Set up ContextBroker to IOTA comunication mechanism
 
-A new way to ContextBroker provides a command to a IoTAgent is through notifications. In this case CB notify the command
-to the IotAgent with a request like the following:
+The communication mechanism will be based on subscriptions, although a different one than the one used in `notification` mode. Note this mode has not been implemented yet, so following should be taken as a draft:
+
+```bash
+curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "Fiware-Service: workshop" \
+  -H "Fiware-ServicePath:  /iota2ngsi " -H "X-Auth-Token: <token>" -d '{
+    "subject": {
+        "entities": [
+            {
+                "idPattern": ".*",
+                "type": "switchExecution"
+            }
+        ],
+        "condition": {
+            "expression": {
+                "q": "status:FORWARDED;targetEntityType:StreetLight"
+            }
+        }
+    },
+    "notification": {
+        "http": {
+            "url": "<value of the IOTA_PROVIDER_URL>/notify"
+        }
+    }
+}' "https://<platform-ip>:1026/v2/subscriptions"
+```
+
+##### Command Execution
+
+Command execution involves to create a *command execution entity* (details are yet to be implemented), which in sequence triggers a notification to IoTAgent as this one (draft)
 
 ```bash
 POST /notify HTTP/1.1
@@ -864,6 +984,7 @@ Fiware-ServicePath: /iota2ngsi
 Accept: application/json
 Content-length: 290
 Content-type: application/json; charset=utf-8
+Ngsiv2-Attrsformat: normalized
 Fiware-Correlator: 9cae9496-8ec7-11e6-80fc-fa163e734aab
 
 {
@@ -945,8 +1066,36 @@ In this case relevant fields are just `targetEntityId`, `targetEntityType`, `cmd
 The IoT Agent detects the selected attribute is a command, and replies to the Context Broker with a 204 OK (without
 payload).
 
+This response just indicates that the IoT Agent has received the command successfully, and gives no information about
+the requested information or command execution.
+
+At this point, the command has been issued to the IoTAgent and the User doesn't still know what the result of its
+request will be.
+
+As mentioned before, advanced notification mode has not been yet implemented. The following considerations are gap in the current implementation at IoT Agent side that should be addressed:
+
+-   Fields others than `targetEntityId`, `targetEntityType`, `cmd` and `params` (i.e. `execTs`, `status`, `info`,
+    `onDelivered`, `onOk`, `onError`, `onInfo`, `cmdExecution` and `dataExpiration`), are not actually used. By the
+    moment they are stored in the commands model (commands collection) but nothing is done with them appart from
+    storing.
+-   The "Result reporting" should not be a "hardwired" behaviour updating the entity associated to the device, but using
+    the corresponding `on*` attribute in the notificaiton (e.g. `onOk` in the case of success). That attribute would
+    typically be a [HATEOAS](https://en.wikipedia.org/wiki/HATEOAS) object like this
+    `"onOk": { "href": "/v2/entities/123456abcdefg/attrs/status?type=switchExecution", "method": "PUT" }`. Moreover, the
+    entity to be updated in that HATEOAS would be the transient entity corresponding to command execuion, not the entity
+    associated to the device.
+
+```
+PUT /v2/entities/123456abcdefg/attrs/status?type=switchExecution
+content-type: text/plain
+
+OK
+```
+
 #### Result reporting
 
+No matter the command mode (legacy or notification based), the result reporting is the same in all cases.
+
 Once the IoT Agent has executed the command or retrieved the information from the device, it reports the results to the
 Context Broker, with an updateContext (P1):
 
@@ -956,7 +1105,6 @@ curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -
     "entities": [
         {
             "type": "device",
-            "isPattern": "false",
             "id": "Dev0001",
             "switch_info": {
                 "type": "commandResult",
@@ -975,24 +1123,7 @@ curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -
 This update does not modify the original command attribute, but two auxiliary attributes, that are not provided by the
 IoT Agent (usually, those attributes has the same name as the command, with an added suffix).
 
-The Context Broker replies to the IoT Agent with a R1 payload (200 OK):
-
-```json
-[
-    {
-        "type": "device",
-        "id": "Dev0001",
-        "switch_info": {
-            "type": "commandResult",
-            "value": ""
-        },
-        "switch_status": {
-            "type": "commandStatus",
-            "value": ""
-        }
-    }
-]
-```
+The Context Broker replies to the IoT Agent with 204 No Content response (no payload).
 
 This operation stores the retrieved values locally in the Context Broker, so it can be retrieved with standard NGSI
 mechanisms.
@@ -1007,7 +1138,6 @@ curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -
   -H "Fiware-ServicePath:  /iota2ngsi " -H "X-Auth-Token: <token>" -d '{
     "entities": [
         {
-            "isPattern": "false",
             "id": "Dev0001",
             "type": "device"
         }
@@ -1038,30 +1168,6 @@ The Context Broker replies with all the desired data, in R2 format (200 OK):
 ]
 ```
 
-#### Differences regarding the new commands mode
-
-A new commands flow has been defined (involving also modifications at ContextBroker). As part of that design, commands
-are not sent to IOTAs using NGSIv2 notifications, but the current implementation has some differences regarding the
-desired behaviour, which are described next:
-
--   Fields others than `targetEntityId`, `targetEntityType`, `cmd` and `params` (i.e. `execTs`, `status`, `info`,
-    `onDelivered`, `onOk`, `onError`, `onInfo`, `cmdExecution` and `dataExpiration`), are not actually used. By the
-    moment they are stored in the commands model (commands collection) but nothing is done with them appart from
-    storing.
--   The "Result reporting" should not be a "hardwired" behaviour updating the entity associated to the device, but using
-    the corresponding `on*` attribute in the notificaiton (e.g. `onOk` in the case of success). That attribute would
-    typically be a [HATEOAS](https://en.wikipedia.org/wiki/HATEOAS) object like this
-    `"onOk": { "href": "/v2/entities/123456abcdefg/attrs/status?type=switchExecution", "method": "PUT" }`. Moreover, the
-    entity to be updated in that HATEOAS would be the transient entity corresponding to command execuion, not the entity
-    associated to the device.
-
-```
-PUT /v2/entities/123456abcdefg/attrs/status?type=switchExecution
-content-type: text/plain
-
-OK
-```
-
 ### Scenario 3: commands (error)
 
 In Scenario 3, errors can happen asynchronously, out of the main interactions. When the IoTAgent detects an error
@@ -1074,7 +1180,6 @@ curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -
     "entities": [
         {
             "type": "device",
-            "isPattern": "false",
             "id": "Dev0001",
             "switch_info":{
                 "type": "commandResult",
@@ -1090,23 +1195,6 @@ curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -
 } ' "https://<platform-ip>:1026/v2/op/update"
 ```
 
-In this case, the Context Broker reply with the following response (200 OK):
-
-```json
-[
-    {
-        "type": "device",
-        "id": "Dev0001",
-        "switch_info": {
-            "type": "commandResult",
-            "value": ""
-        },
-        "switch_status": {
-            "type": "commandStatus",
-            "value": ""
-        }
-    }
-]
-```
+In this case, the Context Broker reply with the a 204 No Content response (no payload).
 
 The User will acknowledge the error the next time he queries the Context Broker for information about the command.

package/lib/commonConfig.js

@@ -160,7 +160,8 @@ function processEnvironmentVariables() {
         'IOTA_LD_SUPPORT_DATA_TYPE',
         'IOTA_EXPRESS_LIMIT',
         'IOTA_USE_CB_FLOW_CONTROL',
-        'IOTA_STORE_LAST_MEASURE'
+        'IOTA_STORE_LAST_MEASURE',
+        'IOTA_CMD_MODE'
     ];
     const iotamVariables = [
         'IOTA_IOTAM_URL',
@@ -500,6 +501,9 @@ function processEnvironmentVariables() {
     } else {
         config.storeLastMeasure = config.storeLastMeasure === true;
     }
+    if (process.env.IOTA_CMD_MODE) {
+        config.cmdMode = process.env.IOTA_CMD_MODE;
+    }
 }
 
 function setConfig(newConfig) {

package/lib/model/Device.js

@@ -57,7 +57,9 @@ const Device = new Schema({
     useCBflowControl: Boolean,
     storeLastMeasure: Boolean,
     lastMeasure: Object,
-    oldCtxt: Object
+    oldCtxt: Object,
+    cmdMode: String,
+    subscriptionId: String
 });
 
 function load() {

package/lib/model/Group.js

@@ -67,7 +67,8 @@ const Group = new Schema({
     entityNameExp: String,
     payloadType: String,
     useCBflowControl: Boolean,
-    storeLastMeasure: Boolean
+    storeLastMeasure: Boolean,
+    cmdMode: String
 });
 
 function load() {

package/lib/services/common/iotManagerService.js

@@ -65,7 +65,8 @@ function register(callback) {
             endpoint: service.endpoint,
             transport: service.transport,
             useCBflowControl: service.useCBflowControl,
-            storeLastMeasure: service.storeLastMeasure
+            storeLastMeasure: service.storeLastMeasure,
+            cmdMode: service.cmdMode
         };
     }