We have a huge problem with implementing iOS app that could listen to beacon (not iBeacon) messages as background operation.
What does success look like?
There are 20 Ruuvitags sending data to one iOS device that is on the table. Once opened and authenticated to some cloud, it just listens to the beaconing and transfers the data time-to-time to cloud. It continues the operation also tomorrow and day after that without opening the app - as background function.
Notice that the protocol for tag can be rewritten also. If there is some way to implement this operation, I’m really interested.
Is this possible?
If someone has already implemented this or is able to implement this => Award.
Can you be a bit more specific on what problems exactly you encountered, and what the deployment path will be (in house, Apple Appstore).
I can think of a few ways to do this, but it depends on requirements and where you are already with this…
One BLE advertisement has 34 bytes (iirc), of which 24 or 27 bytes is useable payload depending on if the advertisement is advertisement or a scan response. Sending kilobytes in advertisement would probably require getting creative with BLE5 advertisement extensions, and supporting them on iOS would probably require even more creativity.
Peripheral connection and sending data over Nordic UART Service (for example) would sound easier approach to me. Connections don’t have to be simultaneous, a tag could advertise “Hey, I’ve data, read me!” and stop advertising after read. Phone would then get data from one beacon at a time
I too would suggest peripheral connections to read the data.
The problem though with iOS/CoreBluetooth is that an app will (almost) never see advertisements when in the background. And connections - which offer notifications on value changes - are problematic because of the (undocumented, as far as I’m aware of) limit on the number of concurrent connections, and simply connecting round-robin to all known peripherals is killed by another detail of CoreBluetooth.
But, just out of the back of my head: With the given requirements, and if there is full control of the peripherals radio, the CoreLocation-API may be usable for the “Hey, I’ve data, read me”-announcement. There will be some pitfalls and tricky details, but on the technical side*, this may be the best bet.
@Jarmo_Hiljanen: I may come up with a proof-of-concept implementation; if you’re interested, please feel free to contact me
*) I think this will not violate any AppStore-rules upfront, but it will still require an ugly amount of capabilities and “creative” usage of APIs; with this, app review may turn into a bit of a fight
I’ve scanned few best Finnish SW companies, had meetings with them and come to same assumption - Beacon is going to be very tricky or impossible to implement like we want.
We have decided to continue development with PoCs. We just have to find the way to do this somehow. So, thanks @NoHalfBits for the offer, I’ll be in touch if our way does not work.
RuuviTag does not connect to phones. BLE capable devices can listen RuuviTag’s broadcasts. So there is no limit on how many devices can simultaneously hear the messages .
I tried latest iOS weather station app and it is very different to android version.
It is missing alerts setup and accelerometer readings.
Is there an update on the way or is that more or less it for now ?
Alerts won’t work as expected on iOS, since iOS doesn’t allow apps to receive BLE advertisements when not in the foreground. I’ve written a bit about this here, see “Known Limitations”.
So please go complain about that broken bluetooth implementation file a bug report / feature request with Apple…
Ruuvi iOS app is still on development and we are planning to add as much as possible same features as in Android version. But like @NoHalfBits wrote some of these features are challenging to implement.
