NRF9160 / Asset Tracker V2 / AWS - Power consumption problem with MQTT_KEEPALIVE

[Dev123]

I have an application modified from the Asset Tracker V2. It is on the 1.8 SDK.

I am able to get the power consumption low, but every 20 minutes the application starts the modem and pings AWS. This is because of:

# Maximum specified MQTT keepalive timeout for AWS IoT is 1200 seconds.

#CONFIG_MQTT_KEEPALIVE=1200

The Asset Tracker V2 code does not disconnect from AWS until the modem is shutdown, but in PSM mode- it will not shutdown (and therefore send a shutdown event).

What is the easiest way to stop these connections?

Thanks

[Øyvind]

Hello, 

Could you elaborate more on how you try to disconnect from AWS? Can you use i.e. aws_iot_disconnect?

Kind regards,
Øyvind

[Dev123]

I am using the Asset Tracker V2. It manages connection. My assumption is that it was built for low power. I do not understand how it can be low power if it turns the radio on every twenty minutes. I am assuming I am missing some configuration.

[Dev123]

My power consumption is 18 ua when in psm. I have not measured the energy consumption of waking up the radio every twenty minutes, but I know it will be non-trivial on a device meant to last years. Radio is not just turned on, it needs to transmit and it does this 72 times a day.

Peter

[Lorenzo Amicucci]

Hi,
have you considered using Lwm2m or other coap based solutions? 

[Dev123]

In the end, I set it very high and use it as a safety to make sure device talks. So if it is scheduled to talk every 12 hours, I set it to 25 hours to ensure it does not miss. May move it farther out than that.

So now I have a solution for me, but I think a robust sample app for a low power solution should be handling this better (probably disconnecting).

[Øyvind]

Please note that the Asset Tracker v2 is a real-time configurable ultra-low power capable application. This does not mean that it is by default configured to lowest possible configuration. The application is a demonstration of what our nRF9160 is capable of, but will not reflect all use cases.

[Achim Kraus]

I guess you need to decide, which way to go:

- TCP based:

   - always connected

   - always connecting

- UDP based:

   - connection less

That means, neglecting encryption ((D)TLS), for TCP you either need frequently (here 20 min) messages, or you need a TCP connect ahead of sending application data. With MQTT that results with the TCP injected messages easily in about 8 IP-packets instead of 2 for UDP.

Also enables UDP to use RAI, which also reduces the energy consumption.

Considering encryption, "connecting" requires an additional TLS handshake, with that it's about 20 IP messages instead of 2.

Using DTLS 1.2 (6347) usually requires also handshakes, because in the most cases the client's IP-address is changing. You may be able to configure the client's IP-address in a static manner, but that may be harder than expected. Without, an handshake is required and will also end up in about 10 IP messages instead of 2.

For such cases, where the IP-addess is changing, DTLS 1.2 Connection ID (RFC 9146) was introduced. That enables you again to exchange data with mainly 2 IP-messages.

Currently there are 3 implementation I know, Eclipse/Californium (java, client and server), Eclipse/tinydtls (C, only client, currently in develop), and recently mbedtls (C).

If you're interested, you may check my demonstration client, https://github.com/boaks/zephyr-coaps-client. It uses tinydtls and Californium as cloud-server. It only demonstrates the use of CoAP/DTLS CID, it's no tracker app. Using a Thingy:91 exchanging a message every hour it reaches 1/2 a year from the internal battery.