Azure IoT DPS: Does DPS support persistent sessions?

Question

In the DPS documentation (Communicate with DPS using the MQTT protocol) it states that "DPS doesn't support persistent sessions", but the behavior I am observing on my devices connected to Azure using DPS is that there is session persistence, since even a device that has been disconnected for more than a week when connecting to Azure indicates "Session Present" equal to true (MQTT » CONNACK » Session Present).

When I delete the Device through "IotCentral » Device Manager" and then connect the Device, this first time the connection indicates "Session Present" equal to false.

Can I trust the "Session Present" information from azure-iot-sdk to indicate that the device had or did not have a session present when connecting to Azure via DPS?

Log

• Device NOT deleted from IoTCentral before connecting to Azure

D (2023-11-15T18:36:38Z) DPS: Provisioning API Version: 1.3.4
D (2023-11-15T18:36:38Z) DPS: Iothub API Version: 1.3.4
D (2023-11-15T18:36:38Z) DPS: DPS task is waiting activation
I (2023-11-15T18:36:39Z) DPS: Initiating connection to IoTHub via DPS
I (2023-11-15T18:36:40Z) DPS: Registering Device ....
I (2023-11-15T18:36:45Z) DPS: Provisioning Status: PROV_DEVICE_REG_STATUS_CONNECTED
I (2023-11-15T18:36:46Z) DPS: Provisioning Status: PROV_DEVICE_REG_STATUS_ASSIGNING
I (2023-11-15T18:36:50Z) DPS: Registration Information received from service: XXXXX.azure-devices.net, XXXXX
I (2023-11-15T18:36:50Z) DPS: Registered successfully!
I (2023-11-15T18:36:50Z) DPS: Working with IoT Central.
V (2023-11-15T18:36:54Z) azure: -> 13:36:54 CONNECT | VER: 4 | KEEPALIVE: 20 | FLAGS: 128 | USERNAME: XXXXX.azure-devices.net/XXXXX/?api-version=2017-11-08-preview&DeviceClientType=iothubclient%2f1.3.4%20(native%3b%20freertos%3b%20esp%20platform) | CLEAN: 0
V (2023-11-15T18:36:56Z) azure: <- 13:36:56 CONNACK | SESSION_PRESENT: true | RETURN_CODE: 0x0

• Device deleted from IoTCentral before connecting to Azure

D (21994) DPS: Provisioning API Version: 1.3.4
D (21994) DPS: Iothub API Version: 1.3.4
D (22024) DPS: DPS task is waiting activation
I (23014) DPS: Initiating connection to IoTHub via DPS
I (23154) DPS: Registering Device ....
I (25974) DPS: Provisioning Status: PROV_DEVICE_REG_STATUS_CONNECTED
I (26404) DPS: Provisioning Status: PROV_DEVICE_REG_STATUS_ASSIGNING
I (28354) DPS: Registration Information received from service: XXXXX.azure-devices.net, XXXXX
I (28394) DPS: Registered successfully!
I (28444) DPS: Working with IoT Central.
V (32554) azure: -> 14:17:31 CONNECT | VER: 4 | KEEPALIVE: 20 | FLAGS: 128 | USERNAME: XXXXX.azure-devices.net/XXXXX/?api-version=2017-11-08-preview&DeviceClientType=iothubclient%2f1.3.4%20(native%3b%20freertos%3b%20esp%20platform) | CLEAN: 0
V (34454) azure: <- 14:17:33 CONNACK | SESSION_PRESENT: false | RETURN_CODE: 0x0

Answer 1

Hi @Bruno Siqueira I have raised this issue with our Content SME team. You can track this issue through the URL - MicrosoftDocs#117267 The team has identified the cause for this behavior as follows.

The session is being persisted by IoT Central, which uses DPS and IoT Hub under it. The DPS session is only used for registering the device to the correct hub and stablish the connection between the device and the IoT Hub, after that it has no role on the communication flow between device and IoT Hub. DPS session are non-persistent and every time the device is assigned to the hub, it will end the session, however the Device<->IoT Hub session will be stablished then. I believe that existing session is the log you are seeing from IoT Central.

You can learn more on this documentation in regards IoT Central persistent connections: Connectivity patterns

You can also learn more on DPS usage from IoT Central at Provision a device

Hope this provides some clarity on this behavior and answers your question. We will work on improving the document to avoid the confusion going forward.

---

If the response helped, please do click Accept Answer and Yes for the answer provided. Doing so would help other community members with similar issue identify the solution. I highly appreciate your contribution to the community.