Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Websocket connection doesn’t get messages on subscription after terminated reconnect #645
I’m using a STMicroelectronics Wireless Module (SPWF04S) as MQTT Websocket Client. This device doesn’t support any other protocol. After the connection is established the Wireless Module does subscribe on the topic
Here are the logs (with log_type all).
The Broker does not send the Received PUBLISH from 864e7ddd-89f8-485d-a876-a24e98fe3cef to SPWF04S.
That’s how the connection looks like (always the same):
a) you can definitely use more than just websockets mqtt with that module. even st talks about native mqtt, http rest, anything you like. anyway...
b) you seem to be subscribing at qos2, but only publishing at qos 0? If that's the case, messages will not be queued for your subscriber when it goes offline. It's unclear from your logs when you are disconnecting things. I presume you're seeing them disconnect later, after the keepalive, or if you reconnect soon enough, you're seeing that "client xxxx already connected..." line.
c) your client is subscribing with what seems to be a fixed clientid, good, but without cleansession set to false, you're also not going to get anything queued for you, even if you fix your qos problem.
Thank you for your fast answer.
I have double checked, the STMicroelectronics Wireless Module SPWF04S does only support MQTT over Websockets:
As next step I have fixed all publishes and subscriptions to QoS 2 but it was still doesn’t working. After I have changed the Fixed ID to a Random ID which I generate each time new, everything seems to work.
But I still don’t get it: after the client starts and establishes connection (with clean session and a fixed ID), the client should get new messages (I don’t think and want to talk about persistence) from the subscription. But why does the client don’t get this messages?
No. I do not receive any messages that were sent after the device was turned on and connected to the server.
For a better understanding, I have compiled the following protocol here (please mind the second connection, the first and third is working):
I can reproduce this issue. It happen when a new client replace an existing one (i.e. using the same clientid) and cleansession is False.
To reproduce this issue, I'm using:
Run the following client:
You will see that the message is only received by first and third client.
On server logs:
If you change TRANSPORT and PORT to "tcp" and 1885, the client will works as expected.
I think the issue come because mqtt3_handle_connect will add a duplicate key in contexts_by_id which is not permitted by uthash.