Attachments (0)
Nordic Case Info
  • Case ID: 287290
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

MQTT messages received multiple times on QoS 1 subscription

JWizard

I am using the SLM app from the 1.9.1 SDK.

I connect to my MQTT broker using TLS offloaded on the modem.

I subscribe to a topic using QoS = 1

Then if a message is published to the same topic using QoS = 1 then the nrf9160 reports the message received over and over again every few seconds.

If I instead subscribe to the topic using QoS = 0 then I will only get the messages (published at QoS = 1) one time.

Is this the intended behavior? I feel unsure that I am actually operating under QoS = 1 conditions when the subscription is set to QoS = 0.

Parents
  • 0

    Hello, 

    Sorry for the late response. I will have a look at your issue today. Please note that due to Easter holidays in our R&D department, there might be some more delay to get an answer.  We're sorry for the inconvenience. 

    Kind regards,
    Øyvind

Reply
  • 0

    Hello, 

    Sorry for the late response. I will have a look at your issue today. Please note that due to Easter holidays in our R&D department, there might be some more delay to get an answer.  We're sorry for the inconvenience. 

    Kind regards,
    Øyvind

Children
  • 0 in reply to Øyvind

    Hello, 

    I tested with 
    #XMQTTCON: 1,"287290_client","test.mosquitto.org",1883
    AT#XMQTTSUB="nordic/test",1

    Then publishing to nordic/test from my mosquitto client with QoS 1. I received only one notification in the SLM. 

    Have not been able to test using TLS yet. Can you confirm if you see the same issue with e.g. similar setup as I did?

    Kind regards,
    Øyvind

  • 0 in reply to Øyvind

    I was finally able to test this scenario connecting to AWS IoT, and yes, you are correct. 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    2022-04-11T12:25:08.800Z DEBUG modem >> AT#XMQTTSUB="nordic/test/",1
    2022-04-11T12:25:08.816Z DEBUG modem << OK
    2022-04-11T12:25:09.363Z DEBUG modem << #XMQTTEVT: 7,0
    2022-04-11T12:25:49.691Z DEBUG modem << #XMQTTMSG: 12,45
    2022-04-11T12:25:49.703Z DEBUG modem << nordic/test/
    2022-04-11T12:25:49.705Z DEBUG modem << {
    2022-04-11T12:25:49.706Z DEBUG modem << "message": "Hello from AWS IoT console"
    2022-04-11T12:25:49.708Z DEBUG modem << }
    2022-04-11T12:25:49.710Z DEBUG modem << #XMQTTEVT: 2,0
    2022-04-11T12:25:50.130Z DEBUG modem << %CESQ: 55,2,17,2
    2022-04-11T12:25:53.932Z DEBUG modem << %CESQ: 54,2,12,1
    2022-04-11T12:26:09.565Z DEBUG modem << #XMQTTEVT: 9,0
    2022-04-11T12:26:19.791Z DEBUG modem << #XMQTTMSG: 12,45
    2022-04-11T12:26:19.803Z DEBUG modem << nordic/test/
    2022-04-11T12:26:19.804Z DEBUG modem << {
    2022-04-11T12:26:19.806Z DEBUG modem << "message": "Hello from AWS IoT console"
    2022-04-11T12:26:19.806Z DEBUG modem << }
    2022-04-11T12:26:19.807Z DEBUG modem << #XMQTTEVT: 2,0
    2022-04-11T12:26:25.229Z DEBUG modem << %CESQ: 57,2,17,2
    2022-04-11T12:26:32.909Z DEBUG modem << %CESQ: 54,2,12,1
    2022-04-11T12:26:49.846Z DEBUG modem << #XMQTTMSG: 12,45
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Will investigate to verify behavior.

    Kind regards,
    Øyvind

  • 0 in reply to Øyvind

    Hi Oyvind,

    Thanks for looking into it. I just tested with the public, non-encrypted test.mosquitto.org and I also saw only one message received with QoS=1 in that scenario.

  • 0 in reply to JWizard

    Hello, 

    A small update on this case. Looking at Steve's Internet Guide on Understanding MQTT QoS Levels, the QoS 1 message will continue to be resent at regular intervals, until the sender receives an acknowledgement.

    The MQTT API in Zephyr has the following API

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    /**
    * @brief API used by client to send acknowledgment on receiving QoS1 publish
    * message. Should be called on reception of @ref MQTT_EVT_PUBLISH with
    * QoS level @ref MQTT_QOS_1_AT_LEAST_ONCE.
    *
    * @param[in] client Client instance for which the procedure is requested.
    * Shall not be NULL.
    * @param[in] param Identifies message being acknowledged.
    *
    * @return 0 or a negative error code (errno.h) indicating reason of failure.
    */
    int mqtt_publish_qos1_ack(struct mqtt_client *client,
    const struct mqtt_puback_param *param);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The Serial LTE Modem does not use this, however, the Simple MQTT sample does use the following in the mqtt_evt_handler (nrf\samples\nrf9160\mqtt_simple\src\main.c)

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    if (p->message.topic.qos == MQTT_QOS_1_AT_LEAST_ONCE) {
    const struct mqtt_puback_param ack = {
    .message_id = p->message_id
    };
    /* Send acknowledgment. */
    mqtt_publish_qos1_ack(&client, &ack);
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Øyvind

    Hello, have confirmed that this was a bug. A bug fix has been registered https://github.com/nrfconnect/sdk-nrf/pull/7363 

    Kind regards,
    Øyvind

Terms of service