How best to begin new nRF91 MQTT project connecting to AWS

[craig.goldman]

I am re-starting a project to send MQTT topics to AWS.  At this point, is MQTT_Simple still the best way to start and then modify the endpoint as suggested in case 224855 or would it be better to start with something like Asset_Tracker (or maybe something else)?  I am particularly concerned about the effort to add certificate and keys to MQTT_Simple code.

[Didrik Rokhaug]

Hi.

mqtt_simple is probably the easiest place to start from, as there is very little "extra" other than just connecting to a broker. However, the mqtt_simple does not support TLS. For this, asset_tracker or the nrf_cloud library is a good place to look. Especially nrf_cloud_transport.c which contains all the MQTT related code. Adding TLS to mqtt_simple requires very few changes. If the certificates are already provisioned, e.g. with AT commands and the Certificate Manager tab in the Link Monitor, the only changes needed is to configure the mqtt_client to use TLS. The result should be something like this (from case 224855):

/**@brief Initialize the MQTT client structure
 */
static void client_init(struct mqtt_client *client)
{
	mqtt_client_init(client);

	broker_init();

	/* MQTT client configuration */
	client->broker = &broker;
	client->evt_cb = mqtt_evt_handler;
	client->client_id.utf8 = (u8_t *)CONFIG_MQTT_CLIENT_ID;
	client->client_id.size = strlen(CONFIG_MQTT_CLIENT_ID);
	client->password = NULL;
	client->user_name = NULL;
	client->protocol_version = MQTT_VERSION_3_1_1;

	/* MQTT buffers configuration */
	client->rx_buf = rx_buffer;
	client->rx_buf_size = sizeof(rx_buffer);
	client->tx_buf = tx_buffer;
	client->tx_buf_size = sizeof(tx_buffer);

	/* MQTT transport configuration */
#if defined(CONFIG_MQTT_LIB_TLS)
	client->transport.type = MQTT_TRANSPORT_SECURE;

	static sec_tag_t sec_tag_list[] = {MY_SEC_TAG};
	struct mqtt_sec_config *tls_config = &client->transport.tls.config;
	
	tls_config->peer_verify = 2;
	tls_config->cipher_list = NULL;
	tls_config->sec_tag_list = sec_tag_list;
	tls_config->sec_tag_count = ARRAY_SIZE(sec_tag_list);
	tls_config->hostname = CONFIG_MQTT_BROKER_HOSTNAME;

#else
	client->transport.type = MQTT_TRANSPORT_NON_SECURE;
#endif
}

If you want to provision from the application, you can use the provision function from nrf_cloud_transport.c. Note that it expects CONFIG_NRF_CLOUD_PROVISION_CERTIFICATES=y to be set in prj.conf, and the certificates to have the same name as in the certificates.h file found in asset_tracker.

Best regards,

Didrik

[craig.goldman]

Thank you.  This is a very good answer.

I'm going to take a look at the cloud library.

It now appears to me that I should try something with mqtt_simple (modified as described above), then look to build a new application using the nrf_cloud library.

Just to make sure I understand you, for the provision function, do you mean "nct_provision"?

-Craig

[Didrik Rokhaug]

Yes, I meant nct_provison.

The nrf_cloud library is built specifically for nRF Cloud, and so while the transport layer can be used without too much modification, you might have more problems with the upper layers of the library, as they implement more nRF Cloud specific functionality. However, it can still be used as an inspiration on how to build your own cloud-interfacing library.

[craig.goldman]

I'm a bit confused by your answer.  Are you saying that the upper layers of the nrf_cloud library are not built to work with AWS?

[craig.goldman]

The "prj.conf" file under "mqtt_simple" does not contain CONFIG_NRF_CLOUD_PROVISION_CERTIFICATES; is it as easy as simply adding a new line or am I looking in the wrong "prj.conf" file?

Should I also add "CONFIG_MQTT_LIB_TLS=y" to this file?

[Didrik Rokhaug]

nRF Cloud is built on AWS, but we have configured AWS for our use. I am not familiar enough with AWS to say how much impact this has, but I can not guarantee that all the upper layers of the nrf_cloud library work with your (or other) AWS setups.

To give an example:

A DK can be in several different states: It can be associated with a user account, it can be waiting for a user to input a sequence of button presses, etc.

When a DK connects to nRF Cloud, it receives a message informing it of what state it should be in. It will then decode the message, and perform the appropriate actions.

As your cloud implementation will have other requirements and uses, the received state might not make sense to the nrf_cloud library (leading to an error), or the corresponding action might not be what you want.