Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 RouterOS. In order to do that, you will need a RouterOS device that has at least 2 GB RAM, has an option to increase storage (for example, an additional USB port), and is either ARM64 or AMD64 architecture. CHR machine or CCR2004-16G-2S+ could be a good fit.

Setup requirements:

  • a running ThingsBoard server;
  • 2+ devices with Bluetooth interface, like the KNOT KNOT's with access to the server's network via ethernet, Wi-Fi, or cellular connection (the amount of the units required depends on the size of the area that needs to be covered);
  • 1+ Bluetooth TG-BT5-IN and/or TG-BT5-OUT tags (depending on how many assets you need to track - 1 tag per asset);
  • a running ThingsBoard server.

Just attach the tag to the asset and, after a few additional steps explained below in this guide, you will be able to track its approximate location.

...

As a result, when you have 2 KNOTs (KNOT-A and KNOT-B), running the same script on a scheduler, and the tag moves between their Bluetooth operating ranges, you will have the data on the server indicating whether it was KNOT-A or KNOT-B that have sent the tag's payload. Of course, by that logic

Logically, if the Bluetooth operating ranges overlap and the tag is within the overlapped area (at the same time within KNOT-A and KNOT-B Bluetooth ranges), both KNOTs will send the data and the server will showis going to show that the tag is reported by both devices at the same time.

Keeping the above mentioned in mind, you can position the KNOTs across your environment Let's say, you have a warehouse. What you can do, is you can scatter the KNOTs across the warehouse so that the KNOT's Bluetooth ranges do 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 each other but cover the whole area. The actual Bluetooth operating distance can vary from site to site because a lot of different factors can impact it, like 2.4 GHz interference or materials that can impact the signal strength, like concretethe surrounding materials used. For example, in line of sight, with no interference, the distance at which the KNOT is able to capture the tag's broadcasted payload, can be up to 180 meters (KNOT — ~180 meters — TG-BT5-OUT). But you also have to keep in mind that with more distance, more packets will be lost on the way.

The idea is simple,

In the office environment, the range can go down to much less than 100 meters.

To understand the scenario, take 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)a warehouse and you wish to track pallets.

Configuration



Info

This example will showcase access-token and one-way SSL communication via access-token scenarios for simplicity reasons, but you can use other available options as well.

...