Azure-iot-sdk-c: Device twin partial update mechanism

Created on 6 Apr 2020  路  7Comments  路  Source: Azure/azure-iot-sdk-c

Hi,

I would like to have some clarification regarding the device twin update mechanism.

I have observed that the device always receive the full desired twin, even if I only update only some keys inside. for instance on this example, if an update is made on only one component I understand (and would expect) that only the part of the json with the component that change is pushed to the device.

The device would receive the following twin on turning the device off:

{
  "fanOn": "false"
}

The current behavior shows that the device receive all the twin:

{
  "fanOn": "false",
  "components": {
    "system": {
      "id": "17",
      "units": "farenheit",
      "firmwareVersion": "9.75"
    },
    "wifi" : { 
      "channel" : "6",
      "ssid": "my_network"
    },
    "climate" : {
      "minTemperature": "68",
      "maxTemperature": "76"
    }
  }
}

I tested using both az CLI and web portail, does it comes from this?

The two problems receiving all device twins are:

  • transmit unnecessary data
  • on receiving data, triggers behavior hooked to a value notification. In the previous examples, the device will change the minTemperature and maxTemperature even tho they haven't changed.

I also noticed that since recently the device now receive the "$version" corresponding to the local version for the desired key. Does that change come from a SDK update or the iothub service? How can I be notifid about next changes like this in the future?

Thanks,
Regards,

Alexis

investigation-required question

All 7 comments

The will accept partial updates for device twin desired properties. The hub will still send the update, even if the desired does not change from the current value. It should not send the other desired properties that was not part of the property update.

I verified this with the following sample.

azure-iot-sdk-c\iothub_client\samples\iothub_client_device_twin_and_methods_sample

twin payload update:
{
"deviceId": "mydevice",
"etag": "AAAAAAAAAAU=",
"deviceEtag": "OTYwNDUxNDAz",
"properties": {
"desired": {
"desired_maxSpeed": 55
}
}
}

Hi,

Using the SDK version 1.3.8 and az-cli 2.3.1 here what I get with the iothub_client_device_twin_and_methods_sample sample with the following small changes in deviceTwinCallback function:

if (newCar->changeOilReminder != NULL)
    {
        printf("--- Received a new changeOilReminder = %s\n", newCar->changeOilReminder);
        if ((oldCar->changeOilReminder != NULL) && (strcmp(oldCar->changeOilReminder, newCar->changeOilReminder) != 0))
        {
            free(oldCar->changeOilReminder);
        }

        if (oldCar->changeOilReminder == NULL)
        {
            printf("Setting a new changeOilReminder = %s\n", newCar->changeOilReminder);
            if ( NULL != (oldCar->changeOilReminder = malloc(strlen(newCar->changeOilReminder) + 1)))
            {
                (void)strcpy(oldCar->changeOilReminder, newCar->changeOilReminder);
                free(newCar->changeOilReminder);
            }
        }
    }

    if (newCar->settings.desired_maxSpeed != 0)
    {
        printf("--- Received a new desired_maxSpeed = %" PRIu8 "\n", newCar->settings.desired_maxSpeed);
        if (newCar->settings.desired_maxSpeed != oldCar->settings.desired_maxSpeed)
        {
            printf("Setting a new desired_maxSpeed = %" PRIu8 "\n", newCar->settings.desired_maxSpeed);
            oldCar->settings.desired_maxSpeed = newCar->settings.desired_maxSpeed;
        }
    }

Command on az-cli

az iot hub device-twin update -d <devicename> -n <iothubname> --set properties.desired.changeOilReminder=\"Today\"
az iot hub device-twin update -d <devicename> -n <iothubname> --set properties.desired.settings=\{\"desired_maxSpeed\":42\}
az iot hub device-twin update -d <devicename> -n <iothubname> --set properties.desired.settings=\{\"desired_maxSpeed\":12\}

Output of the sample

Device Twin reported properties update completed with result: 204
< first command sent >
--- Received a new changeOilReminder = Today
Setting a new changeOilReminder = Today
< second command sent >
--- Received a new changeOilReminder = Today
--- Received a new desired_maxSpeed = 42
Setting a new desired_maxSpeed = 42
< third command sent >
--- Received a new changeOilReminder = Today
--- Received a new desired_maxSpeed = 12
Setting a new desired_maxSpeed = 12

As you can observe in this log, on the second and third command, the device receive the value for both changeOilReminder and desired_maxSpeed desired properties, even if we only changed one.

I suspect the issue is with the CLI command. It is calling PATCH with the whole device twin document, not just the changed property.

You can go to the device in the UI portal and navigate to the device twin page and enter following json payload and click save.

 {
  "properties": {
    "desired": {
      "desired_maxSpeed": 55
    }
  }
}

This will update the desired property and you should get only one property update on your device

Ok it is working as expected using the Azure portal UI.

I also suspect that the issue comes from the CLI then, which is a bit problematic as I use it to script tests to validate the behavior of my device.

Can you forward this issue to the CLI team?
Thanks!

Thanks Eric!

This issue should be resolved in 0.9.2 via new patch arguments --desired and --tags. Until the extension is available on the extension index (usually takes a few days), you will have to pin the package installation via --source.

The steps are as follows:

First remove the existing installation: az extension remove --name azure-iot
Then add the latest via source: az extension add --source "https://github.com/Azure/azure-iot-cli-extension/releases/download/v0.9.2/azure_iot-0.9.2-py2.py3-none-any.whl"

Was this page helpful?
0 / 5 - 0 ratings

Related issues

vpetrigo picture vpetrigo  路  6Comments

moncef-bibani picture moncef-bibani  路  4Comments

vpetrigo picture vpetrigo  路  5Comments

thematrix9 picture thematrix9  路  4Comments

wlisac picture wlisac  路  4Comments