I'm trying to develop a solution, where iBeacon has to be used as an alerting mechanism. This iBeacon has to receive alerts or messages from a remote server and then publish the same to its nearables.
Is this a possible usecase where iBeacon has to receive request from a remote server? As a disclaimer, I new to this technology and let me know if my understanding is wrong.
I believe you are approaching this problem from the wrong angle. Essentially you would like to receive a message when you encounter certain iBeacon signals. iBeacons are "dumb" devices, meaning they can only broadcast a data packet, they cannot receive any information and cannot broadcast anything different than the iBeacon protocol packet.
That being said, if you had a remote server that stored these messages, you ask the server what the most recent message is associated with the beacon you have just encountered. That way you can change the messages dynamically on the server based on what you need your user to know.
So essentially, because each beacon can be uniquely identified based on UUID, major, minor, you can store your messages based on this so that you can ensure the user is receiving the correct message when they encounter the beacon by sending these identifiers up to your server in order to retrieve the message.
Related
How to know the remote device is online using mqtt (as a device simulator I am using MQTTfx). After publishing to a topic I am not getting any acknowledgement message and in the callbacks I am getting the same payload data that is published.
You can not find out is another MQTT client is online at a protocol level, in fact at a Pub/Sub pattern level a publishing client should not care is 0 or an infinite number of other clients are subscribed to the topic that message is published on.
The callbacks are only an indication that the message has been successfully delivered to the broker not to any of the subscribers. There is no end to end delivery notification (because there may be no subscribers to a given topic).
If you need to know the status of devices then you need to implement this yourself, the usual pattern is to use a status topic with a retained message and the LWT to clear this if the client crashes and setting it manually when it starts up or shuts down cleanly.
Is it possible to simultaneously broadcast my iOS app as an iBeacon and at the same time publish a service?
My app currently advertises a service, which works perfectly fine. My client app (central) is able to find the peripheral, connect, obtain the service and read data from the characteristic. However, if I update my server app (peripheral) to start broadcasting as an iBeacon emitter in addition to the service, I am no longer able to find services that I setup to advertise on the client app (central).
The idea of this is that I want to be able to read information from the server (peripheral) app when in close proximity from the client (central).
Is this technically feasible?
I was thinking about turning off iBeacon transmission when a device comes into close proximity and then starting the service broadcast, but there is no API in Core Bluetooth that calls back to the emitter when a client device enters the region being advertised.
Is this doable? Is there a workaround that would achieve something along these lines? I would like to avoid any networking, as this should be an offline solution.
Taz, For sure you can be an iBeacon and you can look for iBeacons. What I did and what I see other doing is combining iBeacons with other services, such as the CloudKit [which yes, means networking too] to add functionality to their basic functionality.
That said I can imagine an app in which your iBeacons switch to a different protocol when they see each other, the challenge; how-to negotiate a channel/UUIDs for a BLE peripheral/central pair.
I am still in the process of building, but have implemented something similar over the past months... in short you hardcode an initial channel to start your BLE conversation, your first and only exchange on said channel being to agree a new BLE one to use.
For a project I need many clients to subscribe to different hardware devices. In this setup the clients are iOS - Devices. The hardware is something like a raspberry pi but i don't think this matters. This hardware devices send a signal if it measures some kind of information. This is a rare event and possibly could never happen.
Purpose of the app is to warn the user when some kind of event appears in a location he is interested to.
I planed to implement this using the MQTT protocol.
That is where my problem is. To work with MQTT the app needs to send PINGREQ every few minutes even when the app is in background. Also the app needs to receive its subscriptions and handle them immediately.
This is what I planned to do:
Set the "UIBackgroundModes" key in Info.plist to "voip".
Mark the socket as voip socket to wake the app when it receives something
Set the keepAliveTimer:callback: and send the PINGREQ
.. as described here
My questions are: Will Apple allow this? My app is not an VoIP app. If no, are there any alternatives to this approach?
If Apple policies doesn't allow your to put your MQTT client App running in the background, then the solution should be to implement an additional push service.
A push service subscribes to your MQTT broker and sends push notifications to your mobile devices, so that either they have the MQTT client App running or not they will get the events.
Yes!
There is a chance that apple can reject your application when you are using VOIP(even though your app is not a VOIP Kind of application) to keep application alive!
I'm using Location services which is a proper solution to keep application alive in background mode.
Ask permissions to use location services even when the app in background mode & after getting the allow call back,set your location manager's desired accuracy to worst,distance filter to 99999(means your app will be notified if the user travels more than 99999 Meters from last location update call back)
By altering the desired Accuracy and distance filters you can save the user's battery consumption,otherwise your app will consumes lot of energy
That was one proper way which makes your application to run in background for more than 2 days continuously (Already using in our projects).
HTH! Have fun in coding :)
Is it possible to send only 1 iBeacon packet? I have tried using CBPeripheralManager,but since there are only 2 method to start and stop advertising, so I can't control how many packet is being broadcast.
What I want to try to do is use an iBeacon packet as a command, instead of just a broadcasting some ID. So I could send 1 iBeacon packet, and if the receiver got the message, it can send back Acknowledgement with another iBeacon packet. The intention is to avoid the pairing of bluetooth to send very simple data. The information will be linked to UUID, major, and minor of the packet.
Or are there better ways to do this than using iBeacon.
Yes, you can use iBeacon technology to send information back and forth between two iOS devices without pairing. If you have two devices, Device A and Device B, you set both of them up to range for beacons with a common ProximityUUID, say, E2C56DB5-DFFB-48D2-B060-D0F5A71096E0. And then you can exchange information in the two byte major and minor fields.
What you can't do is control the transmitter enough to send only a single iBeacon advertisement. The transmitter in iOS sends out 10 advertisement packets per second, so the best you could do is start the transmitter then stop it on a timer about 100ms later. (You probably shouldn't do this, because there is no guarantee that a single iBeacon advertising packet will be received successfully by the other device -- it may be lost due to a CRC error in the radio noise. You are probably better off letting the packet continue to transmit until you can confirm from a response from the other device that it was received.)
You can see an example of starting and stopping a transmitter on a timer in my answer here.
Of course, there may be easier and more robust ways of accomplishing what you want with built-in Bluetooth data exchange mechanisms. But that doesn't change the fact that what you propose is certainly possible.
No you can't since iBeacon is uni-direction device
I'm currently working with a Corebluetooth, with my phone acting as central, and a separate peripheral.
I'm successfully reading data from a peripheral device using the didUpdateValueFor delegate method. The problem I'm having is when I'm sending multiple packets of information at the same time.
For instance, I send "abc" first and "def" later. As the central updates the reading upon indication from the peripheral, I should be able to get "abcdef" at the end. This works fine if I am sending indications at a speed of 10 packets per second.
However, once my speed gets to the default indication speed, it's too fast for the central to keep up. I only get the first indication "abc", but I never receive the indication for "def".
Is there a way I can force the didUpdateValueFor method to run concurrently so it captures all incoming notifications regardless of speed?
The best-practices chapter of the Core Bluetooth Programming Guide recommends the use of subscription via setNotifyValue:forCharacteristic: rather than plain reads for characteristics that will change often.
It isn't clear from your question as to whether you are using subscription or polling via readValueForCharacteristic:
I think that you mean didUpdateValueForCharacteristic instead of didWriteValueForCharacteristic. Otherwise, the question doesn't seem correct as didWriteValueForCharacteristic can not be used to read data from the remote device (except if you are using error codes for communication - which you shouldn't ;) ).
There are two methods to push data from the peripheral to the central: indications and notifications.
Notifications may be discarded if sent too fast or for whatever reasons.
Indications can only be sent one at a time (you'll have to wait until the central replies with a confirmation that the indication has been processed, before sending another one!).
I see multiple ways how your current implementation may be incorrect:
You are not waiting for the Handle Value Confirmation packet and send the next indication too early.
You are sending indications / notifications before the Client Characteristic Configuration has been written by the central.
Your peripheral has flagged the characteristic to support both notifications and indications. In this case, Core Bluetooth only supports notifications and doesn't enable indications, in which case you are back at unreliable notifications ([CBPeripheral setNotifyValue:forCharacteristic:])
If the specified characteristic is configured to allow both notifications and indications, calling this method enables notifications only.