I’m using an Argon (deviceOS 1.4.0) acting as a BLE central device to connect to a peripheral.
On each of the peripheral device characteristics that have NOTIFY it appears that the BLE.connect function is enabling these notifications.
Our device expects a command sequence on another characteristic before enabling notifications. We have 3 services with NOTIFY capability but generally only one service is used during a connection.
Is there a way to change this undesired behavior and selectively enable/disable Notifications?
Sorry for the delayed response. I was on vacation and just came back to work.
The initial intention of automatically discovering and enabling notification is to simplify the development experience. But we also provide an option for user to manually do this stuff, see: https://docs.particle.io/reference/device-os/firmware/argon/#ble-connect-. If you specify the last argument automatic to be false, then it will only connect to peer device without going further, which means that you need to manually call peer.discoverAllCharacteristics() to discover all characteristics and characteristics.subscribe() to enable the characteristic’s notification.
We currently haven’t provided an API to automatically discover services and characteristics, while not enabling notifications.
Thanks for the response. I eventually dug into the BLE.connect() code and found the automatic flag. I was able to set automatic to false but only after changing the prototype in the header to not set ‘automatic = true’. I then did as you suggest to discover and subscribe to the specific notification of interest.
I think it is better to let the implementor to decide whether to do discovery and enable specific notifications upon connection. Power consumption on a battery operated device can be impacted by doing discovery and turning on all indications/notifications.
I don't think you have to modify the prototype declared in the header file. You can simply override the default automatic value by specifying it explicitly as like BLE.connect(..., false).
So I think this is happening because spark_wiring_arduino_constants.h included by Arduino.h changes the definition of false from a boolean type to an integer, which results in connect(particle::BleAddress&, int) which is what the ambiguous message is all about.
Thanks for helping to isolate the source of the problem, I cast false to a (bool) as you suggested in BLE.connect and can compile clean. I’m using a number of libraries that require Arduino.h … I wonder if those true / false constants in spark_wiring_arduino_constants.h can be removed but I don’t know the Arduino history and why they are there. As a test, I commented them out of spark_wiring_arduino_constants.h and cleaned compile with the libraries I’m using and don’t need to cast false in the BLE.connect call.