IoT-Hub-Portal
IoT-Hub-Portal copied to clipboard
Bug: I don't have a "LoRa" device after using "import device" feature
Expected Behavior
I tried to create 2 sensors at the same time using a CSV file with the import feature. I want it to be a LoRa device.
Current Behavior
In the details of my newly created devices, I don't have the "LORAWAN" tab. I also have a "Connect" button as if it was an IoT Edge device (instead of a classic sensor) (see screenshot in additional information below)
Steps to Reproduce
- Use the "Import" feature on the "Device List" page with this CSV file (created from the previously downloaded template) :
Id,Name,ModelId,TAG:assetId,TAG:locationCode,PROPERTY:AppKey,PROPERTY:AppEUI,PROPERTY:AppSKey,PROPERTY:NwkSKey,PROPERTY:DevAddr,PROPERTY:GatewayID,PROPERTY:Downlink,PROPERTY:ClassType,PROPERTY:PreferredWindow,PROPERTY:Deduplication,PROPERTY:RX1DROffset,PROPERTY:RX2DataRate,PROPERTY:RXDelay,PROPERTY:ABPRelaxMode,PROPERTY:SensorDecoder,PROPERTY:FCntUpStart,PROPERTY:FCntDownStart,PROPERTY:FCntResetCounter,PROPERTY:Supports32BitFCnt,PROPERTY:KeepAliveTimeout
00110011001100,Central_Test_STM_Import,dco_SteamTrap,CAR000.AssetId,CAR000.LocationCode,00,11,,,,,true,A,1,Drop,,,,true,myDecoder,,,,,86400
00220022002200,Central_Test_BOB_Import,eolane_BobAssistant-50-80-001-000,CAR000.AssetId,CAR000.LocationCode,00,11,,,,,true,A,1,Drop,,,,true,myDecoder,,,,,86400
Portal version: 4.13.2.170 LoRaWAN Stack version: 2.1.0
Additional Information
If needed, here is an example of a twin created as shown above :
{
"deviceId": "00110011001100",
"etag": "AAAAAAAAAAI=",
"deviceEtag": "NTY3MTc0MzE4",
"status": "enabled",
"statusUpdateTime": "0001-01-01T00:00:00Z",
"connectionState": "Disconnected",
"lastActivityTime": "0001-01-01T00:00:00Z",
"cloudToDeviceMessageCount": 0,
"authenticationType": "sas",
"x509Thumbprint": {
"primaryThumbprint": null,
"secondaryThumbprint": null
},
"modelId": "",
"version": 3,
"tags": {
"deviceName": "Central_Test_STM_Import",
"modelId": "dco_SteamTrap",
"assetId": "CAR000.AssetId",
"locationCode": "CAR000.LocationCode"
},
"properties": {
"desired": {
"$metadata": {
"$lastUpdated": "0001-01-01T00:00:00Z",
"$lastUpdatedVersion": 1
},
"$version": 1
},
"reported": {
"$metadata": {
"$lastUpdated": "0001-01-01T00:00:00Z"
},
"$version": 1
}
},
"capabilities": {
"iotEdge": false
}
}
Here is an example of a device created alone with the classic way
{
"deviceId": "0033003300330033",
"etag": "AAAAAAAAAAE=",
"deviceEtag": "NzQ1ODg4MTgw",
"status": "enabled",
"statusUpdateTime": "0001-01-01T00:00:00Z",
"connectionState": "Disconnected",
"lastActivityTime": "0001-01-01T00:00:00Z",
"cloudToDeviceMessageCount": 0,
"authenticationType": "sas",
"x509Thumbprint": {
"primaryThumbprint": null,
"secondaryThumbprint": null
},
"modelId": "",
"version": 2,
"tags": {
"deviceName": "Central_Test_STM_Classic",
"supportLoRaFeatures": "true",
"modelId": "dco_SteamTrap",
"assetId": "CAR000.AssetId",
"locationCode": "CAR000.LocationCode"
},
"properties": {
"desired": {
"AppEUI": "00",
"AppKey": "11",
"$metadata": {
"$lastUpdated": "0001-01-01T00:00:00Z",
"$lastUpdatedVersion": 1,
"AppEUI": {
"$lastUpdated": "0001-01-01T00:00:00Z",
"$lastUpdatedVersion": 1
},
"AppKey": {
"$lastUpdated": "0001-01-01T00:00:00Z",
"$lastUpdatedVersion": 1
}
},
"$version": 1
},
"reported": {
"$metadata": {
"$lastUpdated": "0001-01-01T00:00:00Z"
},
"$version": 1
}
},
"capabilities": {
"iotEdge": false
}
}
The main difference seems to be in the "SupportLoRaFeature" available in the 2nd twin, and not in the first one.
I just took a look at the code and noticed that we were just missing the TAG:supportLoraFeatures value in the CSV.
Could it be added to the template to avoid this mistake from our end users in the future ? Fixing it in v4.13 along with the latest version would be a great help too!