Scanning for Estimotes from a Linux based SOC chip like Raspberry Pi

Hi,

I’m trying to write a script to scan and list nearby estimotes on a linux machine. As mentioned here, I tried to use the Bleacon library for node.js. However, the library does not work for firmware version 3.2 and above.

As an alternative, I used the node.js library Noble and look for the UUID “fe9a” in the BLE advertisement service data, and then uniquely identify the estimote by the “device address”. However, I understand this will only work if the Estimote has a static device address, which need not be the case. I wanted to double check if the device address used by a estimote is static across advertisements, or is there a chance they can change?

Since you only have an SDK for Android and iOS, what is the suggested way of developing a scanner for a Linux platform? Do you have some support for Python, Java or any other languages?

Thank you.

“bleacon” is for detecting iBeacon packets, so it should still work with the latest Estimote Beacons—you just need to enable iBeacon on them, since it’s no longer enabled by default.

Alternative 1: enable some Eddystone packet(s) on your beacon, and use “noble” to scan for the FEAA service UUID, and parse the service data yourself per the Eddystone spec:

https://github.com/google/eddystone/blob/master/protocol-specification.md

Alternative 2: enable Estimote Telemetry on your beacon (actually, should be enabled by default, but you may want to adjust the advertising interval, since it’s pretty slow by default), and then use our open-source Estimote Telemetry parser/detector built on top of “noble”:

https://github.com/estimote/estimote-specs
https://github.com/estimote/estimote-specs/blob/master/estimote-telemetry.js

Thank you so much! I am able to parse the telemetry packets with the estimote-telemetry script. The short Identifier in the telemetry packet should be good enough to uniquely identify the devices for my purpose. I have one more question.

Is there a reason why the short identifier in the estimote telemetry packet is preferred over the “peripheral.address” or “peripheral.id” fields that I get with noble for estimote packets?

I don’t know what peripheral.id is, I assume it might be some internal noble/Bluetooth stack ID for the given peripheral, so I don’t think it’d be wise to use that. (e.g., it might be different for the same beacon, but detected on two different devices)

peripheral.address is the Bluetooth address of the device, and for your specific situation, it actually should be a good alternative to the Estimote ID. The only drawback I can think of is, Estimote Cloud doesn’t show (or even know) the Bluetooth address of Estimote beacons, so you won’t be able to easily find a beacon by its address in Estimote Cloud or apps.