Search code examples
ubuntumqttmosquittobroker

How to mention will message setting in bridg.conf file of mosquitto broker


I have installed mosquitto broker on ubuntu which is configured to send all the messages on an IP.

Below is the bridge.conf file contents:

connection local-ubuntu
log_type all
address 192.168.0.5:1883
remote_username admin
remote_password admin
remote_clientid dev
try_private false
cleansession false
start_type automatic
bridge_insecure false
bridge_protocol_version mqttv311
bridge_tls_version tlsv1.2
notifications false
keepalive_interval 36000
autosave_interval 30

topic # out 2 test/topic/ test/topic/
topic # in 2 test/topic/ test/topic/

I am sending all the data to broker and it is successfully publishing all the data to the mentioned IP address machine.

Now sometime this machine goes down, due to which the messages sent from the MQTT broker are not received at the machine and are lost.

I want to handle this scenario in the bridge of broker. I have read if we specify will messages then it will retain all the messages which are not delivered and will deliver them once the machine is on. But I am not able to find appropriate configuration for this.

Is there any way who has worked on this type of scenario. Please help. Thanks


Solution

  • I think you are conflating a number of different things here.

    Firstly, the Last Will and Testament message is set by a client when it connects to a broker, the broker then hangs on to this message and only publishes it if the client connection breaks (not if the client cleanly disconnects). It has no effect on if messages are queued for this client. There is no way to configure a LWT for a broker's bridge connection.

    Secondly there is no need for 2 topic lines to configure which topics get bridged you can replace both those lines with this one:

    topic # both 2 test/topic/ test/topic/
    

    Now because you have the QOS for the topic bridging set to 2 it should already be queuing messages if the remote broker is down and it will forward these once the bridge comes back up.

    If you want to check on the current status of the bridge you can subscribe to the $SYS/broker/connection/<remote_clientid>/state topic having set the notifications true option

    Also, your keepalive value (10 hours) for the bridge is too high to do anything useful. On a LAN I would be using something between 10-30 seconds.