Azure IoT Hub DPS library seems to always reprovision our device

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!

Parents
  • Thank you for specifying. I pinged the devs, and there has not been any progress on this unfortunately. I have made an internal ticket so that we can track this issue/investigation properly now, and will get back to you with any updates on it. I don't have an estimate on when exactly that would be unfortunately. Is there any rush on getting the NVS backend up and running on your end so that this should be prioritized?

    Best regards,

    Simon

  • Thank you for clarifying.

    We have documented and included the lingering NVS backend problem in our bug analysis process.
    While this isn't a time-critical issue for our immediate project, we are keenly interested in documenting the cause.

    Could you please keep us updated on any progress made by your team in investigating the cause of the NVS behaviour on the DK? Even incremental insights would be appreciated.

    Thank you for your continued assistance.

    Regards,
    Vincent

Reply
  • Thank you for clarifying.

    We have documented and included the lingering NVS backend problem in our bug analysis process.
    While this isn't a time-critical issue for our immediate project, we are keenly interested in documenting the cause.

    Could you please keep us updated on any progress made by your team in investigating the cause of the NVS behaviour on the DK? Even incremental insights would be appreciated.

    Thank you for your continued assistance.

    Regards,
    Vincent

Children
Related