MQTTSN Example: Client unable to reconnect to Broker after timeout

Hello,

I am currently using mqttsn publisher exams with keep allive time of 30 seconds, so according to MQTT standard if period of inactivity will be 45 second and the client is unable to recieve ping response or broker doesn't recieve ping request from client in fixed time it will break the connection.

I would like to know how could I reconnect client to the broker once the broker timesout the client connection. Currently I am checking the state of client using isConnected api but it indeed take 3-4 minutes to restablish a connection. 

I would like to re-establish a connection as soon as the mqtt-sn client get's time out. I can't wait for 2-3 minutes to connect to broker. Also currently I have to wait for the next publish to check whether my client is connected to broker or not.

For Example: if I take a python MQTT client with keep alive time of 60 second and turn off and turn on the mosquito broker , the python client immediately connects within few seconds. I want some solution like that for mqtt-sn client. 

Please provide some tried and tested code or help for the same.  

Parents Reply Children
  • Hi

    When I build and run the MQTT-SN sleepy publisher, I can not see the lag you are mentioning.

    It could be a problem with the MQTT-SN gateway.
    I used the https://github.com/osaether/otbr-mqtt-sn/, maybe you could try this?

    To set up this, install and setup docker. Then go to the releases in the mentioned github and download the otbr-mqtt-sn-1.2. This is a docker image.
    To unzip and load this, use:

    gzip -d otbr-mqtt-sn-1.2.tar.gz
    docker load < otbr-mqtt-sn-1.2.tar

    Then you can run the "docker run" command from the README to start the border router.

    Are you able to try this?

    Regards,
    Sigurd Hellesvik

  • Hello Sigurd,

    I am currently using Nordic Border Router image as suggested by Jonathan *** from Openthread Google Group. 

    And also that image is the latest one, so I don't think that could be the issue or no one ever checked with that image ? 

    According to my understanding the lag is because I have kept Keep Alive time of 60 sec, so after 90 sec only my MQTT client will be able to know that it has got disconnected from the broker. So can you please check with Nordic image itself.

    I would like reiterate I am able to reconnect to gateway but after that 90 seconds. In my publish function, I have condition to check whether client is connected or disconnected, if connected it will send data, if not connected it will re-initiate a connection with gateway. But for this to happen it has to wait 1.5 times the keep alive time period as per MQTT standard.  

    But how a normal MQTT client in my PC is able to connect to mosquitto broker after restart of broker I don't get the same result with my thread mqtt-sn publish client. 

    Thanks. 

  • Hello Sigurd,

    Quick Update: I have updated the mqtt-sn gateway on Nordic border router image to the one used in the docker image link which you have provided. I tried updating mqtt-sn gateway to the master branch but the configuration have changed now. So I have stick with the mqtt-sn gateway commit used in Docker Image. So my MQTT-SN gateway is almost up-to-date.

    As you asked me about whether I am getting MQTTSN disconnect event. Answer is yes, in mqqtsn_event handler i am getting MQTTSN DISCONNECT event. Also in the mqtt-sn logs, when I shut down the broker I can see disconnect packet sent to client. So that aspect is working fine. But in Mqtt-sn disconnect event, than I have to try to connect to gateway manually. Can that be automated like somewhere in background similar to normal python MQTT client ? 

    Also I am facing a new issue now. With the updated mqtt-sn gateway on border router, whenever I shut-down the broker it gives me a assertion error one by one in mqttsn_client.c file state changed function. In that switch case of CLIENT CONNECTEd, disconnected and establishing connection give me assertion error whenever I shut down the broker. Why is it so ? 

  • Hi Brian

    Brian (Geek) said:
    As you asked me about whether I am getting MQTTSN disconnect event. Answer is yes, in mqqtsn_event handler i am getting MQTTSN DISCONNECT event. Also in the mqtt-sn logs, when I shut down the broker I can see disconnect packet sent to client. So that aspect is working fine. But in Mqtt-sn disconnect event, than I have to try to connect to gateway manually. Can that be automated like somewhere in background similar to normal python MQTT client ? 

    I do not know of any way to make this reconnect automatically. Since that MQTTSN implementation does not seem to do this automatically, you will have to fix this manually in the mqttsn_event_handler in your application.

    Brian (Geek) said:
    In that switch case of CLIENT CONNECTEd, disconnected and establishing connection give me assertion error whenever I shut down the broker. Why is it so ? 

    This crashes due to the handler not being able to handle a fsm_event. The fsm_event can have the following values:

    /**@brief MQTT-SN events that cause MQTT-SN client's state to change. */
    typedef enum client_state_fsm_event_t
    {
        SENT_SEARCHGW,                  /**< SEARCH GATEWAY message was sent. */
        SENT_CONNECT,                   /**< CONNECT message was sent. */
        SENT_PINGREQ,                   /**< PINGREQ message was sent. */
        SENT_SLEEP_REQUEST,             /**< DISCONNECT message with sleep duration was sent. */
        SENT_DISCONNECT_REQUEST,        /**< DISCONNECT message without sleep duration was sent. */
    
        RECEIVED_CONNACK,               /**< CONNACK message was received. */
        RECEIVED_SLEEP_PERMISSION,      /**< Response to a DISCONNECT message with sleep duration was received. */
        RECEIVED_DISCONNECT_PERMISSION, /**< Response to a DISCONNECT message without sleep duration was received. */
        RECEIVED_DISCONNECT,            /**< DISCONNECT message sent not as a response (disconnected by the gateway). */
        RECEIVED_PINGRESP,              /**< PINGRESP message was received. */
    
        TIMEOUT_SEARCHGW,               /**< Timeout occurred when waiting for GWINFO message. */
        TIMEOUT_CONNECT,                /**< CONNECT message retransmission limit has been reached. */
        TIMEOUT_PINGREQ                 /**< PINGREQ message retransmission limit has been reached. */
    } client_state_fsm_event_t;

    If you are able to find the value of the fsm_event int the MQTT_CLIENT_CONNECTED switch case, this could give an indication to why it will crash on broker disconnect.

    Regards,
    Sigurd Hellesvik

  • Hey Sigurd,

    Thanks for assistance. I managed to achieve a state machine for mqtt-sn examples.

    Currently my devices are in testing stage, once i feel everything is working properly I would close this ticket.

    Till that can you please tell me what's exactly is the use of polling period in sleepy example. Because when I try to measure the current consumption it give me spikes in uA every few seconds. I would like to keep my device in sleep state for 5 minutes. Than what should be my default and short poll period ?

Related