eddystone | Specification for Eddystone, an open beacon format from Google

According to Eddystone documentation, Eddystone is a protocol specification that defines a Bluetooth low energy (BLE) message format for proximity beacon messages (data from your sensor) and farther specifies a Configuration GATT Service that allow to make some configurations.

In BLE terms, the Eddystone sensor is a peripheral that should expose the Eddystone Configuration GATT Service and advertise data according to the Eddystone format.

In order to use the Eddystone Configuration GATT Service you have to establish a BLE connection from central (your IPhone) and the peripheral (your sensor) and to write the parameters in the characteristics.

According to documentation of Eddystone Configuration GATT Service, to stop the advertisement write an empty array, or a single 0x00 in the charatecistic with UUID a3c8750a-8ed3-4bdf-8a39-a01bebede295.

This is possible if your sensor exposes this service.

arr1 is an Array it doesn't have beacons property. If you expect it to be the only one item with the mac you should use data.find instead of data.filter. Also do not use for-in loop to iterate over arrays. You can use for-of or .forEach instead.

The two vendors below claim to sell beacons compatible with Eddystone-EID as of October 2021:

• Gimbal

• Estimote Location Beacons

Before you buy anything beware that Google shut down their beacon platform web services in April 2021. I wrote a full blog post to explain what this means: Eddystone is Dead, Long Live Eddystone!

Using these web services is completely optional for Eddystone-UID and Eddystone-URL, but critical for Eddystone-EID, because the beacon identifier rotates with a crypto algorithm and a “trusted resolver” server is needed to convert the advertised “ephemeral identifier” from jibberish to something meaningful and useful.

Without Google’s beacon platform web services, I am aware of no commercially available trusted resolver for Eddystone-EID. You would need to build your own, which is a non-trivial effort. Without a trusted resolver Eddystone-EID is worthless.

Because of this, make sure the vendors above still support using their products with Eddystone-EID. In time, it is likely they will remove support in their beacon firmware.

Finally, it is important to note that just because Google gave up on their beacon web services, most apps that use Eddystone, iBeacon and Altbeacon are unaffected. Beacons are standardized and will work forever — just don’t use Google web services! Again, beacon technology aside from Eddystone-EID has no need for Google web services.

I looked at the library you linked to and it had the following for temperature:

The only platform that allows you to do this is the Chrome Browser on Chrome OS. On that platform, users can optionally enable BLE advertising in a browser setting, then apps can programmatically configure BLE advertising including for beacons like Eddystone. The folks at Radius networks put together a JavaScript Beacon Library to help you do this.

For all other platforms the answer is no, you cannot advertise BLE using a web browser. This answer applies to all other browsers on all other operating systems.

It is worth mentioning that Google sponsors the Web Bluetooth initiative to bring BLE support to browsers. However, it is designed to support only the BLE central role (not the peripheral role needed to advertise). And even Web Bluetooth's central support is very limited -- it doesn't support general BLE scanning for beacons (it only supports scanning for BLE services for connection purposes.) Further still, Web Bluetooth is not supported at all by Apple Safari on either iOS or MacOS, and Apple has said it does not plan to support it in the future.

Bottom line, if you want to work with beacons in the web browser, you are largely out of luck. The one exception is that you can advertise on ChromeOS.

Eddystone UID: A unique, static ID with a 10-byte Namespace component and a 6-byte Instance component. In onScanResult you can extract Eddystone uid packet like below

Those packages look like they are just for iBeacon which uses manufacturer data in the advertising packet. For Eddystone it uses service data. The flutter_blue library give you access to the service data. https://pub.dev/documentation/flutter_blue/latest/flutter_blue/AdvertisementData-class.html

The following answer shows how to scan and access the advertising data with flutter_blue: https://stackoverflow.com/a/63591662/7721752

There are two variants of Bluetooth LE advertisements defined by the Bluetooth SIG standards body:

1. GATT Service Advertisements - these are designed to advertise GATT Services and may have service data bytes, which are designed to tell you something about the advertised service.
2. Manufacturer Advertisements - these are designed for any purpose that the Bluetooth device manufacturer wishes to use. They always include manufacturer data of 0-24 bytes.

When Apple designed the iBeacon format, it chose to use manufacturer advertisements. As a result, whenever you detect them you must get the manufacturer data to decode the contents.

When Google designed Eddystone, it chose not to use manufacturer advertisements and instead use GATT Service advertisments. It made this choice because it wanted he format to work well on iOS devices, and iOS generally refuses to let 3rd party apps detect manufacturer advertisements (other than iBeacon) in the background.

Because of this design decision by Google, you must check to see if there is service data when attempting to decode Eddystone advertisements.

If you want to detect both beacon types, use logic like this:

1. Is there attached service data? If no, go to step 3.
2. Can the service data be decoded as Eddystone? If yes, we are done.
3. Is the advert a manufacturer advert? If no, go to step 5.
4. Can the manufacturer data be decoded at iOS, if yes, we are done.
5. The advertisement is neither Eddystone nor iBeacon.

Curve25519 represents keys in little-endian order. X25519 (ECDH with Curve25519) represents the shared secret in little-endian order. This is unlike most standard formats used in cryptography, in particular keys on SECP/NIST and Brainpool curves and the shared secret from ECDH with Weierstrass curves, which represent numbers in big-endian numbers. So change both calls to mbedtls_mpi_write_binary to mbedtls_mpi_write_binary_le.

Alternatively, use mbedtls_ecp_point_write_binary to export the public key and mbedtls_ecdh_calc_secret to calculate the shared secret: they take care of formatting the numbers with the correct endianness for each curve.

I haven't verified that this is the only problem.