Ruuvi aware BLE scanner for iOS available

NoHalfBits · April 4, 2018, 11:09am

Hello,

i’ve written a basic BLE beacon scanner for iOS, with parsers for ruuvi tag raw and Eddystone formats. Since there seems to be nothing else with ruuvi support on iOS right now, i’ve published it - maybe somebody will find it useful.
More information here: http://corebeacons.fluthaus.com.

It’s nothing fancy, just a byproduct of playing around with my ruuvi tags and dipping my toes a bit into Bluetooth LE, so please don’t expect too much. And naturally, it’s limited in some aspects by these many frustrating shortcomings of the weird iOS CoreBluetooth API… i’ll try to contain myself and not rant at length about it

lauri · April 4, 2018, 2:38pm

That’s awesome, great work @NoHalfBits !

I don’t have an iOS phone but our team will try this asap.

BTW, On App Store I can see that the logo is inverted. Please change it to this once you’ve got a chance:

github.com

ruuvi/brand/blob/master/logo/Eye.svg

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->

<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://creativecommons.org/ns#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:xlink="http://www.w3.org/1999/xlink"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   width="42.95388mm"
   height="42.953861mm"
   viewBox="0 0 152.19879 152.19872"
   id="svg3456"
   version="1.1"
   inkscape:version="0.91 r13725"
   sodipodi:docname="Eye.svg">
  <defs

This file has been truncated. show original

NoHalfBits · April 4, 2018, 7:46pm

interesting… must have slipped in when i was working on the mac version, which required a mask-type graphic for a different highlighting style.

ok, thanx for pointing out, will be in the next version. I think i will give it a few days to see what else shows up, than submit an update.

lauri · April 6, 2018, 6:16am

Could you confirm the feature to differentiate sensors from each other works ok, except the identifiers are not reproducible?

As long as the app + installation + device remain same, will also the UUIDs remain the same? What about when the app gets updated? Will it break the custom names?

No reproducible identifiers: CoreBluetooth denies access to the mac address of a BLE device; instead it assigns an UUID, which is different for every application, installation and iOS device. This makes it impossible to identify a beacon across applications, installations or iOS devices.

NoHalfBits · April 6, 2018, 10:07am

“confirm” may not be the appropriate word.

From what i’ve seen, the CoreBluetooth assigned UUIDs seem to be persistent:

over iOS device reboots
over version changes of the application (CFBundleVersion as well as CFBundleShortVersionString)
over changes in the BLE peripherals characteristic: advertised service types, manufacturer data
over reboots of a peripheral

The UUIDs change

~~when the application identifier (CFBundleIdentifier) changes~~ [Edit: maybe I was wrong about this, will have to investigate]
over macOS reboots

I haven’t had a chance to test (yet):

iOS updates
exchange of iOS devices for a given installation (like when transferring to a different device over iCloud or iTunes backup/restore)

All based on the limited selection of iOS devices and hence iOS releases available to me (can’t test in iOS Simulator, since CoreBluetooth there is just a stub)

So, for me, it seems stable enough for labeling beacons in a developer tool - in the end, you hopefully don’t lose that much if it breaks -, but with no detailed documentation*, i wouldn’t build my business model on it.

*) CBPeer.h only states that it’s a “unique, persistent” identifier, and the API documentation is even more vague. And that it’s actually persistent i think can be doubted, see macOS reboots above

lauri · April 6, 2018, 1:20pm

Ok, this is not so good Because, for now, we would like to continue shipping Tags with a factory preloaded data format 3 firmware which has no identifier embedded on the data packet. And at the same time would like support also multiple Tags on iOS.

Need to think about this. Maybe it would be “ok” to tell users to upgrade their firmwares if they would like to overcome this feature.

NoHalfBits · April 7, 2018, 9:19am

sorry, that was unclear: I literally meant “macOS”, like, in ‘Apples desktop os’. I 've observed UUIDs change after reboot there, while playing with a macOS version of Core Beacons (which got mostly abandoned over the even worse discovery performance of CoreBluetooth on macOS; discovery often takes minutes).

On iOS, in contrast, i’ve not yet seen CoreBluetooth assigned UUIDs - the value of the CBPeer ‘identifier’ property, to be precise - change after an iOS device reboot. Of course, this is no guarantee - as mentioned, the documentation is vague, and incorrect in the case of macOS - so we can’t know for sure which behaviour to expect.

Regarding the firmware: That’s fine for Core Beacons. On the long term, to my understanding, apps on iOS would benefit from features like connectability - which seemingly makes a big difference on how CoreBluetooth lets an app communicate with a peripheral, especially while being in the background. And iirc, Apple suggests some other details, like certain advertisement timing intervals, for BLE devices to be reliably detected by ‘Apple products’.

NoHalfBits · April 8, 2018, 7:43pm

Update approved by Apple, available on AppStore. And yes… icons look more familiar now, thanks for pointing me at this.

ximenchuixue · March 20, 2019, 2:46am

Is the uuid obtained by different iphone phones the same? Under what circumstances will the uuid change

otso · March 20, 2019, 7:09am

UUID will vary from device to device, but same tag should have same UUID on same receiver. The UUID might change on OS updates and reinstalls.