MQTT Bridge message caching

Networking Solutions
1

I’m running an MQTT broker and an MQTT bridge on a Teltonika OTD500 as per MQTT Client on IoT hardware -> OTD500 -> AWS IoT core MQTT Broker . Broker persistence is enabled.

I tested sending MQTT messages to the broker while the router was offline from the internet. I expected these messages to be cached and forwarded to AWS IoT once the connection was restored. However, when I restored connectivity (by re-inserting the SIM card and manually restarting the mobile connection), the messages were not delivered to AWS. I have confirmed that message delivery works when the internet connection is active.

Questions:

  1. How can I configure the MQTT bridge to cache messages that cannot be immediately delivered to AWS IoT? My guess is that broker persistence only ensures messages are stored locally on the broker, so the bridge itself would need to handle offline caching.

  2. When testing the SIM removal, the mobile connection did not come back within 1–2 minutes. Would the OTD500 eventually reconnect automatically if I hadn’t manually restarted it?

3

Hello,

A 100% solution would be to use Data to server to achieve this, however, this will mean that our device will no longer act as a MQTT Bridge, but rather will read MQTT data and then just forward it to the AWS server. Would this work for you? Could you test it out?

It could take a while, yes, but it should most likely reconnect on its own.

Regards,
M.

5

The Data to server feature only offers Retry count = 1-10, and Timeout = 1-10. I’m looking for a solution which will support reliably delivering MQTT messages even in the face of a multi-hour internet outage.

Is there anything which I can do to get the MQTT Bridge to deliver messages which were received locally while the internet connection was offline?

7

Update: Solved

I found the root cause by reviewing the Mosquitto source code and running tests with debug logging.

Problem: My IoT device publishes at QoS 0 (and this can’t be changed). In src/database.c (lines 597-606), Mosquitto explicitly drops QoS 0 messages when the bridge is disconnected:

if(!net__is_connected(context)){
    /* Client is not connected only queue messages with QoS>0. */
    if(qos == 0 && !db.config->queue_qos0_messages){
        ...
        return 2;  // Message dropped
    }
}

The topic controllers/# out 1 setting only sets the maximum QoS for the subscription - it does not upgrade incoming QoS 0 messages to QoS 1.

Solution: I added these two broker configuration options using the Custom Config option:

upgrade_outgoing_qos true
queue_qos0_messages true
  • upgrade_outgoing_qos true - Upgrades outgoing messages to match the subscription’s QoS (see src/subs.c line 82)
  • queue_qos0_messages true - Allows QoS 0 messages to be queued for offline clients

With these settings, I confirmed that messages published while the bridge was offline are now queued and successfully delivered when the connection is restored.

It would be very helpful if a future Teltonika firmware release exposed UI for enabling these two underlying Mosquitto config options.

1 Like
8

In the end I’ve settled on using the Custom Config support, and uploading a config file with these settings:

# 50MB disk space
max_queued_bytes 52428800
# Allow queuing of QoS 0 messages, and send them to AWS at QoS 1 (based on Bridge config)
queue_qos0_messages true
upgrade_outgoing_qos true
# Persist to disk
persistence_location /etc/mosquitto/
autosave_interval 300
autosave_on_changes false
1 Like
9

Hi, mchr3k,

Thank you kindly for sharing the solution, I’ll pass this information to our R&D team so they can look into improving this in the future firmware releases.

Regards,
M.