why connect() returns but connection is not established?

[charleshuangcai]

paho version is 1.5.0, python 3.8 code example: client.connect(host=self.__profile.get_host(), port=self.__profile.get_port(), keepalive=self.__profile.get_keep_alive_interval()) client.loop_start() client.is_connected()

but client.is_connect() reslut is false. why sync method connect returns but connection is not established?

[smuu]

Have the same problem and can't find a solution.

client.connect(..) returns 0 (MQTT_ERR_SUCCESS) so no error occur while connecting.

[smuu]

I have another python script to publish data to mqtt.

client.connect(host, port)
client.is_connected()
client.publish(topic, message)
client.disconnect()

client.is_connected() returns False but data get published to the mqtt broker.

[cjdcordeiro]

same here

[billimek]

observing the same behavior

[smuu]

For me was the problem, that I used websockets at the mqtt broker and forgot to specify that while creating the client.

[denravonska]

Same issue here. connect is asynchronous and requires an event loop. That defeats the purpose of a synchronous variant.

[dxmann]

I'm working with AWSIoT. After understanding that is not useful set the CA cert path, I have encountered your same problem. Looking on called callbacks I have on_disconnected called with error code 1: as wrote here, 1 is "Connection refused – incorrect protocol version". so I set the protocol to MQTTv311, the only one used by AWSIot, but with the same result.

[eohlde]

Same issue here. is_connected() always returns False, but MQTT data is being published. I have also overridden the on_connect and on_disconnect callbacks and they are never triggered.

[wanZzz6]

Have the same problem

[Haifischbecken]

Ran into a similar problem, I didn't know that calling client.tls_set_context() or client.tls_set() was necessary as it wasn't part of any introduction I found online and I'm quit new to this whole networking thing.

[chengchenglee]

I'm working with AWSIoT. After understanding that is not useful set the CA cert path, I have encountered your same problem. Looking on called callbacks I have on_disconnected called with error code 1: as wrote here, 1 is "Connection refused – incorrect protocol version". so I set the protocol to MQTTv311, the only one used by AWSIot, but with the same result.

Same here. I am using aws iot mqtt for data transmit.

I am using mqtt_bridge.

every time , the on_disconnect will give the response code 1 back .

I do not know how to solve it. I also raised a question here. https://github.com/groove-x/mqtt_bridge/issues/61

[MattBrittan]

Connecting to a broker is a two stage process:

• Establish a connection (TCP/TLS/Websocket etc)
• Perform the MQTT connection handshake (CONNECT/CONNACK)

Taking a look at the source it appears that connect returns when the first step (establish network connection) is complete and the CONNECT packet has been sent (connect returns reconnect() returns _send_connect()). At this point in time the second part of the process (receiving/processing the CONNACK) has not happened; that happens latter within the network loop code. Code called within the loop:

• Updates the connection status (returned by is_connected())
• Calls the on_connect callback

This has a few implications:

• Some functionality relies upon the network loop. If the network loop is not run is_connected() will return false and callbacks such as on_connect will not be called.
• is_connected() will return false if called soon after connect (or for ever if the loop is not called/running) because the connection state is only updated when the CONNACK is received/processed. Using the callback `on_connected' is the best way to handle this (do not assume the connection is up until this is called).
• It is possible that the broker will reject the connection due to something within the CONNECT packet (meaning connect returns without error but is_connected() continues to evaluate to false). When this happens on_disconnect should get called if the loop is run (this is what @chengchenglee is seeing).
• publish may succeed without a network loop (but messages may also just be dropped and, as PUBACK/PUBCOMP will not be handled, QOS1/2 transactions will not complete).

The above is my assessment based upon a review of the code; I'd appreciate it if someone could confirm my findings and I'll propose some updates to the docs.

[FeroxTL]

Made cool workaround:

def connect():
    client = mqtt.Client()
    client.connect(host="host", port="port")

    started = time.time()
    while time.time() - started < 5.0:
        client.loop()
        if client.is_connected():
            return client

    raise OSError('Not connected')

[MattBrittan]

Closing this because my PR (#615) to update the documentation has now been accepted. Hopefully that will clarify things a bit!