Minor changes

doc/api.md

@@ -32,6 +32,8 @@
         -   [Multientity measurement transformation support (`object_id`)](#multientity-measurement-transformation-support-object_id)
     -   [Command execution](#command-execution)
         -   [Triggering commands](#triggering-commands)
+        -   [Command reception](#command-reception)
+        -   [Command confirmation](#command-confirmation)
     -   [Timestamp Processing](#timestamp-processing)
     -   [Overriding global Context Broker host](#overriding-global-context-broker-host)
     -   [Multitenancy, FIWARE Service and FIWARE ServicePath](#multitenancy-fiware-service-and-fiware-servicepath)
@@ -968,9 +970,9 @@ adds a `TimeInstant` attribute as metadata for every other attribute in the same
 
 ### Triggering commands
 
-This starts the process of sending data to devices. It starts by updating an attribute into the context broker. You need to know which attributes correspond to commands and update them. You can declare the command related attributes at the registry process (as shown in the previous "Register your IoT device" section). Also, you can declare the protocol you want the commands to be sent (HTTP/MQTT) with the "transport" parameter at the registry process.
+This starts the process of sending data to devices. It starts by updating an attribute into the context broker. You need to know which attributes correspond to commands and update them. You can declare the command related attributes at the registry process. Also, you can declare the protocol you want the commands to be sent (HTTP/MQTT) with the `transport` parameter at the registry process.
 
-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:
+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:
 
 ```
 PUT /v2/entities/<entity_id>/attrs/ping?type=<entity_type>
@@ -1002,13 +1004,16 @@ Once the command is triggered, it is send to the device. Depending on transport
 
 **Push commands**
 
-Push commands are those that are sent to the device once the IoT Agent receives the request from the Context Broker. In order to send push commands it is needed to set the "endpoint": "http://[DEVICE_IP]:[PORT]" in the device or group provision. The device is supposed to be listening for commands at that URL in a synchronous way. Make sure the device endpoint is reachable by the IoT Agent.
+Push commands are those that are sent to the device once the IoT Agent receives the request from the Context Broker. In order to send push commands it is needed to set the `"endpoint": "http://[DEVICE_IP]:[PORT]"` in the device or group provision. The device is supposed to be listening for commands at that URL in a synchronous way. Make sure the device endpoint is reachable by the IoT Agent.
 
-Push commands are only valid for HTTP devices. For MQTT devices it is not needed to set the "endpoint" parameter. 
+Push commands are only valid for HTTP devices. For MQTT devices it is not needed to set the `endpoint` parameter. 
 
 **Poll commands**
 
-Poll commands are those that are stored in the IoT Agent waiting to be retrieved by the devices. This kind of commands are typically used for devices that doesn't have a public IP or the IP cannot be reached because of power or netkork constrictions. The device connects to the IoT Agent periodically to retrieve commands. In order to configure the device as poll commands you just need to ignore the "endpoint" parameter in the device provision.
+Poll commands are those that are stored in the IoT Agent waiting to be retrieved by the devices. This kind of 
+commands are typically used for devices that doesn't have a public IP or the IP cannot be reached because of 
+power or netkork constrictions. The device connects to the IoT Agent periodically to retrieve commands. In order 
+to configure the device as poll commands you just need to ignore the `endpoint` parameter in the device provision.
 
 Once the command request is issued to the IoT agent, the command is stored waiting to be retrieved by the device. In that moment, the status of the command is `"command_status":"PENDING"`. 
 
@@ -1025,7 +1030,7 @@ It can be also possible for a device to retrieve the commands from the IoT Agent
 
 ```
 POST /iot/json?k=<apikey>&i=<deviceId>&getCmd=1
-Content-Type: text/json
+Content-Type: application/json
 
 {"t":25,"h":42,"l":"1299"}
 ```
@@ -1037,22 +1042,31 @@ Once the command is retrieved by the device the status is updated to `"command_s
 
 ## MQTT devices
 
-For MQTT devices, it is not needed to declare and endpoint. The device is supposed to be subscribed to the following MQTT topic:
+For MQTT devices, it is not needed to declare and endpoint. The device is supposed to be subscribed to the 
+following MQTT topic:
 
 ```
 /<apiKey>/<deviceId>/cmd
 ```
 
-where it will receive the command information. Please note that the device should subscribe to the broker using the disabled clean session mode (enabled using `--disable-clean-session` option CLI parameter in mosquitto_sub). This option means that all of the subscriptions for the device will be maintained after it disconnects, along with subsequent QoS 1 and QoS 2 commands that arrive. When the device reconnects, it will receive all of the queued commands.
+where it will receive the command information. Please note that the device should subscribe to the broker 
+using the disabled clean session mode (enabled using `--disable-clean-session` option CLI parameter in 
+`mosquitto_sub`). This option means that all of the subscriptions for the device will be maintained after 
+it disconnects, along with subsequent QoS 1 and QoS 2 commands that arrive. When the device reconnects, it
+will receive all of the queued commands.
 
 ### Command confirmation
 
-Once the command is complely procesed by the device, it should return the result of the command to the IoT Agent. This result will be progressed to the Context Broker where it will be stored in the `command_info` attribute. The status of the command will be stored in the `command_status` attribute (`OK` if everything goes right). 
+Once the command is complely procesed by the device, it should return the result of the command to the IoT 
+Agent. This result will be progressed to the Context Broker where it will be stored in the `command_info` 
+attribute. The status of the command will be stored in the `command_status` attribute (`OK` if everything 
+goes right). 
 
 #### HTTP
 
 **Polling**
- Eventually, once the device makes the response request with the result of the command the status is updated to "command_status": "OK". Also the result of the command delivered by the device is stored in the "command_info" attribute.
+Eventually, once the device makes the response request with the result of the command the status is updated 
+to`"command_status": "OK"`. Also the result of the command delivered by the device is stored in the `command_info` attribute.
 
 #### MQTT