Sending direct message to Class C device about iotedge-lorawan-starterkit

[ronniesa]

Hi, there is a mismatch of DR for you downlink message and what the device is expecting.
{"txpk":{"imme":true,"data":"oFRmYAMAAQABRH8lpTaUh5JKSS4o","tmst":0,"size":21,"freq":923.3,"rfch":0,"modu":"LORA","datr":"SF12BW500","codr":"4/5","powe":14,"ipol":true}}
We use the defaut US DR8 so datr is SF12BW500 but your device is expecting on DR12 SF8W500. Either you change the dropdown (RX2 Datarate) on your device to SF12 or you set this device twin: https://github.com/Azure/iotedge-lorawan-starterkit/blob/master/Docs/quickstart.md#device-reported-properties "RX2DataRate" to "12". I would try first to change the device dropdown. Let us know

[gerfen]

Hi @ronniesa,

Please bear with me as I'm still not as familiar with the LoRaWan spec as I should be.

Looking at the RX2 data rate dropdown for the device, SF12 is not a choice:

Further when I set "RX2DataRate" to "12" in the device twin, clear the LoRaWanNetworkSrvModule cache and force a device reconnect I see this in my logs [1] - twin RX2 DR value is not within acceptable values. When I send a C2D message with this configuration, my logs look like this[2] -- which appears to show that the twins config change had no effect?.

I'm a bit confused as how to proceed?

[1] Join logs

2019-06-14 11:04:23.055 Physical dataUp {"rxpk":[{"tmst":3663781628,"chan":4,"rfch":1,"freq":903.100000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":10.8,"rssi":-47,"size":23,"data":"AExrbmlMQHJVIjATkiJhUhFuYu4h7q4="}]}
2019-06-14 11:04:23.309 1152612292133022: join request received
2019-06-14 11:04:23.322 1152612292133022: querying the registry for OTAA device
2019-06-14 11:04:24.051 1152612292133022: using edgeHub local queue
2019-06-14 11:04:24.233 1152612292133022: getting device twin
2019-06-14 11:04:25.095 1152612292133022: done getting device twin
2019-06-14 11:04:25.586 1152612292133022: updating twin
2019-06-14 11:04:26.026 1152612292133022: twin updated
2019-06-14 11:04:26.032 1152612292133022: the provided RX2DataRate is not valid
2019-06-14 11:04:26.081 1152612292133022: device added to cache
2019-06-14 11:04:26.082 1152612292133022: **twin RX2 DR value is not within acceptable values**
2019-06-14 11:04:26.348 UDP: sending message with ID FFA1, to 172.18.0.1:57992
2019-06-14 11:04:26.352 UDP: message sent with ID FFA1
2019-06-14 11:04:26.353 UDP: packet with id FFA1 successfully transmitted by the aggregator
2019-06-14 11:04:26.357 1152612292133022: processing time: 00:00:03.3021507
2019-06-14 11:04:26.357 1152612292133022: JoinAccept {"txpk":{"imme":false,"data":"IHZX69HDnKzOPW3Syc5BzGk=","tmst":3668781628,"size":17,"freq":925.7,"rfch":0,"modu":"LORA","datr":"SF10BW500","codr":"4/5","powe":14,"ipol":true}}

[2] C2D logs

2019-06-14 11:07:59.099 1152612292133022: received cloud to device message from direct method: {"devEUI":"1152612292133022","fport":"1","messageId":"0001","confirmed":true,"payload":"HeaterOn"}
2019-06-14 11:07:59.140 1152612292133022: [class-c] down frame counter: 1
2019-06-14 11:07:59.155 1152612292133022: using standard second receive window
2019-06-14 11:07:59.347 1152612292133022: ConfirmedDataDown {"txpk":{"imme":true,"data":"oIgmjwIAAQABRiMrYiQhAGtUOasY","tmst":0,"size":21,"freq":923.3,"rfch":0,"modu":"LORA","datr":"SF12BW500","codr":"4/5","powe":14,"ipol":true}}
2019-06-14 11:07:59.347 UDP: sending message with ID 567D, to 172.18.0.1:57992
2019-06-14 11:07:59.348 UDP: message sent with ID 567D
2019-06-14 11:07:59.349 UDP: packet with id 567D successfully transmitted by the aggregator

[ronniesa]

Can you do a quick test set the "RX2DataRate" on the twin to "10" and set the device to use 0-SF10? and check if the ConfirmedDataDown message will use SF10BW500

[gerfen]

Ha! I was just in the process of doing just that. Unfortunately I'm not seeing any difference...

2019-06-14 12:54:47.970 1152612292133022: received cloud to device message from direct method: {"devEUI":"11526    12292133022","fport":"1","messageId":"0001","confirmed":true,"payload":"HeaterOn"}
2019-06-14 12:54:47.972 1152612292133022: [class-c] down frame counter: 2
2019-06-14 12:54:47.973 1152612292133022: using standard second receive window
2019-06-14 12:54:47.974 1152612292133022: ConfirmedDataDown {"txpk":{"imme":true,"data":"oD2S+AIAAgABdqrMabvWbU    QiscjB","tmst":0,"size":21,"freq":923.3,"rfch":0,"modu":"LORA","datr":"SF12BW500","codr":"4/5","powe":14,"ipol"    :true}}
2019-06-14 12:54:47.974 UDP: sending message with ID 2EC1, to 172.18.0.1:57992
2019-06-14 12:54:47.975 UDP: message sent with ID 2EC1
2019-06-14 12:54:47.977 UDP: packet with id 2EC1 successfully transmitted by the aggregator
2019-06-14 12:54:52.830 Statistic: {"stat":{"time":"2019-06-14 12:54:52 GMT","rxnb":1,"rxok":0,"rxfw":0,"ackr":    100.0,"dwnb":1,"txnb":1}}

[gerfen]

I see the same behavior if I change "RX2DataRate" on the twin to "8" and set the device to use 2 -SF8 on the device.

[ronniesa]

I think we have a bug on how we validate the DR for US.... let us check and come back to you

[gerfen]

OK. Let me know if I can provide any more info. Thanks!

[ronniesa]

Gerfen can you please post the twin properties -> reported -> RX2DataRate? (the desired you already posted so we don't need it)

[gerfen]

@ronnesia The reported RX2DataRate is 10, which is the same as the desired value.

[ronniesa]

Hi Gerfen, we found the bug and it is in fact related to the US freq we will post a quick fix beginning of next week so you can test it. Sorry for the inconvenience

[gerfen]

@ronniesa Thanks for the update.

…

--Michael

________________________________ From: ronniesa <[email protected]> Sent: Friday, June 14, 2019 4:56:19 PM To: Azure/iotedge-lorawan-starterkit Cc: Michael Gerfen; Author Subject: Re: [Azure/iotedge-lorawan-starterkit] Sending direct message to Class C device (#192) Hi Gerfen, we found the bug and it is in fact related to the US freq we will post a quick fix beginning of next week so you can test it. Sorry for the inconvenience — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#192?email_source=notifications&email_token=ABIJFZGG3SHU3MTOTBOSXITP2QAXHA5CNFSM4HX4BLF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXX6F4I#issuecomment-502260465>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABIJFZAKWW33QYO7NCUSBX3P2QAXHANCNFSM4HX4BLFQ>.

[Mandur]

Hello @gerfen could you try the branch 'mik-dev-us-fix' to see if it fix the issues you had?

[gerfen]

I'm having an issue deploying. I'm getting this on both my current production branch and the new mik-dev-us-fix branch so something in my dev environment has changed but I'm not sure what.

PS D:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit-1.0.0\iotedge-lorawan-starterkit\LoRaEngine> docker build  --rm -f "d:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit-1.0.0\iotedge-lorawan-starterkit\LoRaEngine\modules\LoRaWanNetworkSrvModule\Dockerfile.amd64" -t evolution.azurecr.io/lorawannetworksrvmodule:1.0.3-amd64 "d:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit-1.0.0\iotedge-lorawan-starterkit" && docker push evolution.azurecr.io/lorawannetworksrvmodule:1.0.3-amd64 && docker build  --rm -f "d:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit-1.0.0\iotedge-lorawan-starterkit\LoRaEngine\modules\LoRaWanPktFwdModule\Dockerfile.amd64" -t evolution.azurecr.io/lorawanpktfwdmodule:1.0.1-amd64 "d:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit-1.0.0\iotedge-lorawan-starterkit\LoRaEngine\modules\LoRaWanPktFwdModule" && docker push evolution.azurecr.io/lorawanpktfwdmodule:1.0.1-amd64
At line:1 char:343
+ ... tedge-lorawan-starterkit-1.0.0\iotedge-lorawan-starterkit" && docker  ...
+                                                                ~~
The token '&&' is not a valid statement separator in this version.
At line:1 char:415
+ ... h evolution.azurecr.io/lorawannetworksrvmodule:1.0.3-amd64 && docker  ...
+                                                                ~~
The token '&&' is not a valid statement separator in this version.
At line:1 char:791
+ ... lorawan-starterkit\LoRaEngine\modules\LoRaWanPktFwdModule" && docker  ...
+                                                                ~~
The token '&&' is not a valid statement separator in this version.
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : InvalidEndOfLine

I think I've encountered this in the past but I can't recall the fix. Any insight?

[ronniesa]

We have seen this issue also in some of our pc not sure yet why but you need to replace the && with a ; and it should work

[gerfen]

Sorry for being thick... in which file should I make that change?

[ronniesa]

in the vscode terminal just hit arrow up to recall the command and then change it there.... should be like this: docker build --rm -f "d:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit-1.0.0\iotedge-lorawan-starterkit\LoRaEngine\modules\LoRaWanNetworkSrvModule\Dockerfile.amd64" -t evolution.azurecr.io/lorawannetworksrvmodule:1.0.3-amd64 "d:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit-1.0.0\iotedge-lorawan-starterkit" ; docker push evolution.azurecr.io/lorawannetworksrvmodule:1.0.3-amd64 ; docker build --rm -f "d:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit-1.0.0\iotedge-lorawan-starterkit\LoRaEngine\modules\LoRaWanPktFwdModule\Dockerfile.amd64" -t evolution.azurecr.io/lorawanpktfwdmodule:1.0.1-amd64 "d:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit-1.0.0\iotedge-lorawan-starterkit\LoRaEngine\modules\LoRaWanPktFwdModule" ; docker push evolution.azurecr.io/lorawanpktfwdmodule:1.0.1-amd64

[ronniesa]

not sure what is causing this seems to be an VSCode Edge plug in issue....

[ronniesa]

in my version when I it build and publish iot edge.... is putting the ";" correctly instead of the && … but we have seen in other machines this issue

[gerfen]

@ronniesa - your suggestion worked for me. Thanks!

Something definitely changed in the last 4 to 6 weeks or so. I was able to successfully deploy at the end of April without issue.

[gerfen]

@Mandur and @ronniesa - I think we're getting closer. I am now seeing that a downlink message is being received by my class C device [1]. However, the command [2] I set up on the device is still not getting executed. Here are my logs[3]. For reference here is the entire twin info[4].

[1] class C device monitor

[2] device command

[3] Gateway logs

2019-06-17 16:00:05.209 1152612292133022: received cloud to device message from direct method: {"devEUI":"1152612292133022","fport":"1","confirmed":true,"payload":"HeaterOn","MessageId":"3596e623901843279a0bc840ad689a87"}
2019-06-17 16:00:05.250 1152612292133022: [class-c] down frame counter: 1
2019-06-17 16:00:05.458 1152612292133022: ConfirmedDataDown {"txpk":{"imme":true,"data":"oCzR4gIAAQABJzad6OOITYPBaP2c","tmst":0,"size":21,"freq":923.3,"rfch":0,"modu":"LORA","datr":"SF10BW500","codr":"4/5","powe":14,"ipol":true}}
2019-06-17 16:00:05.458 UDP: sending message with ID 145D, to 172.18.0.1:40854
2019-06-17 16:00:05.459 UDP: message sent with ID 145D
2019-06-17 16:00:05.460 UDP: packet with id 145D successfully transmitted by the aggregator

[4] twin info

{
  "deviceId": "1152612292133022",
  "etag": "AAAAAAAAABI=",
  "deviceEtag": "Nzk0Mzk0MzEx",
  "status": "enabled",
  "statusUpdateTime": "0001-01-01T00:00:00",
  "connectionState": "Connected",
  "lastActivityTime": "2019-06-17T15:50:11.3346203",
  "cloudToDeviceMessageCount": 0,
  "authenticationType": "sas",
  "x509Thumbprint": {
    "primaryThumbprint": null,
    "secondaryThumbprint": null
  },
  "version": 119,
  "properties": {
    "desired": {
      "AppEUI": "xxxxxxxxxxxxxxxxxxxxxxxxxx",
      "AppKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "ClassType": "C",
      "GatewayID": "evolution-gateway",
      "SensorDecoder": "DecoderValueSensor",
      "RX2DataRate": "10",
      "$metadata": {
        "$lastUpdated": "2019-06-17T15:52:56.2585423Z",
        "$lastUpdatedVersion": 18,
        "AppEUI": {
          "$lastUpdated": "2019-06-17T15:52:56.2585423Z",
          "$lastUpdatedVersion": 18
        },
        "AppKey": {
          "$lastUpdated": "2019-06-17T15:52:56.2585423Z",
          "$lastUpdatedVersion": 18
        },
        "ClassType": {
          "$lastUpdated": "2019-06-17T15:52:56.2585423Z",
          "$lastUpdatedVersion": 18
        },
        "GatewayID": {
          "$lastUpdated": "2019-06-17T15:52:56.2585423Z",
          "$lastUpdatedVersion": 18
        },
        "SensorDecoder": {
          "$lastUpdated": "2019-06-17T15:52:56.2585423Z",
          "$lastUpdatedVersion": 18
        },
        "RX2DataRate": {
          "$lastUpdated": "2019-06-17T15:52:56.2585423Z",
          "$lastUpdatedVersion": 18
        }
      },
      "$version": 18
    },
    "reported": {
      "AppSKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "NwkSKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "DevAddr": "02E2D12C",
      "FCntDown": 0,
      "FCntUp": 0,
      "DevEUI": "1152612292133022",
      "NetId": "010000",
      "DevNonce": "7DB6",
      "Region": "US915",
      "PreferredGatewayID": "xxxxxxxxxxxxxxxxxx",
      "RX2DataRate": 10,
      "$metadata": {
        "$lastUpdated": "2019-06-17T15:57:15.4440923Z",
        "AppSKey": {
          "$lastUpdated": "2019-06-17T15:57:15.4440923Z"
        },
        "NwkSKey": {
          "$lastUpdated": "2019-06-17T15:57:15.4440923Z"
        },
        "DevAddr": {
          "$lastUpdated": "2019-06-17T15:57:15.4440923Z"
        },
        "FCntDown": {
          "$lastUpdated": "2019-06-17T15:57:15.4440923Z"
        },
        "FCntUp": {
          "$lastUpdated": "2019-06-17T15:57:15.4440923Z"
        },
        "DevEUI": {
          "$lastUpdated": "2019-06-17T15:57:15.4440923Z"
        },
        "NetId": {
          "$lastUpdated": "2019-06-17T15:57:15.4440923Z"
        },
        "DevNonce": {
          "$lastUpdated": "2019-06-17T15:57:15.4440923Z"
        },
        "Region": {
          "$lastUpdated": "2019-06-13T14:38:03.1612933Z"
        },
        "PreferredGatewayID": {
          "$lastUpdated": "2019-06-17T15:57:15.4440923Z"
        },
        "RX2DataRate": {
          "$lastUpdated": "2019-06-17T15:57:15.4440923Z"
        }
      },
      "$version": 101
    }
  },
  "capabilities": {
    "iotEdge": false
  },
  "deviceScope": "ms-azure-iot-edge://xxxxxxxxxxxxxxxxxxx"
}

[ronniesa]

ok we are getting closer now it seems a payload issue do you send a string or byte array (rawPayload) https://github.com/Azure/iotedge-lorawan-starterkit/blob/master/Docs/quickstart.md#cloud-to-device-message ? Do you know the format and the port?

[gerfen]

I'm currently sending plain string via the 'payload' property. I can change my code to try sending a base64 encoded string via the 'rawPayload' variable. I'll try that and will report back.

[ronniesa]

It is worth a try with base64. Does the device have kind of workflow to parse the string? Also on which fport do you send the message?

[gerfen]

Success! Changing the message to use the 'rawPayload' property worked[1] ... here's proof[2]. Now I just need to get past the intermittent "Not found"[3] error related to IoT Edge. Any ideas on resolving that issue?

[1] Working message
{
	"devEUI": "1152612292133022",
	"fport": "55",
	"messageId": "0004",
	"confirmed": true,
	"rawPayload": "SGVhdGVyT24="
}

[2] Device monitoring

[3] Not found error.

[DirectMethod] Invoking Direct Method [ClearCache] to [xxxxxx/LoRaWanNetworkSrvModule] ...
[DirectMethod] Failed to invoke Direct Method: Not found

[gerfen]

I should add that currently when I get the "Not found" error, I have to issue

sudo iotedge restart edgeHub
sudo iotedge restart LoRaWanNetworkSrvModule

then restart my device by disconnecting its power and waiting for it to reconnect, which is time consuming and a bit painful.

That said I'm really grateful for all of the help!

[ronniesa]

cool, yep the issue that you describe is due to a bug on IoT Edge you can try to use 1.0.7 of edgeAgent and egeHub just be aware that we did not run the whole test suite against this version yet

[gerfen]

OK. I'm currently testing in my development environment so I have the ability to experiment freely. I'll will try 1.0.7 of edgeAgent and will report back.

[gerfen]

Unfortunately, I see the exact same behavior with edgeAgent 1.0.7. I've restarted my gateway and confirmed that the new version is running...

gerfen@BLYN-LORA:~$ sudo iotedge list
NAME                     STATUS           DESCRIPTION      CONFIG
LoRaWanPktFwdModule      running          Up 10 minutes    evolution.azurecr.io/lorawanpktfwdmodule:1.0.4-amd64
edgeHub                  running          Up 10 minutes    mcr.microsoft.com/azureiotedge-hub:1.0.6
LoRaWanNetworkSrvModule  running          Up 10 minutes    evolution.azurecr.io/lorawannetworksrvmodule:1.0.4-amd64
edgeAgent                running          Up 10 minutes    mcr.microsoft.com/azureiotedge-agent:1.0.7

If there anything I can do to help get this issue resolved, please let me know.

[gerfen]

Gah! I just noticed that you suggested updating the edgeHub as well. Doing that now.

[gerfen]

OK. Updating the edgHub to 1.0.7 as well has significantly improved the situation. I am no longer getting the "not found" error - even after letting my dev environment sit idle for a period of time. I'm going to let it sit idle for the next hour or so. Hopefully things just keep working. I'll close this issue one way or the other after a run a few more tests.

[gerfen]

Happy to report the system is stable after upgrading both edgeAgent and edgeHub to 1.0.7. I'm going to close this. Thanks again @Mandur and @ronniesa!