I’m using the MQTT DAT, which reports publish requests from the MQTT Server via the callbacks. However, the arguments of onPublish() only include the origin DAT. It would be very helpful for debug purposes to include more information in the callbacks, specifically the topic(s) that are requested, and the IP address of the requesting host.
If this is possible, I’m sure that it would also be useful to include this kind of granular data in all callbacks, such as onSubscribe(), onUnsubscribe(), etc.
onPublish is triggered when a local mqttclientDAT.publish() call succeeds, not when a remote client does. It’s the same case with onSubscribe. onMessage is triggered when a remote client sends a message.
I’m not sure there’s a general solution to get the network information of the publishing client, though certain brokers may relay that information in the message.
All that being said, I think it is a reasonable suggestion to add topic names to more of the callbacks.
The comments within the callbacks are a bit confusing then. In the case of onPublish():
# Called when server receives publish request
If I understand correctly the server refers to the remote system that the client DAT is connected to? If so, I’d expect this callback to be triggered when the remote system receives the payload of the published topic.
However, I tested this by pulling my Ethernet cable and the callback did continue to be triggered, so the actual behavior of onPublish() appears to be as you’ve described. I haven’t tested this with other callbacks, but the comment description of onSubscribe() and onUnsubscribe() may need to be adjusted if they are similarly just reflections of the client’s actions, and not confirmed via the remote server.
Whatever descriptive metadata is available to pass into the callbacks would certainly be welcomed for troubleshooting purposes.
I agree the comment isn’t entirely accurate - I’ll fix that. More accurately, it is triggered when the mqttclient1.publish/subscribe/unsubscribe succeeds locally and is sent to the server.
That’s strange it would still get triggered with no internet connection (assuming your broker isn’t on the same machine). I wouldn’t expect the publish call to succeed if the connection doesn’t actually exist. I’m also not able to reproduce the issue on my end.