eclipse
Suback is not sent to log topic ($sys/#)
I am using mosquitto 1.5.5 and trying to send logs to sys topics. It receives log but subacks are not coming to sys topic. I have requirement of listen to a particular suback and do some event based on that. For eg: lets say I subscribe to topic topic/test/su on remote broker and once I receive suback for this topic subscription send some event to remote broker. So I need here to monitor this suback. NOTE: I am using broker to broker communication where my local broker is mosquitto and remote broker is some different mqtt broker.
I tried to montitor sys logs on topic but it seems its not sending the subacks to the topic
How to achieve this?
No protocol information is sent over the topic based log.
If I understand correctly, what you should use is log_type subscribe, then monitor the $SYS/broker/log/M/subscribe topic.
$SYS/broker/log/M/subscribe this recvs notification about subscription of local MQTT client to local broker in my case mosquitto, but I want to recv notification about the subscription of mosquitto to remote broker. I am using bridge so I want to ensure that mosquitto has made subscrption to remote broker and this subscription notification does not recvd on "$SYS/broker/log/M/subscribe " topic
is the notifications topic not sufficient for this purpose?
Notification topic gives notification about the bridge is UP or NOT, with 0/1 having 1 as the bridge has come online. It does not guarantee subscription of topics from local broker to remote broker. I see instances where Suback are logged even after bridgup up, ideally I would expect that notification about the bridge being should be sent only after it receivs CONNACk and It local broker made all subscription to remote broker but this is not case currently. Notification "1" is sent even before the suback , this is where the problem comes, i need to ensure that local broker made subscription to remote broker where local broker acting as a bridge (Mosquitto). Unfortunaly notification topic only ensures CONNACk and not subscription guarantee.
If you're using durable bridges (which I would presume you would be, if you care about this level of robustness) you would seem to only have a weakness the very first time the bridge is ever created. Trying to trigger something after that first suback seems awfully convoluted for just that first initial step.
If you're not using durable bridges. (non clean sesson) then.... why not?
yes i using durable bridges and yes the problem is for 1st time,. I need this issue fixed for 1st connectivity becoz every day this broker will be used in 1000s of new devices and so it is very 1st connectivity for them and due to this 50% of devices fails.
@deeshah4 if you want to make sure the events from the client are sent to the external broker you should sent the PUBLISH with QoS 1 or 2 and configure the bridge with QoS 1 or 2 and cleansession false.
If you do so, the local broker will queue the messages until the connection to the remote broker is established.
