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
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.
Thanks for an exhaustive answer! 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.
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.