MQTTSN Example: Client unable to reconnect to Broker after timeout

[Brian (Geek)]

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.  

[Sigurd Hellesvik]

Hi Brian

I will have to fix a bug with my install of the MQTT-SN router.

I think I will be able to fix this at the start of next week. Sorry for this delay.

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

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

[Brian (Geek)]

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. 

[Brian (Geek)]

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 ? 

[Sigurd Hellesvik]

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

[Brian (Geek)]

Hello Sigurd,

Sorry for late response.

I am doing current measurement using multimeter. I am getting 6uA but after couple of seconds I can see spike of around 600-700 uA even when I am not doing anything. Also I see in your graph from profiler kit there are many spike of around 600-700 uA . What is that from. When I try to publish 1K bytes of data I get current consumption spike of around 4-6mA while sending data. Can you tell me from where are this spikes of 600uA coming from ? If I set a poll period of 4s, than I should a spike after 4 seconds right ? 

Can you please explain ? 

[Sigurd Hellesvik]

Hi Brian,

Here is the expected power consumption of the nRF52840DK in sleep mode.

The spikes from my graphs are most likely Auto-controlled refresh modes for LDO and DC/DC regulators to maximize efficiency.

But an important point:
If you want to measure the power consumption for your device, you need to do so yourself. My graphs will be different from what you get, as it is hard for us to set up the exact same setup, especially as you use custom code in a project consisting of multiple parts.

Multimeters are not well suited to measure sleep currents, as they tend to have long sampling intervals and do not provide graphs. If you need to power-optimize your design, I strongly advise you to use an oscilloscope, Power Profiler Kit 2 or similar to do current measurements.

Regards,
Sigurd Hellesvik