We are planning to use Ruuvi weather station beacons in a big hall to mark tools and track them using the mobile devices carried by workers.
Until now we discovered that Ruuvi emits data in two modes, switchable by pressing the B button: URL mode and RAW mode. Out-of-the-box the beacon emit in either Format 3 or 4.
We need a way to get the beacon’s unique identifier in URL mode. The URL frame contains a 6 bit ID. This is not sufficient for us, as we will have much many devices in use, and many would overlap IDs.
Using pre-release firmware 2.2.2 the beacon sends data in Format 5 if you switch it to RAW mode, which delivers the MAC address as a UDID.
However when the device is in RAW mode, our app doesn’t detect the beacons at all while in background. In order to find devices when our mobile app is in background mode we need a specific service ID to scan after, which seems not to be available in RAW mode.
Is there a service ID based on which we can scan for devices in RAW mode? In URL mode for example the beacons expose the FEAA service ID and we are able to scan them while the app is in background.
You should be able to use tags as they come if you’re using Androids only. The ad type is “Manufacturer Specific data”, 0xFF. You should be able to find the beacons with it.
If you’re using Mac devices you’ll need to use 2.x firmware, as Mac hides the MAC addresses from applications.
We could also make a custom firmware which advertises the ID in URL, but it’s definitely easiest to use off-the-shelf RuuviTags if possible.
We are using iOS devices.
With 2.x firmware the URL frame contains still the 6-bit ID. Are we missing something and is there actually a way to extract also the MAC address with fw 2.x?
The URL format is the same in 1.x and 2.x. You should get the MAC address on 2.x in the manufacturer specific data, please refer to https://github.com/ruuvi/ruuvi-sensor-protocols data format 5, 2.x FW sends it in RAW mode.
If you cannot use the RAW format for some reason, we can make a custom firmware which would have the ID in the URL mode, or we could ship the tags to you as Eddystone beacons. This would however lead to higher unit cost since we need to take extra steps at the factory to flash the special firmware to you. Please contact sales@ruuvi.com if you’re interested in such a solution.
When the app wakes app from background as a result of entering the region of an iBeacon, we attempt to scan all Ruuvi beacons.
However, if the Ruuvi beacons are in RAW mode, the scanning doesn’t work because there is no exposed service ID.
Do you know how if it’s possible to do this scan in background on iOS?
This is an area I’ve not yet played around so I don’t have much to add.
Maybe it would be possible to register the tags for background scanning with the UUID while in foreground somehow?
I will surely be touching this topic in the coming weeks so I’ll update here if I find something :).
To my understanding - from what i learned when writing Core Beacons, and backed by the CoreBluetooth documentation -, with the current CoreBluetooth API it’s not possible for an app to receive BLE advertisements from ruuvi tags in raw-mode (a.k.a. non-connected, non service-uuid advertising) while being in the background.
On the other hand, if your app receives Eddystone-URL advertisements in the background*, you’ll get the CB-UUID of the tag, which identifies it uniquely on the iOS device.
So, depending on the nature of your project, you may be able to do some manuell pairing between each ruuvi tag and each iOS device in a setup phase, building a mapping between the local, device-specific CB-UUIDs and a global identifier.
*) did you test this? CB documentation is a bit ambiguous about this, imho
thank you for your input!
Actually we investigated this path as well, of using CB-UUID from the bluetooth device profile. The problem with this approach is that CB-UUID is unique only per iOS device, meaning that the same beacon will have different CB-UUIDs on two different iPhones.
To circumvent this one could use an internal UDID (sticked physically to the beacon) which would be also kept on our server. Ths internal UDID would then be associated with a list of CB-UUIDs. However, this way things get quite complicated and error prone. Probably we won’t go down that route.
@otso, @io53, is there a mode in which the Ruuvi devices act as iBeacon devices?
In general, besides URL and RAW can we switch the Ruuvi device to other modes as well?
We currently do not have iBeacon firmware, but it would be relatively quick to implement. Our stock firmware has only URL and RAW modes.
You can get started really fast with iBeacon if you have a devkit, as Nordic Semiconductor does offer their own iBeacon example with precompiled .hexes. I think the hex would run as-is on RuuviTag, but some work might be required to make configuring the beacons easier.
