Not reconnecting Mqtt

[meli27]

I'm trying this example https://github.com/shamblett/mqtt_client/blob/master/example/mqtt_server_client_autoreconnect.dart, however when Mqtt broker disconnects the app doesn't notice that mqtt is back and doesn't re connect.

What do I need to set up in this function?

void onAutoReconnect() {
  print(
      'EXAMPLE::onAutoReconnect client callback - Client auto reconnection sequence will start');
}

Should this work in another thread?

I will appreciate your help.

[shamblett]

I'm going to need a log, please turn logging on and post the output.

[meli27]

@shamblett Sure, right now it's working with an mqtt simulator.

// Simulator sends data
flutter: LatLng(latitude:54.097975, longitude:11.109153)

// Mqtt simulator gets interrupted and tries to reconnect
flutter: MqttConnectionState.connected // prints mqtt connection state
flutter: EXAMPLE::onAutoReconnect client callback - Client auto reconnection sequence will start // calls _onAutoReconnect func

[shamblett]

So are you saying its OK now?

[meli27]

No, it's not working, it stops getting the new data when the broker gets reconnected. I tried disconnecting and reconnecting again but it doesn't work neither.

 try {
      await client.connect();
    } on Exception {
      client.disconnect();
      rethrow;
    }

    if (client.connectionStatus!.state != MqttConnectionState.connected) {
      client.disconnect();
      _onAutoReconnect();
    }
  }

  void _onAutoReconnect() { //Should this function have more logic?
    print(client.connectionStatus!.state);
    print(
        'EXAMPLE::onAutoReconnect client callback - Client auto reconnection sequence will start');
  }

[shamblett]

This more to do with how you are configuring the broker than the client, what connection message are you sending? What QOS levels are you using for your subscriptions?

[meli27]

It's QoS 0 (fire an forget). We're not setting a qos level with the subscription. So it should default to 0. we have a few topics where retain is set to true on the publishing side.

[shamblett]

From the MQTT 3.1 spec -

3.1.2.4 Clean Session
Position: bit 1 of the Connect Flags byte.

This bit specifies the handling of the Session state. 

The Client and Server can store Session state to enable reliable messaging to continue across a sequence of Network Connections. This bit is used to control the lifetime of the Session state. 

If CleanSession is set to 0, the Server MUST resume communications with the Client based on state from the current Session (as identified by the Client identifier). If there is no Session associated with the Client identifier the Server MUST create a new Session. The Client and Server MUST store the Session after the Client and Server are disconnected [MQTT-3.1.2-4]. After the disconnection of a Session that had CleanSession set to 0, the Server MUST store further QoS 1 and QoS 2 messages that match any subscriptions that the client had at the time of disconnection as part of the Session state [MQTT-3.1.2-5]. It MAY also store QoS 0 messages that meet the same criteria.

If CleanSession is set to 1, the Client and Server MUST discard any previous Session and start a new one. This Session lasts as long as the Network Connection. State data associated with this Session MUST NOT be reused in any subsequent Session [MQTT-3.1.2-6].

So you need to not set the clean session bit, i.e don't use the startClean() method on your connect message and use QoS 1 or 2 for your subscriptions, looks like your broker doesn't support QoS 0 for this.

[meli27]

The broker we're using is eclipse mosquito. The python services reconnect to the broker as expected on connection loss.

[shamblett]

You may be sending a different connection message with your Python client, as I've said above, could you post your connection message.

[meli27]

I already deleted startClean(). And we are sending:

final MqttConnectMessage connMess =
        MqttConnectMessage().withClientIdentifier(uniqueClientId)

Right now is showing the reconnection message and the onConnect, but then the client does not PUBLISH the data again:

1646110290: Sending SUBACK to d639b595-613c-4356-8210-11c2dbd3972f
1646110336: Received PINGREQ from d639b595-613c-4356-8210-11c2dbd3972f
1646110336: Sending PINGRESP to d639b595-613c-4356-8210-11c2dbd3972f
1

[shamblett]

I'm getting confused here as to what the problem is you are reporting, firstly you said -

however when Mqtt broker disconnects the app doesn't notice that mqtt is back and doesn't re connect.

Then you said -

No, it's not working, it stops getting the new data when the broker gets reconnected. 

Which implies you are getting re connected.

From the log above you are re connecting and auto resubscription is working although its hard to tell without a full log. Now you are saying -

 the client does not PUBLISH the data again:

the client doesn't store messages you publish and re send them after an auto reconnect, it only auto re subscribes as per the API docs. If you are reading somewhere that the client will somehow store published messages and re send them on reconnect then point this out to me and I'll correct it. The client does not do this, if you want this functionality then you need to add this in your code.

[meli27]

Sorry for the confusion. This is the log: LogMqtt.pdf

I meant I can not see the publish messages the for the subscribed subcriptions.

[shamblett]

OK, from the log I can see the auto reconnect and auto re subscribe are successful and you are not starting with clean start. At this point the broker should start sending you saved published messages for your client however you are using a QoS level of 0(At Most Once), this has to be 1(At Least Once) or 2(Exactly Once) for the broker to do this as the extract from the spec says above.

[rimedar]

Hi, how i can set the CleanSession to 0 or 1? I can´t find this option, only .startClean(), and the Qos level.

From the MQTT 3.1 spec -

3.1.2.4 Clean Session
Position: bit 1 of the Connect Flags byte.

This bit specifies the handling of the Session state. 

The Client and Server can store Session state to enable reliable messaging to continue across a sequence of Network Connections. This bit is used to control the lifetime of the Session state. 

If CleanSession is set to 0, the Server MUST resume communications with the Client based on state from the current Session (as identified by the Client identifier). If there is no Session associated with the Client identifier the Server MUST create a new Session. The Client and Server MUST store the Session after the Client and Server are disconnected [MQTT-3.1.2-4]. After the disconnection of a Session that had CleanSession set to 0, the Server MUST store further QoS 1 and QoS 2 messages that match any subscriptions that the client had at the time of disconnection as part of the Session state [MQTT-3.1.2-5]. It MAY also store QoS 0 messages that meet the same criteria.

If CleanSession is set to 1, the Client and Server MUST discard any previous Session and start a new one. This Session lasts as long as the Network Connection. State data associated with this Session MUST NOT be reused in any subsequent Session [MQTT-3.1.2-6].

So you need to not set the clean session bit, i.e don't use the startClean() method on your connect message and use QoS 1 or 2 for your subscriptions, looks like your broker doesn't support QoS 0 for this.

[shamblett]

CleanSession defaults to 0, you set it by specifying .startClean()