Code assumes devices remain online 100% -- does not try to "connect"

[PaulCharlton]

CloudRelay/src/Distech.CloudRelay.API/Services/AzureIotHubAdapter.cs

Line 67 in 6fea56b

var deviceMethod = new CloudToDeviceMethod(m_Options.Value.MethodName, TimeSpan.FromSeconds(responseTimeout));

current implementation is using: public CloudToDeviceMethod (string methodName, TimeSpan responseTimeout);

is there some good reason not to use?: public CloudToDeviceMethod (string methodName, TimeSpan responseTimeout, TimeSpan connectionTimeout);

See: https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.devices.cloudtodevicemethod.-ctor?view=azure-dotnet#Microsoft_Azure_Devices_CloudToDeviceMethod__ctor_System_String_System_TimeSpan_System_TimeSpan_

See also: https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-direct-methods#method-invocation regarding use of connectTimeoutInSeconds

[usdruscia]

@PaulCharlton There's no particular reason other than that most of the time, waiting X seconds for a disconnected/offline ECLYPSE device to come back online won't change anything, and the downside of this approach is that the delay will also be applied when querying an invalid device ID, which is something the teams wanted to avoid.

That being said, it might still be nice to have the ability to use the connectionTimeout for specific use cases/implementations.

[PaulCharlton]

@usdruscia perhaps would be best to allow the client of the API a choice in the matter ... for example, I am willing to wait an extra 5 seconds to get a clean response from an otherwise offline controller whose connection can be restored

[usdruscia]

@PaulCharlton Yes, I was thinking of an application setting for this. Not sure it's relevant to have this kind of timeout on a per-request basis.

[PaulCharlton]

personally, I would make it as flexible as possible .. a default setting from an ENV variable, and override that if a certain http header is provided