Updating reported properties failed with error {"message":"'Properties.Reported' size should be less than 32768 bytes.","errorCode":403100,"trackingId":"","details":null} type Microsoft.Azure.Devices.Client.Exceptions.IotHubException

[alaendle]

This is more a support request, but theoretically we should be able to deploy 50 containers, however practically this seems to be impossible, since under "normal" conditions you hit the 32kB device twin limit.

E.g we faced the message in the title while trying to deploy 29 containers - by taking a look at https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-device-twins#device-twin-size and just focusing on properties/desired I realized that a typical module in it's definition alone usually is around 1kB (for us).

E.g. something like the module definition below - other modules have less environment variables, but for that more createOptions that specify port bindings or volume mounts - so basically the size stays at around 1 kB per module - and we need to reserve around 2-3 kB for the reported properties of the system modules.

Since our applications are very modular - which is possible thanks to the abstraction of communication via the edgeHub - we have a relatively large number of individual containers, which we can or would like to place in groups via layered deployments. Maybe this is also related to the fact that we use the iot edge as a release vehicle in an enterprise IT setting - so we have fully fletched servers as runtime and not low powered embedded devices. Therefore, this 32kB limit seems problematic to us, and we would like to discuss what options there are in order not to be hampered by this limit.

If it gets us further faster, perhaps because this is more of a general product issue, we can also submit a support request via the Azure portal. Just let us know.

Thanks in advance for your assistance. And please don't hesitate to contact me if I was unclear or if I could contribute further information regarding the problem or the context it appears in.

Prototypical definition:

{
    "baseline-metrics": {
        "settings": {
            "image": "mcr.microsoft.com/azureiotedge-metrics-collector:1.1.2",
            "createOptions": ""
        },
        "type": "docker",
        "version": "1.0",
        "env": {
            "experimentalFeatures__AddIdentifyingTags": {
                "value": "true"
            },
            "UploadTarget": {
                "value": "AzureMonitor"
            },
            "MetricsEndpointsCSV": {
                "value": "http://edgeHub:9600/metrics,http://edgeAgent:9600/metrics"
            },
            "no_proxy": {
                "value": "edgeHub,edgeAgent"
            },
            "LogAnalyticsWorkspaceId": {
                "value": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
            },
            "LogAnalyticsSharedKey": {
                "value": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
            },
            "ResourceID": {
                "value": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
            },
            "https_proxy": {
                "value": "http://xxxxxxxxxxxxxxxxxxxxx:8080/"
            }
        },
        "status": "running",
        "restartPolicy": "always"
    }
}

[veyalla]

Hi @alaendle - thanks for the issue.

Therefore, this 32kB limit seems problematic to us, and we would like to discuss what options there are in order not to be hampered by this limit.

Unfortunately, this is not actionable from the edge side. The limitation is inherited from IoT Hub twin size limits. You could open an Azure support ticket for IoT Hub, but a heads-up that this has been requested in the past but hasn't make any progress.

[fswane]

@alaendle Hi Andreas

Did you resolve your reported properties size issue?

We deploy many containers to an IoT Edge Device exactly how you describe your deployment architecture and are running into the same size limitation.

Thanks

[alaendle]

@fswane - Not by now; as suggested I've opened a support ticket which is still in process.

[NeerajGulia]

@fswane - Not by now; as suggested I've opened a support ticket which is still in process.

Hi @alaendle, Any update on your support ticket. We have also opened a support ticket on same issue.

[alaendle]

Hi @NeerajGulia - At least nothing pleasing, our support ticket is still open, as it seems this feature is on the list for Azure IoT Central (which suffers the same limitation at the moment), but not Azure IoT Edge; so basically there is no solution - and the future is uncertain. Please let me know if you achieve a different/better result. We are still in contact with Microsoft to discuss our possibilities in the long-term (e.g. move to IoT central, ...).

[NeerajGulia]

Hi @alaendle - The Microsoft support engineer pointed us to look at azure-iot-hub-large-twin-example

[alaendle]

@NeerajGulia Many thanks for this perspective; unfortunately the workaround presented in the pointed repository is not of much help to use, since we mainly struggle with the size of the device twin of the edgeAgent - and discharging of some bytes for our own modules is not of much help.

[fswane]

@NeerajGulia I agree with @alaendle that the workaround suggested by support will not assist with this issue.

By the way, we have been using the pattern https://github.com/Azure-Samples/azure-iot-hub-large-twin-example and using it extensively to ship large configurations and it works well. But still, it does not solve the problem being discussed here.

[NeerajGulia]

Thanks @fswane and @alaendle, we also looked into azure-iot-hub-large-twin-example but found that this will only help to reduce the individual module configuration and will not help in case we want to reduce the device twin of the edgeAgent.

We are using 33 custom modules and around 182 routes. Unfortunately, in our case also, this is not helpful.