Asset Tracker v2 - How to monitor the On/Off state of the sliding switches: sw1 and sw2 reported every minute from the nRF9160DK device to a topic of the AWS IoT Core?

[Jacek Majda]

I have built and run the application: Asset Tracker v2 using Segger IDE with nRF Connect SDK 1.8.0 , and my nRF9160DK device communicates with the  AWS IoT Core topics.

I can see the battery voltage data (with its time stamp) reported every minute from my nRF9160DK device to the shadow topics of the AWS IoT Core and I can also see the button-pressed data reported (when a button is pressed) from my nRF9160DK device to the AWS IoT Core topic: <IMEI>/messages.

As a next step, I would like to see the On/Off state of the sliding switches: sw1 and sw2 reported every minute from my nRF9160DK device to a topic on the AWS IoT Core.

How can this be done? 

[Jacek Majda]

Hi,

I did adjust the relevant setting in the file: overlay-aws.conf , from 2048 to 2304, as follows:

CONFIG_AWS_IOT_MQTT_PAYLOAD_BUFFER_LEN=2304  ,  and the problem has been resolved.

I noticed that next to the above setting in the overlay-aws.conf file , there is another setting related to RX_TX BUFFER's length, namely:

AWS_IOT_MQTT_RX_TX_BUFFER_LEN=2048 , with a setting of 2048, which is less than 2304 to which the PAYLOAD_BUFFER_LEN has just been set. 

1. Shall I increase this setting to 2034 as well?

2. I intend to add another 4 items to the payload that will be sent from my nRF9160DK device to AWS IoT Core. These 4 new items will be added to the data reported by the modem_module as a part of info related to the modem battery voltage "bat", that will show in the Device Shadow State as follows:

{

"state":{

     "reported":{

            "bat":    {

               "v": 5070,

               "ts": 1645763876628384949,

              "sw1": 99,

              "sw2": 77,

              "New_Item1": 10,

              "New_Item2": 20,

              "New_Item3": 30,

              "New_Item4": 40,

Can I do so without the risk of exceeding the maximum value allowed for any buffers that are used in processing this data?

3. Lastly, on the LTE Link Monitor, I see the following message when I run my "Asset_Tracker_v2" application:

"Try selecting a sample/publication interval greater than the GPS search timeout".

Should I do anything about that ?

Regards,

JM

[Håkon Alseth]

Hi,

 

Jacek Majda said:

CONFIG_AWS_IOT_MQTT_PAYLOAD_BUFFER_LEN=2304  ,  and the problem has been resolved.

I am glad to hear this!

 

Jacek Majda said:

1. Shall I increase this setting to 2034 as well?

Not strictly required, as it is the publish payload that is the most crucial, but please be aware that if you send/receive (apart from the mqtt publish payload) larger packets, you should consider to adjust this config.

Jacek Majda said:

2. I intend to add another 4 items to the payload that will be sent from my nRF9160DK device to AWS IoT Core. These 4 new items will be added to the data reported by the modem_module as a part of info related to the modem battery voltage "bat", that will show in the Device Shadow State as follows:

{

"state":{

     "reported":{

            "bat":    {

               "v": 5070,

               "ts": 1645763876628384949,

              "sw1": 99,

              "sw2": 77,

              "New_Item1": 10,

              "New_Item2": 20,

              "New_Item3": 30,

              "New_Item4": 40,

Can I do so without the risk of exceeding the maximum value allowed for any buffers that are used in processing this data?

It is hard to say, have you tried this and checked if it works in your specific scenario?

 

Jacek Majda said:

3. Lastly, on the LTE Link Monitor, I see the following message when I run my "Asset_Tracker_v2" application:

"Try selecting a sample/publication interval greater than the GPS search timeout".

Should I do anything about that ?

As the GPS and LTE cannot be active at the exact same time, it is important that you configure the LTE publication interval to be greater than the GPS search timeout, ie. if you send every 180 seconds, you cannot set the GPS to 180 seconds search timeout, as they will collide.

 

Kind regards,

Håkon