Merge pull request #194261 from rido-min/rido/pnpconvention

Describe ACK messages

Author: PRMerger19

articles/iot-develop/concepts-convention.md

@@ -3,15 +3,15 @@ title: IoT Plug and Play conventions | Microsoft Docs
 description: Description of the conventions IoT Plug and Play expects devices to use when they send telemetry and properties, and handle commands and property updates.
 author: rido-min
 ms.author: rmpablos
-ms.date: 07/10/2020
+ms.date: 04/06/2022
 ms.topic: conceptual
 ms.service: iot-develop
 services: iot-develop
 ---
 
 # IoT Plug and Play conventions
 
-IoT Plug and Play devices should follow a set of conventions when they exchange messages with an IoT hub. IoT Plug and Play devices use the MQTT protocol to communicate with IoT Hub.
+IoT Plug and Play devices should follow a set of conventions when they exchange messages with an IoT hub. IoT Plug and Play devices use the MQTT protocol to communicate with IoT Hub, AMQP is supported by IoT Hub and available in some device SDKs. 
 
 Devices can include [modules](../iot-hub/iot-hub-devguide-module-twins.md), or be implemented in an [IoT Edge module](../iot-edge/about-iot-edge.md) hosted by the IoT Edge runtime.
 
@@ -129,16 +129,29 @@ The device or module should confirm that it received the property by sending a r
 - `av` - an acknowledgment version that refers to the `$version` of the desired property. You can find this value in the desired property JSON payload.
 - `ad` - an optional acknowledgment description.
 
+### Acknowledgment responses
+
+When reporting writable properties the device should compose the acknowledgment message, using the four fields described above, to indicate the actual device state, as described in this table
+
+
+|Status(ac)|Version(av)|Value(value)|Description(av)|
+|:---|:---|:---|:---|
+|200|Desired version|Desired value|Desired property value accepted|
+|202|Desired version|Value accepted by the device|Desired property value accepted, update in progress (should finish with 200)|
+|203|0|Value set by the device|Property set from the device, not reflecting any desired|
+|400|Desired version|Actual value used by the device|Desired property value not accepted|
+|500|Desired version|Actual value used by the device|Exception when applying the property|
+
 When a device starts up, it should request the device twin, and check for any writable property updates. If the version of a writable property increased while the device was offline, the device should send a reported property response to confirm that it received the update.
 
-When a device starts up for the first time, it can send an initial value for a reported property if it doesn't receive an initial desired property from the hub. In this case, the device should set `av` to `1`. For example:
+When a device starts up for the first time, it can send an initial value for a reported property if it doesn't receive an initial desired property from the hub. In this case, the device can send the default value with `av` to `0` and `ac` to `203`. For example:
 
 ```json
 "reported": {
   "targetTemperature": {
     "value": 20.0,
-    "ac": 200,
-    "av": 1,
+    "ac": 203,
+    "av": 0,
     "ad": "initialize"
   }
 }
@@ -164,7 +177,7 @@ When the device reaches the target temperature it sends the following message:
   "targetTemperature": {
     "value": 20.0,
     "ac": 200,
-    "av": 3,
+    "av": 4,
     "ad": "Reached target temperature"
   }
 }