I would like to know what is the key difference between firebase multicast send and device group send? What are the use cases where in we can use multicast send and device group send?
A device group can contain up to 20 separate device tokens. It is typically used for address a set of devices of the same user. Note that device groups are only exposed on the legacy API, and not in the newer versioned API of Firebase Cloud Messaging.
Multicast messaging can be used to send a message to 100-500 (depending on the platform) device tokens at a time. For an example of this, see send messaging to multiple devices and sending a batch of messages in the documentation.
Related
I have a BLE device that doesn't respond to SCAN_REQ and am working it out with the vendor independently per https://github.com/espressif/esp-idf/issues/10660.
When I use Nordic nRD Connect iphone app as a client I can see that device in the scan list and can connect to it. However, when I use a different client, a python Windows one, that client doesn't show the device in its scan list and doesn't connect to it if I specify the exact address.
My question is, are BLE 4 devices required to respond to SCAN_REQ requests to be discoverable and connectable or is it just optional response to provide additional advertisement data?
EDIT, I believe that Emil's answer below (thanks) refers to this quote
Yes, it's required to reply with a scan response. That is defined in Bluetooth Core v5.3, Vol 6 Part B (Link Layer), section 4.4.2.3, using the word "shall".
There is one exception though. There is a Filter Accept List in the controller which can contain addresses of centrals allowed to scan and/or connect. There are four combinations the host can set (advertising filter policy) that control if this list shall be used for filtering incoming SCAN_REQ and CONNECT_IND packets, respectively. If you don't use this filtering mechanism, then the device must send a scan response to every scan request.
There are two possible approaches to scanning—Passive Scanning or Active Scanning.
Passive Scanning is when Scanners receive advertising packets and process the contents.
In the case of Active Scanning, however, a device may decide it wants to know more about an advertising device and respond to the initial advertising packet by sending a Scan Request GAP protocol data unit (PDU). This basically means ‘Tell me more.’ The device receiving the Scan Request can send back a Scan Response PDU with more information, once again in the form of a collection of AD types.
The above has been extracted from: https://www.bluetooth.com/blog/advertising-works-part-1/ [the emphasis mine].
As described, BLE Scanner can not know the advertising channel.
How to get BLE advertising channel index number
But, in the link below, at first graph,
the Initiator send the CONNECT_REQ to the Advertiser through Ch.38 which is used to send ADV_IND.
it is something like that the Initiator knows which the advertising channel is used.
https://microchipdeveloper.com/wireless:ble-link-layer-connections
Can Scanner know the advertising channel?
The scanner of course knows which advertising channel is being used. It's just that it's not part of the Bluetooth Specification to expose this information to an application using the Bluetooth stack. In particular, the HCI events for advertisements do not contain such a field. It is possible though that some embedded devices can expose this info to the application, if they have defined a custom API for this.
How do I implement notification in BLE?
I have a smartphone, and every hour it will send notification to all nearby BLE devices (smartwatch, RFduino, etc) for time synchronization purpose.
Other devices are server now (since it provides data), and smartphone is the client that collect the data.
Could I piggyback into the advertisement packages? For example, the smartphone always broadcast an advertisement packet to annoucement its presence (that's how other devices can find it). Can I modify that packet to be a time sync?
In order to send notifications or advertisements, your smartphone has to act as a server, which also means that in order to be able to receive notifications or scan for advertisements, your peripheral devices must act as clients.
This can be a bit tricky, because if two devices act as client and server, they may not simultaneously fulfil the other role. You need to switch roles whenever needed, which is an open field for all kinds of problems.
Also, I am not convinced that it is really the optimal choice to let the smartphone regularly notify all devices in the vicinity. Each of the devices that wants to receive the notification has to be connected with the device in order to receive the notification, and this connection has to be already active when the notification is sent in order to really get the correct time. So all these devices need to connect in advance to the expected notification time, and hold up the connection until the notification has come.
It might be better to just advertise the current time, but remember that you can't connect to the smartphone as a server while it is advertising, because the link layer may not be in scanning and advertising mode at the same time, and you may also not be connected when advertising for a similar reason.
If you want to do it that way, you can include the time information in the advertising data. See the Supplement to the Bluetooth Core Specification v6, Part A for further information on the structure of the advertising data. You could put it in the manufacturer specific data.
However, another option would be to write the time directly to the device using a write request. You can define your own service and characteristics. You can include a "time synch necessary" information in the advertisement data of the servers, and when the smartphone evaluates the advertisement, it can connect to the corresponding device and send the time directly.
The advantage of this procedure is that time is only updated if you really need it on the device, and that you do not have to switch client/server roles, because the device in server role may advertise as normal, and the smartphone can always stay in client role.
I have a device which has a settings on it.
The device is uploading data to the cloud.
In the cloud I have settings of the device that I want to do a smart way to update the device settings, but still leave the device the master and stateless. I mean that every request shall come from the device towards the cloud and NACK/ACK will come back to the device.
Currently what we do is to put a command in the database to send to the device according to its serial number. when the device pings to the server, it gets the message with the update. But I do not want to wait for the ping of the BSS. How can I notify the device that a message is waiting for it ?
How do Apple does it with icloud settings to the devices ?
Thanks
Look at the MQTT protocol. This is being promoted by Amazon for IOT devices, and a broker (message router) is available from Amazon. The protocol uses a publish and subscriber model. The devices subscribe to their "topic" something like yourcompany/todevice/serialnumber, and when the server publishes to the same topic, the MQTT broker delivers the message. the messages normally use JSON protocol.
Is there any way to initiate an SMS MO from a device from the network. Eg: Can I send a special USSD push to a device from the network so that it will SMS a specified text to a specified number from the device.
Only if you are the network operator and the USSD message is defined in the network and supported by the device.
You could also send a MT SMS and get the specified text as a reply (again supported on the device, obviously).
This largely depends on the device capabilities. The device needs logic for processing the USSD message, instead of just displaying it, and to trigger sending the MO SMS.
Since this is not a factory configuration, you would need a custom application to be installed on the device, provided that the device platform allows for the needed functionality. For example some J2ME-capable devices do have this functionality. Consult your device manufacturers development documentation.