Introduction

Bluetooth interface implementation in RouterOS allows the device to capture Bluetooth advertising packets that are broadcasted over 37, 38, and 39 advertising channels. More information can be found in the guide here.

Bluetooth tags like, for example, TG-BT5-IN and TG-BT5-OUT, do exactly that. They broadcast advertising payloads over the mentioned channels. To understand what kind of information is stored in the payload, make sure to check the link.

Amongst different use cases for the Bluetooth tags, as the title suggests, it is possible to implement a scenario, where you can track the approximate position of the tag.

What you are going to need is:

• 2+ devices with Bluetooth interface, like the KNOT (the amount of the devices required depends on the size of the area);
• 1+ Bluetooth TG-BT5-IN and/or TG-BT5-OUT tags (depending on how many assets you need to track);
• a server that is going to collect and visualize the data.

How is it going to work? Let's say, you have a warehouse...

You can scatter the KNOTs across the warehouse so that the KNOT's Bluetooth range does not overlap with the neighboring KNOTs. You need to test the Bluetooth range in your environment/topology to figure out how far the Bluetooth range goes, as it can be much lower than expected if you have a lot of 2.4 GHz interference. For example, in line of sight, with no interference, the KNOT can catch the tag's payload from up to 180 meters away. But you also have to keep in mind that with more distance → more packets will be lost on the way.

Once the KNOTs are spread out, the idea is simple

Take a look at the topology shown below:

MikroTik Bluetooth tags, like → TG-BT5-IN and TG-BT5-OUT ← Many RouterOS devices have GPS support. It allows RouterOS to determine the precise location of its GPS receiver. GPS coordinates will indicate the latitude and the longitude values (among other parameters) of the current position.

Let's say, you have LTAP (or any other RouterOS device with GPS support) and you wish to track its location. You want the router to send this data to a server, where the data will be stored and integrated into a map, as it is more convenient to monitor. In this guide, we will showcase how you can do that. This scenario will utilize MQTT protocol communication with a platform called ThingsBoard.

ThingsBoard has a cloud solution and different local installation options (on different OS).

Since we've added a container feature, it became possible to also run the platform within the RouterOS. Meaning, you can build this scenario, solely on RouterOS units → devices with GPS support that you wish to track (for example, cars equipped with LTAPs → RouterOS devices that act as MQTT publishers), and a ThingsBoard server run within a more powerful RouterOS device (for example, a CHR machine or CCR2004-16G-2S+ → RouterOS device that acts as an MQTT broker).

If you want to choose this route (container route), make sure to pick the devices that you plan on using as a "server" carefully, because this implementation can be heavy on RAM usage (it is suggested to have a device that has at least 2 GB RAM and is either ARM64 or AMD64 architecture).

Configuration

/iot/mqtt/brokers/add name=tb address=x.x.x.x port=1883 username=access_token