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.

[Timothy]

Martin

The problem of not connecting was the SIM cards were full on both boards. I am loading and trying things a hundred times a day and I forgot to check the SIM cards. That still lives the original problem that it connects to AWS and crashes as soon as I do the first publish. I still need any insight you have into solving that  problem.

[Martin Lesund]

Hi Timothy,
The issue is most likely that cJSON_Init() never gets called.
If it's not called malloc/free from newlib will then be used, and this causes issues since malloc/free gets mixed up with k_malloc/k_free.

So if you call cJSON_init() someplace in your code it should work.

[Jan Tore Guggedal]

Hi, 

Yusuke, only nRF Cloud backend is officially supported and tested in NCS releases. I'm not aware of timeline for official AWS IoT support. I would expect it to work, however. 

Timothy, it looks like the client token object in received jobs message is empty. You could use debugger to check if that's the reason for crash.

I'm out of office the next few weeks, so I will unfortunately not be able to follow up much at this time. Hopefully Martin can pick it up or forward it to someone who can. If not, I will pick it up when I'm back. 

Best regards, 

Jan Tore 

[Timothy]

Can anyone tell where to look for the client token object in received jobs. How do I tell if jobs are empty and if so why are they empty? is that fatal? If they are empty who is supposed to put data in them? I appreciate any help you can give. I am sure it is something simple I have not added or set correctly. It does send the Flip data JSON packet so a lot has to be working for that to go to my AWS account.

[Timothy]

There is another problem with the V1.2.0 asset_tracker for AWS that is a show stopper. The Asset_tracker connects to AWS and sends the FLIP, device info, RSRP, and status information to our AWS site, This runs without a problem forever on any single board. We have seen no problem running for days at a time. I recently got a second board working and a colleague got a board working. We are all running the same code. When any one of the boards starts up and connects to AWS and tries to publish the other boards see a POLLHUP which resets the boards. These boards will then in turn reach the same connection point and reset the other boards. It is a death spiral.

How can two or more AWS connections be able to disconnect the MQTT connection on different boards no matter if they are located in different states. The only common denominator is the AWS account. All boards are connecting to the same AWS account which is a requirement since lambda functions on that account are putting all the data from the various boards into dynamodb tables.  any thing I could do to fix this problem would be appreciated.

[Timothy]

I forgot to mention that my two boards have two different sets of certificates.

[Timothy]

Each board had the same AWS_IOT_CLIENT_ID_STATIC. I gave each board a unique ID and that seems to make it work. I will let both boards run overnight to see if that fixes the problem. but all looks good so far.

[Martin Lesund]

Sounds good, let me know if there are new issues that may pop up.
Are there any pending questions left?

[Timothy]

Martin

yes the big problem is that V1.3.0 asset_tracker crashes. as stated earlier I get the FLIP data so I know it is talking to my AWS account then it crashes. I have printouts above. Jan made a suggestion but I did not understand it. can you help me understand how to stop V1.3.0 from crashing.

[Martin Lesund]

Hi Timothy,
Are having issues with the asset_tracker application from v1.3.0 with the default settings?
If so, please make sure that you have the latest modem firmware installed and that you are using the default configurations.

Please share the serial output log when this issue happens.

[Timothy]

Martin

here is the output log. the only difference in my configuration settings is shown below to account for the AWS connection. I do not see any error indication. it just crashes. I need to get V1.3.0 working with my AWS account so I can port over the complete V1.2.0 working program that is running now 24/7.

# MQTT
CONFIG_MQTT_LIB=y
CONFIG_MQTT_LIB_TLS=y

CONFIG_AWS_IOT=y

CONFIG_AWS_IOT_BROKER_HOST_NAME="xxxx.amazonaws.com"
CONFIG_CLOUD_BACKEND="AWS_IOT"
CONFIG_ASSET_TRACKER_LOG_LEVEL_DBG=y

[00:00:00.243,774] <inf> asset_tracker: Connecting to LTE network.
[00:00:00.250,518] <inf> asset_tracker: This may take several minutes.
[00:00:00.257,690] <dbg> lte_lc.lte_lc_system_mode_set: Sending AT command to set system mode: AT%XSYSTEMMODE=1,0,1,0
[00:00:00.276,702] <dbg> lte_lc.lte_lc_system_mode_set: Sending AT command to set system mode: AT%XSYSTEMMODE=1,0,1,0
+CEREG: 2,"9E03","026B8102",7,0,0,"11100000","11100000"
[00:00:02.185,699] <dbg> lte_lc.at_handler: +CEREG notification: +CEREG: 2,"9E03","026B8102",7,0,0,"11100000","11100000"

[00:00:02.197,631] <dbg> lte_lc.parse_psm_cfg: TAU: -1 sec, active time: -1 sec

+CSCON: 1
[00:00:02.235,412] <dbg> lte_lc.at_handler: +CSCON notification
[00:00:05.223,632] <dbg> watchdog.secondary_feed_worker: Feeding watchdog
+CEREG: 5,"9E03","026B8102",7,,,"11100000","11100000"
[00:00:05.884,063] <dbg> lte_lc.at_handler: +CEREG notification: +CEREG: 5,"9E03","026B8102",7,,,"11100000","11100000"

[00:00:05.895,812] <dbg> lte_lc.parse_psm_cfg: TAU: -1 sec, active time: -1 sec

[00:00:05.903,930] <inf> asset_tracker: Connected to LTE network.
[00:00:05.910,583] <inf> asset_tracker: Connecting to cloud, attempt 1 of 8
client_id_buf my-thing
CONFIG_AWS_IOT_BROKER_HOST_NAME a2uy3w9dvx40gv-ats.iot.us-east-1.amazonaws.com
client_broker_init passed
mqtt_connect passed
aws_iot_connect 0
[00:00:10.241,943] <inf> asset_tracker: Cloud connection request sent.
[00:00:10.249,053] <inf> asset_tracker: Connection response timeout is set to 30 seconds.
[00:00:10.257,873] <dbg> watchdog.secondary_feed_worker: Feeding watchdog
[00:00:15.265,319] <dbg> watchdog.secondary_feed_worker: Feeding watchdog
[00:00:17.252,349] <inf> aws_jobs: Subscribe: $aws/things/my-thing/jobs/notify-next
+CSCON: 0
[00:00:17.261,871] <dbg> lte_lc.at_handler: +CSCON notification
[00:00:17.268,585] <inf> aws_jobs: Subscribe: $aws/things/my-thing/jobs/$next/get/#
[00:00:17.277,465] <inf> asset_tracker: CLOUD_EVT_CONNECTED
[00:00:17.283,569] <inf> asset_tracker: Persistent Sessions = 0
[00:00:17.290,039] <inf> asset_tracker: CLOUD_EVT_READY
[00:00:17.296,600] <dbg> nrf9160_gps.init: GPS socket created, fd: 1232491587
[00:00:17.305,358] <inf> gps_control: GPS initialized
[00:00:17.812,713] <inf> aws_fota: subscribed to notify-next topic
[00:00:17.819,519] <inf> aws_jobs: Publish topic: $aws/things/my-thing/jobs/$next/get
[00:00:17.827,880] <inf> aws_jobs: Publish payload {"clientToken": ""}
+CSCON: 1
[00:00:17.836,608] <dbg> lte_lc.at_handler: +CSCON notification
[00:00:18.309,509] <dbg> aws_fota.on_publish_evt: Received topic: $aws/things/my-thing/jobs/$next/get/accepted
[00:00:18.320,098] <inf> aws_fota: Checking for an available job
[00:00:18.326,721] <dbg> aws_fota.get_job_execution: Job doc: {"clientToken":"","timestamp":1593695296}
[00:00:18.337,005] <dbg> aws_fota.get_job_execution: Got only one field
[00:00:18.344,177] <inf> aws_fota: No queued jobs for this device
*** Booting Zephyr OS build v2.3.0-rc1-ncs1 ***
[00:00:00.005,004] <inf> mcuboot: Starting bootloader

[Martin Lesund]

Please share the full prj.conf  (add it as a .zip if you have issues uploading it).

(make sure to have CONFIG_RESET_ON_FATAL_ERROR=n)