• State Not Answered
  • Replies 64 replies
  • Subscribers 76 subscribers
  • Views 10319 views
  • Users 0 members are here
Attachments (10) Download All
Nordic Case Info
  • Case ID: 250233
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

mqtt_simple connect to AWS

Timothy

I have an AWS account and I am comfortable with the AWS IOT operation in general. I have used it in the past. I am trying to get the sample mqtt_simple to connect to AWS IOT and be able to send packets and receive packets to the nRF9160dk board.

 I am not sure how to set up mqtt_simple parameters? I have created a thing and certificates. I have named the thing "nrf-IMEI" as recommended so it has the board ID in it. All I want to do is to be able to publish a packet to a topic on my AWS account and receive a packet from a topic in my AWS account. I have done this several times in the past with other systems so I am comfortable with AWS IOT operations and formats. I just do not understand how to get mqtt_simple to publish from my board to AWS and subscribe to messages from AWS.

Is this the correct program to use. It seems like all the pieces are there I just do not know how to use them.

I appreciate any help you can give, This is an essential requirement of our production system. right now we are using the pre-production system with a modified version of asset_tracker to send sensor data to the nRF Connect site. We need to be able to send sensor data to our AWS site.

Parents
  • 0

    Hi Timothy,

    I see that you have added some configurations in the Kconfig file, but would instead invite you to instead add the Kconfig options from the AWS fota sample:
    https://github.com/nrfconnect/sdk-nrf/blob/master/samples/nrf9160/aws_fota/Kconfig#L13

    And insert your correct MQTT_BROKER_HOSTNAME etc..

    and remember to 

    CONFIG_USE_NRF_CLOUD=y
    I also see changes that you have done in the main.c file
    e.g. cjson_init etc. --> https://github.com/nrfconnect/sdk-nrf/pull/2035/files recommended to just have that in the cloud_codec instead.
  • 0 in reply to Martin Lesund

    Martin

    I added the lines you suggested and matched up things for my AWS account in Kconfig. I removed the Cjson_int since it is already in cloud_codec.c. no change. I get the exact same output.

  • 0 in reply to Timothy

    Martin

    I went back to the AWS_IOT backend where it sends flip data and then crashed. This matches what we have in V1.2.0 and what you had suggested using. I did some experimenting and found the following.

    if I return immediately in the call device_status_send(struct k_work *work) in main it does NOT crash and sends back the FLIP data and the sensor data.

    I then went further and returned immediately in the call modem_info_params_get in modem_info_parameters.c it does NOT crash and sends the FLIP and sensor data.

    I then went further and returned immediately in the call modem_data_get in modem_info_parameters.c and it does NOT crash and sends back FLIP and sensor data.

    Summary: I am using AWS_IOT as I am using n V1.2.0 as the backend. The only change to the code is a return immediate in the call as shown below.

    static int modem_data_get(struct lte_param *param)
    {
    return 0; /* XXX added TJM */

    So I am very close to getting V1.3.0 working. all works except it crashes when I get the modem information is what it looks like. Any ideas what I am missing or doing wrong at this point.

  • 0 in reply to Timothy

    Martin

    I believe I narrowed it down to where it is failing. I have added print statements as shown below. I will try to explain the steps and teh printout. my prints have an 'XXX' in them.

    If I do nothing (return immediately) in the device_status_send function all works fine and it does not crash. data is snet to mt AWS account as expected. If I only allow the AT_PARAM_TYPE_nUM_SHORT to be allowed things fail on the second call to the handler. I have the calles to AT_PARAM_TYPE_STRING disabled (no call to handler function).

    as you can see the first call to modem_data_get is type 1. this calles modem_info_short_get which gets the string "%XCBAND 13' from the at_cmd_write. this then gets decoded to retunr the value 13 in at_params_short_get. this looks correct to me. the next is a call for AT_PARAM_TYPE_STRING which is ignored.

    the next call is again a call for AT_PARAM_TYPE_NUM_SHORT but it has a param->type 4. at this point the at_cmd_write never returns and you reboot Zephyr.

    I belive I am very close and a lot is working and talking to my AWS account. It seems like it fails trying to get all of the modem information or issue AT commands or something. do I have some configuration incorrect? any ideas what is going on. I cannot proceed until I have all of teh modem information correctly. I use the IEMI, date, etc throughout my program. I would apreciate any help you can give and thank you for all of your help so far. remeber I am using teh AWS_IOT backend like first setup in this ticket not the NRF cloud used later.

    XXX device_status_send called
    XXX modem_info_params_get called
    XXX modem_data_get called param->type: 1 data_type: 1
    AT_PARAM_TYPE_NUM_SHORT
    XXX modem_info_short_get called info: 1
    [00:00:15.705,871] <inf> aws_fota: subscribed to notify-next topic
    [00:00:15.712,615] <inf> aws_jobs: Publish topic: $aws/things/nrf-352656100378150/jobs/$next/get
    [00:00:15.721,893] <inf> aws_jobs: Publish payload {"clientToken": ""}
    XXX at_cmd_write err: 0 recv_buf: %XCBAND: 13

    XXX modem_info_parse err: 0
    XXX at_params_short_get err: 0 value: 13
    XXX modem_data_get called param->type: 2 data_type: 3
    AT_PARAM_TYPE_STRING
    XXX modem_data_get called param->type: 4 data_type: 1
    AT_PARAM_TYPE_NUM_SHORT
    XXX modem_info_short_get called info: 4
    [00:00:16.003,173] <dbg> aws_iot.mqtt_evt_handler: MQTT_EVT_SUBACK: id = 2114 result = 0
    [00:00:16.021,759] <dbg> aws_iot.mqtt_evt_handler: MQTT_EVT_SUBACK: id = 31697 result = 0
    [00:00:16.254,486] <dbg> aws_iot.mqtt_evt_handler: MQTT_EVT_PUBACK: id = 56652 result = 0
    [00:00:16.307,220] <dbg> aws_fota.on_publish_evt: Received topic: $aws/things/nrf-352656100378150/jobs/$next/get/accepted
    [00:00:16.318,664] <inf> aws_fota: Checking for an available job
    [00:00:16.325,195] <dbg> aws_fota.get_job_execution: Job doc: {"clientToken":"","timestamp":1594064733}
    [00:00:16.335,327] <dbg> aws_fota.get_job_execution: Got only one field
    [00:00:16.342,407] <inf> aws_fota: No queued jobs for this device
    *** Booting Zephyr OS build v2.3.0-rc1-ncs1 ***

  • 0 in reply to Timothy

    Martin

    I have turned on all of the debugging I could think of. I have attached a log file. It seems that the AT command is not completing. sometimes the first AT command completes but eventually the AT command does not complete and it crashes. I see "Sending command AT%XCBAND" and then "Awaiting response for AT%XCBAND".  sometimes I see "at_cmd.socket_thread_fn: at_cmd_rx 18 bytes, %XCBAND: 13" so that it did complete. in any case it never gets any further and crashes in teh same place every time.

    I would appreciate any help you can give. I am pretty confused at this point. any idea what is going on or what I can try to fix this.

    log_07_07_2020.zip

  • 0 in reply to Timothy

    Martin

    in the function "int modem_info_params_get(struct modem_param_info *modem)" if I only use 1 " modem_data_get" then everything works fine and data is sent as shown below. I found I can use any one call to modem_data_get and all works.

    I have set  the following to get the results below. you see that currentBand is 13 as expected. I also tried by just sending the supported bands and that worked also. so it seems that I can only call modem_data_get once. This at least must be some clue as to what I am missing and why the seocnd call never returns the recived information.

            ret = modem_data_get(&modem->network.current_band);
    #if 0
           ret += modem_data_get(&modem->network.sup_band);

    {
  "state": {
    "reported": {
      "DEVICE": null,
      "device": {
        "networkInfo": {
          "currentBand": 13,
          "supportedBands": "",
          "areaCode": 0,
          "mccmnc": "",
          "ipAddress": "",
          "ueMode": 0,
          "cellID": 0,
          "networkMode": ""
        },
        "simInfo": {
          "uiccMode": 0,
          "iccid": "",
          "imsi": ""
        },
        "deviceInfo": {
          "modemFirmware": "",
          "batteryVoltage": 0,
          "imei": "",
          "board": "nrf9160dk_nrf9160",
          "appVersion": "v1.3.0",
          "appName": "asset_tracker_tjm_aws"
        },
        "serviceInfo": {
          "ui": [
            "GPS",
            "FLIP",
            "TEMP",
            "HUMID",
            "AIR_PRESS",
            "RSRP"
          ],
          "fota_v1": [
            "APP",
            "MODEM"
          ]
        }
      }
    }
  }
}

    "

  • 0 in reply to Timothy

    Martin

    I am running mfw_nrf9160_1.2.0.zip. that is the latest I found. Is there a V1.3.0 modem firmware needed for V1.3.0 SDK. could that be the problem?

Reply Children
Related
Terms of service