Currently, the simulator may meet connection failure randomly. It will cause the device failed to send and recevie any message. IoT Hub team suggested to re-create the DeviceClient object as a workaround. But it looks not enough, since sometime the it may take quite long time the reconnect to IoTHub even with the new created DeviceClient.
In this code change, we are going to improve the fault tolerance from angles below:
1. Upgrade the Device Client SDK to latest version
2. Add simulator scope check. If 50% devices was found in status "down", the whole simulator process will restart. It will happen only if the simulator was running as a WebJob in cloud environment.
3. [BugFix] Use “finally" statement to ensure the transport object was released
4. Add more trace log
The old js code will be cached by browser which causes many problems after
the new changes has been pushed. Append version parameter to the js path
to let the browser refresh new js code whenever we change the constant
version in the new release.
1. Remove Ericsson SMS Credential Manager
2. Replace project Connectivity with NuGet package
3. Remove publish profile
4. Remove Ericsson option from Advanced page
5. Fix the incorrect string resource file name
6. Remove broken unit test
It was suggested that to use just one key-value pair for single method:
<method signature>: <method description>
<method signature>:=<method name>--<parameter #0 type>-<parameter #0 name>--<parameter #1 type>-<parameter #1 name>...
Samples:
"SupportedMethods.FirmwareUpdate--string-fwPackageUri": "Firmware update"
"SupportedMethods.Ping": "Ping device"
Adjust behavior of device methods
1. Revert change of device method Reboot (no set TemperatureMeanValue anymore)
2. Postpone change of TemperatureMeanValue in device method FirmwareUpdate until reboot
Adjust behavior of device methods
1. Revert change of device method Reboot (no set TemperatureMeanValue anymore)
2. Postpone change of TemperatureMeanValue in device method FirmwareUpdate until reboot
Created two preset filters: unhealthy devices and old firmware
The desired conditions are:
Unhealthy devices
properties.reported.Config.TemperatureMeanValue > 60
Old firmware devices
properties.reported.System.FirmwareVersion < '2.0'
There is an issue in the IoT Hub device SDK which will cause random exception while trying to update reported properties. IoT Hub team suggested us to create a new DeviceClient object as workaround.
Since the exception will be raised randomly, in rare case it will even happen in the new created DeviceClient. So it is not enough to just create the new DeviceClient and try one time. In this code change, we are going to add a new IoTHubTransport wrapper to buffer the out-going reported properties until it was successfully updated to IoT Hub. Considering the telemetry event will be generated periodically, we will just drop those event if it was failed to be sent.
To avoid resource leak, we dispose the current DeviceClient when we are going to create a new one. But it may cause null referenced exception under some racing condition. So we are going to move all the operations on the DeviceClient to a single task “SendLoop” - We introduced two buffer for the out-going reported properties and telemetry events. All the "Send" operation on the IIoTHubTransport were converted to a "enqueue" operation and returned immediately. The “SendLoop” task will poll the buffer periodically and send them to IoT Hub. If any exception raised while sending to IoT Hub, the “SendLoop” task will mark the DeviceClient as unavailable, then dispose it and re-create a new one in next round.
Xiangzhi Sheng
Hui Jiang
v-celi
Hua Zhang
Darren Chuang
huazhan