This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3220SF: MQTT reconnection (MS Azure)

Part Number: CC3220SF

Dear TI!

I am following this advice from Microsoft ( https://learn.microsoft.com/en-us/azure/iot-dps/concepts-deploy-at-scale ) to skip provisioning to IoT Hub when connection string is known.

I am not sure how to correctly recognize that connection failed.

On MS Azure portal I have disabled the connection:

Now trying to understand situation - I have added some log output:

01> provisioning() called
01> MQTT CLIENT CB: CONNACK
01> 1 MQTTClient_connect() returned: 0
01> MQTT CLIENT CB: receive event
01> MQTT CLIENT CB: receive event
01> MQTT CLIENT CB: receive event
01> MQTT CLIENT CB: DISCONNECTION EVENT
01> iotHubConnection() called
01> MQTT CLIENT CB: CONNACK
01> 2 MQTTClient_connect() returned: -3
01> delay=3
01> MQTT CLIENT CB: DISCONNECTION EVENT
01> 2 MQTTClient_connect() returned: 0
01> 2 MQTTClient_subscribe() returned: -7 // this is called because previous call of MQTTClient_connect() returned 0 and we see no blocker here

"MQTT CLIENT CB" is taken from SDK examples and corresponds to metaData->messageType called via callback provided to MQTTClient_create(..) function.

"2 MQTTClient_connect()" is call of MQTTClient_connect(..) from iotHubConnection(..) which follows provisioning(..) procedure.

It is really weird that second try (second call) of MQTTClient_connect(..) returned 0 after previous call returned -3.

My questions:

* how to try again connecting to IoT Hub properly? Is new call of MQTTClient_connect(..) the right way?

* what means error code -3 and how to properly react?

Thank you for help!

Jiří

  • what SDK are you using?

    The only error -3 that i could find (this is not a typical error) is MQTT_PACKET_ERR_NET_OPS which doesn't makes sense. It only can happen if call the MQTTClient_connect without calling MQTTClient_create before.

    The mqtt code is available in under <SDK>/source/ti/net/mqtt

    I think the main issue is the "MQTT CLIENT CB: DISCONNECTION EVENT" - it seems that the server disconnects and you need to understand the reason for that.

  • Hi Kobi,

    our SDK is v5.10.00.02 (ServicePack sp_3.13.0.3_2.0.0.0_2.2.0.6).

    I will check with my colleagues this disconnection issue. 
    I will definitely reply here if I will have update before this thread will be closed.

    Thanks a lot!

    Jiří

  • ok, waiting for more info on this.

  • Kobi,

    my colleague told me that the first "DISCONNECTION EVENT" should be ok, as we are disconnecting from DPS server.

    Second disconnection could be because I have intentionally disabled this device on Azure's IoT hub - this is part of my test. When I keep this enabled I have no more this second disconnection.

    When after first connection issue (-3 returned by MQTTClient_connect(..)) I am trying (after delay) to connect again I get 0 returned by MQTTClient_connect(..). But device doesn't get connected (it even cannot when I have disabled that on Azure).
    But I am not able to try again because I have got 0 (no error) - my program thinks that all is good.

    My workaround is that I destroy (delete) client with MQTTClient_delete(..) and try again from scratch (using MQTTClient_create(..) etc.).

    That is why I wanted to understand why MQTTClient_connect(..) returns 0 even in situation it cannot connect to IoT Hub server.

    Here is device on Azure IoT Hub disabled:

    01> provisioning() called
    01> provisioning MQTTClient_create() called
    01> MQTT CLIENT CB: CONNACK
    01> provisioning MQTTClient_connect() returned: 0
    01> MQTT CLIENT CB: receive event
    01> MQTT CLIENT CB: receive event
    01> MQTT CLIENT CB: receive event
    01> MQTT CLIENT CB: DISCONNECTION EVENT
    01> iotHubConnection() called
    01> IoT Hub connection MQTTClient_create() called
    01> MQTT CLIENT CB: CONNACK
    01> IoT Hub connection MQTTClient_connect() returned: -3
    01> delay=1
    01> MQTT CLIENT CB: DISCONNECTION EVENT
    01> IoT Hub connection MQTTClient_connect() returned: 0
    01> 2 MQTTClient_subscribe() returned: -7

    Here is device on Azure IoT Hub enabled:

    01> provisioning() called
    01> provisioning MQTTClient_create() called
    01> MQTT CLIENT CB: CONNACK
    01> provisioning MQTTClient_connect() returned: 0
    01> MQTT CLIENT CB: receive event
    01> MQTT CLIENT CB: receive event
    01> MQTT CLIENT CB: receive event
    01> MQTT CLIENT CB: DISCONNECTION EVENT
    01> iotHubConnection() called
    01> IoT Hub connection MQTTClient_create() called
    01> MQTT CLIENT CB: CONNACK
    01> IoT Hub connection MQTTClient_connect() returned: 0
    01> 2 MQTTClient_subscribe() returned: 0
    01> MQTT CLIENT CB: receive event
    01> MQTT CLIENT CB: receive event

    Jiří

  • what is the DPS server?

    I'm not familiar with issue where MQTTClient_connect return 0 though it fails.

    Does it work with the MQTTClient_delete/create? is there any issue when using this workaround?

  • DPS = device provisioning service. So server to which we provision to get URL address for device connection. Something from Microsoft - Azure. I am not much familiar with this.

    Issue with workaround is that it is workaround. My colleague taken over this task. I will ask him to add him more info if there will be any.

    Jiří

  • Hello Jiri,

    Kobi and our SW experts are still working on this issue, give us some more time to investigate.

    Please note that this week is a short week because of Thanksgiving, thank you for your patience.

    Best regards,

    Jonathan 

  • Hello Jonathan!

    I am thankful that it's being investigated! Take as much time as needed.

    Regards

    Jiří

  • Hello Jonathan. I and Jiri were looking for the more elegant workaround to avoid recreation of MQTT client after possible disconnection, however I also have not managed to find better solution than recreate MQTT client again after each disconnection (that is what we are doing in our application). I have tried the same approach as Jiri mentioned and would like to confirm result of his investigation. Precondition is that our devise is not allowed to connect to the broker (IOT hub connection is disabled like on the screen attached above). Here is a sequence of actions in our application:
    1) call to MQTT_create() returns 0 which is expected;
    2) create MQTT context thread. MQTTClient_run(0) is called from that thread;
    3) set parameters with MQTTClient_set(): MQTTClient_USER_NAME, MQTTClient_CLEAN_CONNECT = true
    4) call to MQTTClient_connect(). First time -3 (MQTT_PACKET_ERR_NET_OPS) is returned, all next calls to this function return -0.

    I also noticed that MQTTClient_run(0) function terminates immediately on step 4 (after MQTTClient_connect() returns -3). I also tried to perform step 2 before each call to MQTTClient_connect(), but every next call to MQTTClient_connect() terminates with error code 0, although I expected -3 either. 

    Then I downloaded SDK v 6.10.00.05 and looked at "mqtt_client" demo example. At this point I decided to keep our sours code as it is because in the example, MQTT client is also recreated after every disconnection and this is probably correct use of MQTT library:



    Best regards,
    Ihor

  • Ihor,

    Thank you for the update. We are continuing to investigate and we will update you with any new information early next week. 

    Best regards,

    Jonathan 

  • I think you are right. The Create and Connect (as well as the MQTT context thread) are tight together, thus the fix is the recommended behavior.

    I will still need to check why the "MQTTClient_connect" returns 0 when there is no active MQTTClient_run. I'll update as soon as i find anything. 

  • Thanks for assistance, Kobi !

  • I will try to check this by the end of the week, but i don't expect this will change the fix you have done.

    I'll update once i find something.

  • do you see any issue with the suggested fix?

    I was not able to reproduce the issue where "MQTTClient_connect" returns 0 (I'm using SDK6.10).

    Is it still an issue when binding the _create and _connect together?

  • Hi Kobi,

    I was just waiting for some info that was promised. If the problem is not reproduced on your side, we can close this topic. We are using SDK v5.10.00.02.
    I will ask Ihor if he has something to add.

    Regarding binding the _create and _connect together - I would say it is not real issue, it is just not obvious that this is needed. Not a regular practice.

    Regards
    Jiří

  • I also don't like this binding either, thus the MQTT_IF module tries to simplify the interface for the app developer.