Desired Properties callback not triggering after a reconnect
uriel-kluk opened this issue · 5 comments
I believe this used to work, surely I tested it many times with IOTC. but I started a new project connected to IoT Hub and got the same behavior as #450.
The following registration triggers as expected a callback when the device is connected:
await _client.SetDesiredPropertyUpdateCallbackAsync(OnDesiredPropertyChanged, _client, cancellationToken);
But if the device is disconnected and I change the device twin, it won't trigger.
The same thing happens with IoTEdge, therefore, it might be a problem with IoT Hub device twin not pushing the changes on reconnection.
Here is the client setup code:
Log.LogInformation("Creating Symmetric Key DeviceClient authentication");
var authentication = new DeviceAuthenticationWithRegistrySymmetricKey(DeviceId, security.GetPrimaryKey());
var options = new ClientOptions
{
ModelId = ModelId,
};
var _client = DeviceClient.Create(result?.AssignedHub, authentication, TransportType.Mqtt_Tcp_Only, options);
// --- set callback for connection status change
_client.SetConnectionStatusChangesHandler(ConnectionStatusChangeHandler);
// --- set callback for desired property for all the components
await _client.SetDesiredPropertyUpdateCallbackAsync(OnDesiredPropertyChanged, _client, cancellationToken);More details:
The twin shows the following elements:
"properties": {
"desired": {
"devicehealth": {
"__t": "c",
"dhInval": 300,
"HeartbeatInterval": 3600
},
"$metadata": {
"$lastUpdated": "2024-01-12T16:17:43.1751176Z",
"$lastUpdatedVersion": 22,
"devicehealth": {
"$lastUpdated": "2024-01-12T16:17:43.1751176Z",
"$lastUpdatedVersion": 22,
"__t": {
"$lastUpdated": "2024-01-12T16:17:43.1751176Z",
"$lastUpdatedVersion": 22
},
"dhInval": {
"$lastUpdated": "2024-01-12T16:17:43.1751176Z",
"$lastUpdatedVersion": 22
}, "reported": {
"devicehealth": {
"__t": "c",
"HeartbeatInterval": 3600,
"dhInval": {
"ac": 200,
"ad": "success",
"av": 18,
"value": 60
}
},
"$metadata": {
"$lastUpdated": "2024-01-12T15:54:07.8567909Z",
"devicehealth": {
"$lastUpdated": "2024-01-12T15:54:07.3099031Z",
"__t": {
"$lastUpdated": "2024-01-12T15:54:07.3099031Z"
},
"HeartbeatInterval": {
"$lastUpdated": "2024-01-12T15:54:07.3099031Z",
"ac": {
"$lastUpdated": "2024-01-12T04:57:59.0288154Z"
},
"ad": {
"$lastUpdated": "2024-01-12T04:57:59.0288154Z"
},
"av": {
"$lastUpdated": "2024-01-12T04:57:59.0288154Z"
},
"value": {
"$lastUpdated": "2024-01-12T04:57:59.0288154Z"
}
},
"dhInval": {
"$lastUpdated": "2024-01-12T04:57:59.0288154Z",
"ac": {
"$lastUpdated": "2024-01-12T04:57:59.0288154Z"
},
"ad": {
"$lastUpdated": "2024-01-12T04:57:59.0288154Z"
},
"av": {
"$lastUpdated": "2024-01-12T04:57:59.0288154Z"
},
"value": {
"$lastUpdated": "2024-01-12T04:57:59.0288154Z"
}
}
},Do you see this same behavior when using AMQP as well?
@timtay-microsoft , the documentation now says that you have to explicitly pull the device twin document.
We have devices in the field that used to get the callback triggered and now these don't.
This is the comment in the code that we previously deployed:
// After a reconnection to the IoT Hub,
// It's not strictly necessary to explicitly retrieve the device twin
// because the IoT Hub will automatically push any desired property 'updates'
// that occurred while the device was disconnected.
Could you help me track down if there indeed is a change on IoT Hub?
- Device app connects to an IoT hub.
- Device app subscribes for desired properties update notifications.
- Device app retrieves the full document for desired properties.
I believe the SDK team has always recommended that you do a getTwin call upon reconnection to "catch up" on any twin changes that happened while a device was disconnected.
However, if you are seeing a change in behavior from the IoT hub side, then I'd recommend opening a support ticket through the Azure Portal for your IoT hub in particular. The service team has been slowly making a major upgrade to Hubs and it is possible that your Hub was upgraded and came with this is regression. The support ticket should connect you to a service-side engineer who can look at your hub in particular to see if this is the case.
Closing this issue as I believe this is a question of service behavior, not SDK behavior.