MQTT Client on IoT hardware -> OTD500 -> AWS IoT core MQTT Broker

NETWORKING SOLUTIONS
1

I am deploying an OTD500 5G router to a site which has some installed hardware that exposes an MQTT Client interface which can publish readings and receive control commands.

I know that the OTD500 support running an MQTT broker ( OTD500 MQTT - Teltonika Networks Wiki ) and authenticating to AWS IoT core through the AWS IoT Provisioning support ( OTD500 Cloud Solutions - Teltonika Networks Wiki ).

I have three questions:

  1. What steps do I need to complete to correctly configure the OTD500 to run an MQTT broker that can foward MQTT messages to AWS IoT core and receive MQTT messages from AWS IoT core? Based on the “AWS IoT + RUT956 MQTT Bridge” topic in this forum (I’m a new user so have been restricted to 2 links) I think I would configure the OTD500 to run an MQTT Broker along with an MQTT Bridge?
  2. Do I need to complete any steps to configure the OTD500 MQTT broker to cache messages so that if the connection to the internet is lost and later restored, any messages sent during the outage will still be delivered? Or do I get this for free as long as the subscriptions are QoS 1 or 2, and the subscriber connections with clean session = false?
  3. The OTD500 MQTT docs say that the “Max queued messages” setting can be configured on the broker. Is it possible to set the Mosquito “max_queued_bytes” setting? If not, what happens if the total size of cached messages is larger than the available disk space? Is it possible to fill up the disk and cause the OTD500 to stop working properly?
3

Hello!

We have a configuration example of setting up the AWS IoT as an MQTT broker and our device as a publisher in order to send data over the broker, the example can be found here: AWS MQTT cloud connection - Teltonika Networks Wiki
Bare in mind, although the example utilizes a RUT device, the OTD500 also has RUTOs as its operating system, therefore the example should be consistent with what you will see during the configuration.

This is correct.

Not something that is configurable on our devices, at least at the moment (max_queued_bytes) - When the queue is full, new messages are discarded.

Regards,
M.

4

Thanks for the quick reply!

How much disk space is available for queued messages? What happens if the “Max queued messages” is set to a large enough number that the OTD500 runs out of disk space before the maximum number of queued messages is reached? Is it possible to fill up the disk and cause the OTD500 to stop working properly?

5

Hello,

The maximum number of messages to be saved can be 65535. It’s hard to tell whether it will take the entire space of the device due to the fact that every message can have a different size. I would probably suggest opting for a lower number than the maximum. I’d also like to re-mention & fix my typo in my previous response, when the x amount of messages is met, old ones get discarded and new ones take their place.

From personal experiences, we haven’t had clients with issues such as the device memory being full due to these messages & the devices breaking, therefore I would assume you should be okay with the proper amount of messages configured to be saved.

Regards,
M.

6

The “Setting up AWS IoT” section of https://wiki.teltonika-networks.com/view/AWS_MQTT_cloud_connection is relevant, but the rest of the article covers publishing data sourced from the Teltonika device, or from Modus.

These are the steps I followed to get data flowing from IoT device (MQTT client / publisher / subscriber) → OTD500 → AWS IoT core.

Key initial AWS IoT setup steps:

  • Create a thing, download Device certificate, Private key, Root CA cert

  • Create a policy (see notes below) and attach to certificate

  • Get MQTT endpoint

AWS Policy:

  • Fill in correct region

  • Fill in correct account ID

  • Fully wildcarded publish/subscribe as we don’t control the topic names. Permissions could be restricted more by setting a “device/{deviceId}/” prefix on the policy and setting a different policy for each thing.

  • NOTE: Wildcarding in policy uses “?” and “*” rather than MQTT wildcards of “+” and “#”

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Connect",
      "Resource": "arn:aws:iot:<region>:<account-id>:client/${iot:Connection.Thing.ThingName}"
    },
    {
      "Effect": "Allow",
      "Action": "iot:Publish",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iot:Subscribe",
        "iot:Receive"
      ],
      "Resource": "*"
    }
  ]
}

OTD500 config:

  • Service → MQTT → Broker

  • MQTT:

    • MQTT broker: on

    • Enable remote access: on

  • Broker settings → Miscellaneous:

    • Password file: (see below, then upload)

    • Persistence: on

Password file (example password):

brew install mosquitto
echo "admin:admin01" > ~/password_file.txt
mosquitto_passwd -U ~/password_file.txt

  • Bridges:

    • Name of the new bridge instance: AWS

    • Add

  • “AWS” bridge configuration

    • Protocol version: 3.1

    • Remote address: <result from “Get MQTT endpoint”>

    • Remote port: 8883

    • Use remote TLS/SSL: on

    • Bridge CA file: <AmazonRootCA1.pem from earlier>

    • Bridge certificate file: <device_certificate.pem.crt from earlier>

    • Bridge key file: <private_key.pem.key from earlier>

    • Bridge TLS version: tlsv1.3

    • Use remote bridge login: on

    • Remote ID:

    • Topics configuration:

      • Topic name: prefix/#

      • Direction: OUT/IN/BOTH

      • QoS: 0/1/2

7

Thank you for sharing your solution, it will be very useful for any users that might want to set this up in the future!

Regards,
M.

8

From personal experiences, we haven’t had clients with issues such as the device memory being full due to these messages & the devices breaking, therefore I would assume you should be okay with the proper amount of messages configured to be saved.

The MQTT messages we are processing are ~3kb and are sent every 60 seconds (60 x 24 = 1440 messages/day). If we have 10 devices onsite sending readings, and we have a connection outage, then this means there will be 14,400 messages/day, taking up 14,400 x 3 = 43MB on disk waiting to be sent.

The OTD500 only has 88.8MB of disk space available in total for all logs etc. I think this means that the device could only store ~one day of messages safely during a connection outage.

What would happen if I configured “Max queued messages” = 45,000 which would be enough messages for a three day buffer, but would require 135MB of storage space. Would old messages get discarded, or would the device run out of space and crash?

9

Hi there,

I’ve inquired about this with the R&D, will get back to you as soon as I have an answer.

Regards,
M.

10

Have you had a reply from R&D about this?

11

Hello!

Glad you asked, since they replied not too long ago - the memory usage depends on what kind of data is being sent; however, it is always being rotated (in other words, new data replaces old data when full). Regarding the buffering of the messages, the device will buffer as many messages as you set under the max_queued_messages setting; every other message beyond that will be dropped. Regarding how much memory will be needed for this, it depends on how much data is contained within a single message.

Regards,
M.

12

Thanks for the reply. Just to check my understanding, does this mean that even if I set max_queued_messages very high, and I’m processing large messages, that the MQTT broker will start discarding old messages if it runs out of available memory/disk space?

13

Hi there,

It’ll discard old messages.

Regards,
M.

14

Perfect, thanks for getting me answers!

1 Like
15

No worries at all!