You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 64 Next »

Introduction

The introduction of the container feature into the RouterOS made it possible to run all kinds of servers for all sorts of tasks inside the router. This is especially relevant for people, who want to reduce the number of devices in their network. Instead of running a server on a separate device/machine, why not run it inside the router?

A lot of users need a server that is able to gather the data, store it and display it in a way it is easy to understand. This is where a platform like ThingsBoard can come into play.

It is primarily positioned as an IoT platform and you can find all sorts of use cases for it that they demonstrate in the link.

The most appealing part, from the RouterOS user standpoint, is that it can be used as an MQTT server (MQTT broker) or an HTTP server. Meaning, you can use MQTT publish or HTTP post to post the data. You can find ThingsBoard MQTT API guide by using the link here and HTTP API by using the link here.

In short, you can collect RouterOS statistics (like uptime, GPS coordinates, packet statistics, and almost anything else that you print into the terminal), then store this information into variables and structure a JSON message out of those. You can, then send this message via MQTT or HTTP to the ThingsBoard via a schedule (that will run this script whenever you need it). You can find an example of the steps in more detail explained in this guide.

ThingsBoard will store and display the data with the help of widgets, which can be used to help you set up dashboards that visualize the data in graphs, tables, maps, and other ways.

There are 3 versions of the ThingsBoard instances available and each of them uses a different database:

You can find more information in the ThingsBoard/docker documentation.

In our example, we will showcase tb-postgres - a single instance of ThingsBoard with PostgreSQL database.

Summary

Sub-menu: /container

note: container package is required.

RouterOS versions that are older than 7.x will not be able to run this scenario as they will not have a "SYSVIPC" feature added to the kernel that allows it to work.

Make sure to study our container guide before proceeding with the configuration. Make sure to check the disclaimer and requirements sections to understand all the risks and necessary steps you might be required to do.

In this example, we will run it on a Cloud Hosted Router (CHR) device. To help you set it up in a Virtual Box, please check our youtube tutorial.

At the time, when the guide was published, thingsboard/tb-postgres image was available for linux/arm64 and linux/amd64 OS/architectures only. Meaning, you are not able to run this scenario on our arm32-bit architecture RouterOS devices.

There are a couple of parameters to keep in mind:

  • You need to understand that it is a server and that you will need to have additional space for the data that is stored there and the image itself. In our tests, 8 GB of disk space was plenty enough but! you might want to consider adding more for real-life applications, especially if you are planning on running more containers. Just remember → it might be better to have a reserve.
  • Same as with the disk space, RAM memory is also important. Per the ThingsBoard documentation, when using a single instance of ThingsBoard with a PostgreSQL database, it is recommended to allocate at least 1GB of RAM and use a minimum load (a few messages per second). 2-4GB RAM is recommended. In other words, if you want to run it on a RouterBoard device, please understand, that you will not be able to run it on devices that have less than 1 GB RAM (every device should have information about its RAM under their respective specification page, so make sure to check it) and, even better, consider having a device with more memory to spare.

Check the tips and tricks section to understand how to limit RAM and our recommendations about disks.

Configuration

Container mode

Enable container mode:

/system/device-mode/update container=yes

You will need to confirm the device-mode with a press of the reset button, or a cold reboot, if using container on X86.

Networking

  • Add veth interface for the container:
/interface/veth/add name=veth1 address=172.18.0.2/24 gateway=172.18.0.1
  • Create a bridge for containers and add veth to it:
/interface/bridge/add name=dockertb
/ip/address/add address=172.18.0.1/24 interface=dockertb
/interface/bridge/port add bridge=dockertb interface=veth1
  • Setup NAT for outgoing traffic:
/ip/firewall/nat/add chain=srcnat action=masquerade src-address=172.18.0.0/24
  • Forward TCP 9090 for HTTP management (the default HTTP port per ThingsBoard documentation):

We suggest using HTTP access (non-SSL) only when testing locally or through a VPN (when you are certain that the local network is safe).

When you want to access container WEB management from the internet (from the public network/WAN), please, instead, consider using HTTPs.

/ip firewall nat add action=dst-nat chain=dstnat dst-address=192.168.88.1 dst-port=9090 protocol=tcp to-addresses=172.18.0.2 to-ports=9090

In the dst-address field shown in DNAT (dst-nat) rule above, we use the device's local IP address. First, use local IPs (local access) to set everything up and confirm that everything is working.

Then, after further securing this setup → (a) making sure that all default ThingsBoard user credentials were changed/removed (reference ThingsBoard documentation), (b) enabling HTTPs (the steps will be explained later on in the guide), (c) preferably changing HTTPs port to a non-standard one (reference ThingsBoard documentation) → you can consider enabling remote access from WAN (using your public IP address in the dst-address field). Please understand that only you are responsible for the security. If you leave a door open, someone may exploit it. You need to have networking knowledge and understand the risks when setting up such access.

  • And for non-SSL MQTT connection, 1883 TCP:

We suggest using non-SSL MQTT (TCP 1883) communication only when testing locally or through a VPN (when you are certain that the local network is safe).

Please consider using SSL MQTT (TCP port 8883), instead of non-SSL MQTT (TCP port 1883), for real-life applications, when it comes down to access from the internet (from the public network). If you use non-SSL MQTT, the communication between the client (MQTT publisher) and the server (MQTT broker) can be easily sniffed/packet captured, and that will compromise authentication data (such as client-ids, usernames and passwords).

/ip firewall nat add action=dst-nat chain=dstnat dst-address=192.168.88.1 dst-port=1883 protocol=tcp to-addresses=172.18.0.2 to-ports=1883

In the dst-address field shown in DNAT (dst-nat) rules above, we use the device's local IP address, but you can use your public IP address instead.

When using public IP addresses, we highly suggest further increasing security. Consider further restricting such access with the help of src-address=x.x.x.x parameter, where you can input specific trusted source IP addresses, consider using non-standard ports, and using SSL MQTT communication. The configuration example above is just a quick/basic example. Access from the internet to LAN/device SHOULD NOT be taken lightly. Please read this.

An example of SSL MQTT DNAT rule would look like this:

/ip firewall nat add action=dst-nat chain=dstnat dst-address=router_IP dst-port=8883 protocol=tcp to-addresses=172.18.0.2 to-ports=8883

Environment variables and mounts

Check docker-thingsboard documentation for exact mounts and variables that need to be added.

Environment variables:

/container/envs/add name=tb_envs key=TB_QUEUE_TYPE value="in-memory"

Mounts:

/container/mounts/add name=mytb-data src=tb/mytb-data dst=/data
/container/mounts/add name=mytb-logs src=tb/mytb-logs dst=/var/log/thingsboard

Getting image

To simplify the configuration, we will get the image from an external library but you can also import it via the .tar file.

Make sure that you have "Registry URL" set accordingly, limit RAM usage, and set up a directory for the image.

/container/config/set registry-url=https://registry-1.docker.io tmpdir=pull ram-high=2048.0MiB

Pull image:

/container/add remote-image=thingsboard/tb-postgres:latest interface=veth1 root-dir=ThingsBoard mounts=mytb-data,mytb-logs envlist=tb_envs logging=yes

After running the command, RouterOS should start "extracting" the package. Check "File System" for newly created folders and monitor container status with the command /container/print.

Starting the container

After you make sure that the container has been added and the status changed to status=stopped after using /container/print → you can initiate it:

/container/start 0

Wait for a couple of minutes for the container to fully load.

Verification

After the container is started and installed, access it using any browser via the machine, where CHR is installed, by going to → http://192.168.88.1:9090 (where the IP address is the address used in the DNAT rule).

By default, credentials are (Username/Password):

  • Systen Administrator: sysadmin@thingsboard.org / sysadmin
  • Tenant Administrator: tenant@thingsboard.org / tenant

The login prompt should confirm that the server is running.

The follow-up steps, in the MQTT test section below, are just a quick example of how you can test MQTT publish.

MQTT test

Log in with the tenant and create a new device. Go to the "Devices" menu, click on the "+" (Add Device) button and choose the "Add new device" option:

 Name it, however, you like, and click on "Add":

Check your device access token by clicking on the device you've just created and selecting the "Manage credentials" setting (copy the access token generated or type in your own →  "YOUR_TOKEN"):

After these steps, go to the RouterOS settings (back to CHR settings) and create a new MQTT broker (make sure that you have IoT package installed because otherwise, you will not have this menu):

/iot/mqtt/brokers/add name=tb address=172.18.0.2 port=1883 username=YOUR_TOKEN

Publish a static test MQTT message in the JSON format:

/iot/mqtt/publish broker="tb" topic="v1/devices/me/telemetry" message="{\"test\":\"123\"}"

Confirm that the message was posted:

  • No labels