Azure IoT Hub DPS library seems to always reprovision our device

[Actif]

I am working with SDK: 2.5.0 and toolchain 2.5.0.
I am using the new nRF7002DK.

I created an application from the azure_iot_hub sample.

I am using the DPS for my provisioning.
It is important to note that we haven't modified the code other than adding log to help us.

I am experiencing the following issues:

During azure_iot_hub_dps_init(), we are correctly enabling the setting module, and the load is a success:

[00:00:07.963,104] <wrn> azure_iot_hub_dps: azure_iot_hub_dps_init
[00:00:07.963,134] <inf> azure_iot_hub_dps: No registration ID provided, using ID from Kconfig: device-01
[00:00:07.963,165] <inf> azure_iot_hub_dps: Setting DPS registration ID: device-01
[00:00:07.963,226] <inf> azure_iot_hub_dps: No ID scope provided, using ID scope from Kconfig: ********
[00:00:07.963,256] <inf> azure_iot_hub_dps: Setting DPS ID scope: ********
[00:00:07.963,378] <inf> azure_iot_hub_dps: Assigned device ID found:
[00:00:07.963,531] <inf> azure_iot_hub_dps: Assigned device ID length found: 9
[00:00:07.963,714] <inf> azure_iot_hub_dps: Azure IoT Hub hostname found:
[00:00:07.963,928] <inf> azure_iot_hub_dps: Azure IoT Hub hostname length found: 29
[00:00:07.963,958] <inf> azure_iot_hub_dps: Settings fully loaded
[00:00:07.963,989] <inf> azure_iot_hub_dps: State transition: DPS_STATE_UNINIT --> DPS_STATE_DISCONNECTED
[00:00:07.964,019] <inf> azure_iot_hub_sample: DPS registration status: AZURE_IOT_HUB_DPS_REG_STATUS_NOT_STARTED

During the azure_iot_hub_dps_start phase. The global dps_reg_ctx was not updated with the value. I am new, but could it be some thread caching problem?

[00:00:07.964,019] <wrn> azure_iot_hub_dps: azure_iot_hub_dps_start
[00:00:07.964,050] <wrn> azure_iot_hub_dps: Settings not found

Here's the code I added to get that output:

	if ((az_span_size(dps_reg_ctx.assigned_hub) > 0) &&
	    (az_span_size(dps_reg_ctx.assigned_device_id) > 0)) {
		LOG_WRN("Settings found");
		LOG_INF("Device \"%.*s\" is assigned to IoT hub: %.*s",
			az_span_size(dps_reg_ctx.assigned_device_id),
			(char *)az_span_ptr(dps_reg_ctx.assigned_device_id),
			az_span_size(dps_reg_ctx.assigned_hub),
			(char *)az_span_ptr(dps_reg_ctx.assigned_hub));

		LOG_INF("To re-register, call azure_iot_hub_dps_reset() first");

		dps_reg_ctx.status = AZURE_IOT_HUB_DPS_REG_STATUS_ASSIGNED;

		return -EALREADY;
	} else {
		LOG_WRN("Settings not found");
		LOG_INF("Device \"%.*s\" is assigned to IoT hub: %.*s",
			az_span_size(dps_reg_ctx.assigned_device_id),
			(char *)az_span_ptr(dps_reg_ctx.assigned_device_id),
			az_span_size(dps_reg_ctx.assigned_hub),
			(char *)az_span_ptr(dps_reg_ctx.assigned_hub));
	}

After that, we end up straight into the provisioning process:

[00:00:07.964,233] <inf> azure_iot_hub_dps: User name (size: 58): ******/registrations/device-01/api-version=2019-03-31
[00:00:07.964,263] <inf> mqtt_helper: State transition: MQTT_STATE_UNINIT --> MQTT_STATE_DISCONNECTED
[00:00:07.964,324] <inf> mqtt_helper: Resolving IP address for global.azure-devices-provisioning.net
[00:00:08.548,095] <inf> mqtt_helper: IPv4 Address found 52.228.85.227 (AF_INET)

Has anyone here already experienced the same issues?
Am I doing something wrong?

We have already experienced much trouble using this example on our nRF7002DK.
Has this example been thoroughly tested before releasing it to us?

Thanks for any advice regarding this issue. I am a beginner here, and any shared knowledge will be helpful.

Cheers!

[Simonr]

Hi again Vincent

We were able to reproduce this on our end in the meantime, and one of our devs discovered that the host name and dev ID is not loaded correctly. This morning I was told a pull request has been made where the settings are changed on the backend. Please check it out and confirm whether it solves the issues on your end. https://github.com/nrfconnect/sdk-nrf/pull/13180/commits/e46e68c1cf4fdcf5e7a8d24df7e0b70561248c0b 

Best regards,

Simon

[Actif]

Hi Simonr,

Did your team finally understand the reason for this bug?

[Simonr]

Hi again

We concluded this is not a bug, as azure_iot_dps_init has to be run to initialize the library, and azure_iot_dps_start must be run to start the DPS process. Since there is no connection to the DPS server, the DPS library locates the host name and device ID in the flash memory as part of the DPS process and is in the DPS API, not the connection itself.

Best regards,

Simon

[Actif]

Hi Simonr, 

I am speaking of https://github.com/nrfconnect/sdk-nrf/pull/13180/commits/e46e68c1cf4fdcf5e7a8d24df7e0b70561248c0b 

You had already clarify your previous point, in our previous discussion.

Regards,
Vincent

[Simonr]

Hi Vincent

Do you refer to the stability fixes or the issue where it doesn't work with the NVS backend?

The backend override has been removed and the mentioned stability fixes + clean-up has been done. The reason was that the nRF7002 board config overrode the hostname and device ID received during DPS. I'm not sure there is more to add than what's described in the sign-off by my colleague Simen.

Best regards,

Simon

[Actif]

Hi Simonr,

Thank you for the previous clarification regarding the fix that addressed the backend override issue. My inquiry today focuses on the ongoing investigation into the NVS backend problem that remains unresolved.

As noted in the commit documentation (e46e68c1cf4fdcf5e7a8d24df7e0b70561248c0b) by Simen S. Røstad: "Why it doesn't work with the NVS backend needs to be investigated."

Could you please provide an update on the status of this NVS backend investigation? Any insights into potential causes would be welcome.

Thank you for your assistance.

Sincerely,
Vincent