TG-BT5 Bluetooth tag - breaking change in latest firmware

Hardware MikroTik IoT hardware
1

Browsing the documentation I stumbled upon the changelog for the TG-BT5 tags, which listed version 2.4: [link] https://help.mikrotik.com/docs/spaces/UM/pages/215351328/MikroTik+Bluetooth+TG-BT5-XX+tag+changelog[/link]

However after upgrading a few tags, they stopped working with my backend.

It seems that the payload has been changed and MikroTik has prepended 3 bytes to the payload:

02010615ff4f0901006d67ffff00000100008014a802000061 #New payload from v. 2.4.0
      15ff4f090100cea6000000000200a01c91085700005f #old payload, example from documentation

However the documentation has not been updated to reflect these changes, and the meaning of the extra bytes. https://help.mikrotik.com/docs/spaces/UM/pages/105742533/MikroTik+Tag+advertisement+formats

The router itself is however aware of the format and can decode the payloads correctly:

address-type=public address=D4:01:xx:xx:xx:xx name="D4:01:xx:xx:xx:xx" persist=no mtik-key="" rssi=-50 
   last-data="02010615FF4F0901006C50FFFF0000FAFF4F1521C102000064" last-seen=2025-04-27 10:19:15 
   beacon-types=mikrotik mtik-version=1 mtik-encrypted=no mtik-acc-x=0g mtik-acc-y=0g mtik-acc-z=0g 
   mtik-temperature=21.308C mtik-battery=100% mtik-uptime=180513s mtik-flags=""

I have created a support ticket on this as well.

2

Hello!
As per the changelog entry:
https://help.mikrotik.com/docs/spaces/UM/pages/215351328/MikroTik+Bluetooth+TG-BT5-XX+tag+changelog

Include ad flags field in all advertisements.
New “octets” are now displayed in front of the payload. We will update the “format” guide shortly.

“020106” will be added now in front of the payloads. Those octets represent “flags” field:
https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/CSS_v11/out/en/supplement-to-the-bluetooth-core-specification/data-types-specification.html
which simply “indicate” that the flags fields “length” is “02”, type is “01” and data is “06” (which, frankly, only tells surrounding devices that it is “LE” and “discoverable”).

You can, simply, interpretate those octets as a new “static” octets that you do not have to “pay attention” to. There is not much useful information in those.
We’ve made the decision to add the “flags” field because other vendor scanners might not pick up the payload (drop it) if the “advertisement” does have this field in it.

Unfortunately, you will have to rewrite scripts (if you use them to collect Bluetooth information from the tags). If the script is used to “pick” specific “octets” from within the Bluetooth payload, they have to be shifted slightly by 3 octets.

3

Thanks for an exhaustive answer! :slight_smile: I will update my scripts to iterate through the ADs until the MikroTik AD is found.

On the topic of the relase note, it calls out the following:

  • Added an option for MikroTik format payload to detect disabled accelerometer.

Can you elaborate on how to detect this? I suspect it might be and additional bit in the flags field (the 7th bit, which is the next unused bit?), and I could just test it and compare payloads, but I would like to hear it from official side.

4

I have updated the “format” guide.
Added an option for MikroTik format payload to detect disabled accelerometer.
means, that in new app version, there should be “disable accelerometer” checkbox. When you disable it, it will show in the “second to the last” (24th octet), a new “state”:
“40” indicates disabled accelerometer.
In other words, if you see “40” in that octet, it means the accelerometer was disabled in the settings.

5

Thanks a 10^6 :slight_smile: