Azure-iot-sdk-csharp: Twin.DeviceId and Twin.ModuleId return null

[Hammatt]

• OS, version, SKU and CPU architecture used: Windows 10 Desktop x64
• Application's .NET Target Framework : netcoreapp2.1
• Device: Surface Pro (i5)
• SDK version used: Microsoft.Azure.Devices.Client 1.17.0-preview-007

Description of the issue:

When calling Twin.DeviceId or Twin.ModuleId, null is returned.
other properties (e.g. Twin.Properties) are properly populated

Code sample exhibiting the issue:

C# Twin myTwin = await ioTHubModuleClient.GetTwinAsync(); Debug.WriteLine($"Module ID:{myTwin.ModuleId}"); Debug.WriteLine($"Device ID: {myTwin.DeviceId}");

Console log of the issue:

Module ID:
Device ID:

[CIPop]

@damonbarry @varunpuranik PTAL.

[varunpuranik]

Hi Hammatt,
Thanks for reporting. This looks like a bug, we will investigate.
Just one question - you are connecting the module to an EdgeHub (and not directly to the IotHub), right? In case you are unsure, you can tell us how you are getting the connection string - from the Environment variable or is it hardcoded?

[Hammatt]

Hi @varunpuranik,
Yes, here is the code I am using to connect to the hub.
C# string myConnectionString = Environment.GetEnvironmentVariable("EdgeHubConnectionString"); ioTHubModuleClient = IoTModuleClient.CreateFromConnectionString(myConnectionString, mySettings);
where ioTHubModuleClient is a ModuleClient

[varunpuranik]

Great, thanks @Hammatt . I will look into it.

[varunpuranik]

Hi @Hammatt,
Those properties are null by design - IoTHub doesn't set those properties as the device/module is expected to know them already.

Maybe we can look at removing them from the Device SDK (or marking them as obsolete).

[CIPop]

Closing as by design.
@Hammatt feel free to re-open if you disagree.

[Hammatt]

Hi @varunpuranik, thanks for the quick response.
I wanted to use these in my logging implementation for sending data up to Application Insights, to be able to correlate which device & module is sending which data up.

You mention that the device/module is expected to know this already, how exactly should we be getting this information?
this information was present in the module twin when I look at it in the hub, so I would expect a way to get this out of the twin.

[Hammatt]

Hey @CIPop, I can't see an option to re-open myself (I think I can only do that if I was the one that closed it?)
I do need the device/module id's for my Application Insights as described above. If there's a different way that I should be getting this information then if I could get pointed at that by somebody that would be fine, otherwise I would disagree with the design as it's information which is present in the twin when viewed in the portal & I do need it locally for the reason described.
Thanks.

[CIPop]

I always thought that the OP can always reopen...

Keeping this opened until we can get a solution on how to obtain the device and module ID.

At the moment I see two ways:

1. Parse the connection string.
2. If Provisioning was used, the information is available from the RegisterAsync API return.

Marking as an enhancement to add new API on DeviceClient and ModuleClient to expose this information in the future.

[Hammatt]

1. I believe the connection string gives the device ID but not the module ID?
2. By Provisioning, do you mean using the DPS? I don't believe that the DPS is compatible with Edge preview (yet?) unless I'm missing something.

I would still press that the most natural seeming way to get this info would be out of the twin, as it's present there when you inspect the module twin in the portal.

[varunpuranik]

The connection should have both the DeviceId and the ModuleId.

[Hammatt]

Doh! sorry, I was looking at the connection string that iotedgectl sees, not the one that the modules will see. I see that it must have the module ID too so that it knows which module twin to get for its configuration etc.
Parsing the connection string should work for me for now, but I'd still love to see it included in the sdk if possible.
Thanks.

[jason-e-gross]

I'm with Hammatt -- there's no reason the module should have to parse the connection string to identify itself. Feels caveman. The moduleId and deviceId should be populated in the result when the GetTwinAsync is called. Everything else is in the Twin (along with $version and $metadata - which we really don't care about for every day module usage) - why not include useful bits?

The iotedgectl knows me, the events going out know me [connection-module-id]. Why make it more compute to parse a string to get me to know me? I personally like to use my moduleId as a custom property in throwing events around local on the device between modules.

[Hammatt]

During the migration to GA, I noticed the connection string has gone missing. the new workaround for this is to use the new environment variables which have appeared:
C# string myModuleId = Environment.GetEnvironmentVariable("IOTEDGE_MODULEID"); string myDeviceId = Environment.GetEnvironmentVariable("IOTEDGE_DEVICEID");

[jason-e-gross]

@Hammatt I was just going to pop in and voice mine here, too - I also noticed the ModuleId and DeviceId are showing up as env-vars, so I was going to pull back my whining about wanting it in the ModuleTwin as well.

Thanks all.

[AMCN41R]

Personally, I don't mind getting the device id from the twin or environment. I just think its a little confusing as a developer due to the fact that the property is available in the sdk and always returns null, but when you look at the twin in the Azure portal, the device id is populated. Perhaps some clearer documentation or removal from the sdk if it will never be returned?

On a related note, using the environment variable doesn't seem to work when running locally using the iotedgehubdev tool. Can anyone else confirm? I have iotedgehubdev, version 0.7.0 and have logged the following issue...

iotedgehubdev-issues-175

[CIPop]

@AMCN41R I agree with your thinking - unfortunately removing APIs from the Shared lib is almost impossible at this time. In v2 we will be able to redesign the Twin object so that it only exposes items that can and should be filled for the SDK in use (Device vs Service).

Added this to documentation area: feel free to submit a PR to add a doc comment for the properties.

[az-iot-builder-01]

@CIPop, @Hammatt, @jason-e-gross, @AMCN41R, thank you for your contribution to our open-sourced project! Please help us improve by filling out this 2-minute customer satisfaction survey