However, when I run my App, I can see the subscription request sent successfully, but I never ever hear any messages in my callback. I’ve tested both in an emulator, and on my personal device.
To see if the issue is on the broker side or on the client side, I would install HiveMQ broker locally, in order to have full control over the traffic and to be able to see all communication logs on the broker side.
To install a HiveMQ broker locally, you can either download an open source HiveMQ - Community Edition or download a HiveMQ Enterprise Edition (which you can run for 5h without a license, in Trial mode). It does not matter for the test, which edition you install.
To see all the MQTT messages in the HiveMQ broker log (e.g. CONNECT, CONNACK, SUBSCRIBE, SUBACK etc.) you will need to install the open source HiveMQ MQTT Message Log Extension.
Testing your MQTT client against the HiveMQ broker with MQTT Message Log Extension enabled will let you see which MQTT packets reach the broker and which are sent by the broker to the client. This way you can see if the issue is in the client’s code or if it is a communication issue with the broker.
Thank you for your advice, Daria_H. Before your reply, I made a key discovery: my unit test is skipping one step that my app is performing, and it is that extra step that is failing.
My unit test flow is:
Connect to Broker
Publish a Set message
My app flow is:
Connect to Broker
Publish a Status Get message and wait for response
Publish a Set message
App step #2 is what was never getting a response, so it never got to #3.
So it turns out my problem was of my own making.
Now my task is find out why another app is able to sent a Get Status message and get a response, but mine isn’t.
I’m investigating ways of sniffing the traffic from the other app, but it’s tricky since MQTT is not HTTP, and the client-broker connection is TLS.
What kind of “response” is your MQTT client (app) waiting for?
If that is a message from some other client, then your client must subscribe to the corresponding topic first. You can find more information on the Request-Response pattern in MQTT 5 in MQTT Request-Response Pattern – MQTT 5 Essentials Part 9.
If your app is sending a PUBLISH message and waiting for a PUBACK message, you need to use QoS 1 for the PUBLISH message.
If your app is using QoS 2, then it will receive a PUBREC message instead of PUBACK.