BLE Pairing/Bonding (and Http)

Will the BLE support ever be improved to include bonding and improved pairing/handshake/encryption?

I've had multiple projects that would benefit from this, many devices just can't be paired with properly such as cameras.

I am aware of the companion app option, but that defeats the purpose of not having to have a phone with you.

Also will there ever be http support (not https)?

Without this you can't hit endpoints local networks and you are reliant on the internet which can be very unreliable, especially in the backcountry.

  • Toybox.BluetoothLowEnergy was never meant to be more than minimal and specifically for accessing a new sensor.  When the Garmin folks heard I was using it to talk to a Raspberry Pi, they were surprised as it wasn't something they had planned, and I was asked to do this blog post:
    https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/would-you-like-some-raspberry-pi-with-your-connect-iq

    I've implement some security since them but I did it on the pi end. 

    There are some interesting restrictions, such as the Garmin end can only read at most 20 bytes at a time.  The Garmin end can't always see things like the UUID in the advertisement.  You must hard code the BLE profile in your app, and you can use at most 3 services.

    Long story short, is after all this time, I don't think anything will change.

    As far as http and https, the https requirement came about due to the phones (which act as a proxy) requiring https.  This became visible with the 4.20 version of GCM.  You can still use http, but only to 127.0.0.1/localhost (a server on your phone)

  • It's really time for Garmin to implement support for bonding / SMP in BLE. This requirement has been around for several years (forums.garmin.com/.../toybox-bluetoothlowenergy---does-it-support-bonding-with-smp-encryption ). For example, since Garmin is unable to bring the blood pressure monitor BPM Smart Blood Pressure Monitor onto the market in Europe, we need alternatives: for example the OMRON HEM-7600T-E Evolv. Jeed is absolutely right that the lack of support for bonding hinders the development of meaningful projects. I know jim_m_58's PI project. I really like the queue solution. I have already used this successfully with e-bike connections. But in general, I'm seeing more and more Bluetooth devices that require a permanent key exchange via pairing request: that's BONDING! For this purpose, profiles no longer have to be defined, but GARMIN must implement the SMP protocol. This function must be implemented within BLE and cannot be outsourced to the external device. Therefore, the reference to the PI Project is not helpful in this case! I am convinced that Garmin is deliberately blocking this so that no applications are created that are ahead of their own developments: e.g. Blood pressure measurements, camera applications etc.

  • It's really time for Garmin to implement support for bonding / SMP in BLE. This requirement has been around for several years (forums.garmin.com/.../toybox-bluetoothlowenergy---does-it-support-bonding-with-smp-encryption ). For example, since Garmin is unable to bring the blood pressure monitor BPM Smart Blood Pressure Monitor onto the market in Europe, we need alternatives: for example the OMRON HEM-7600T-E Evolv. Jeed is absolutely right that the lack of support for bonding hinders the development of meaningful projects. I know jim_m_58's PI project. I really like the queue solution. I have already used this successfully with e-bike connections. But in general, I'm seeing more and more Bluetooth devices that require a permanent key exchange via pairing request: that's BONDING! For this purpose, profiles no longer have to be defined, but GARMIN must implement the SMP protocol. This function must be implemented within BLE and cannot be outsourced to the external device. Therefore, the reference to the PI Project is not helpful in this case! I am convinced that Garmin is deliberately blocking this so that no applications are created that are ahead of their own developments: e.g. Blood pressure measurements, camera applications etc.

  • See the System 7 announcement

    "API 5.0.0 devices can also pair with BLE devices using Just Works pairing. The system will remember the bonded devices and allow you to reconnect with devices you have previously bonded with."

  • Thanks for the information.

    The solution shown in API 5 means that older devices e.g. Forerunner245 will not benefit from it. The BONDED reminder function means that the BLE server and client must have gone through the BOND process at some point.

    How can I imagine this between a device e.g. Venu2 and a sensor e.g. blood pressure monitor?

    The specific question is, will there be functionality like this example:

    Action: Toybox.BluetoothLowEnergy.BOND_STATE_CHANGED, bond state changed to: BOND_BONDING (11) Action: Toybox.BluetoothLowEnergy.PAIRING_REQUEST, pairing variant: PAIRING_VARIANT_CONSENT (3) Action: Toybox.BluetoothLowEnergy.PAIRING_REQUEST, pairing variant: PAIRING_VARIANT_CONSENT (3) Connection parameters updated (interval: 22.5ms, latency: 0, timeout: 2000ms) Action: Toybox.BluetoothLowEnergy.BOND_STATE_CHANGED, bond state changed to: BOND_BONDED (12) Toybox.BluetoothLowEnergy: Device bonded.

    Maybe I didn't understand something.

    I'm looking forward to your answer.

    Thanks again!

  • The change log for the System 7 beta has this:

    • Add new BLE APIs to support bonded connections (not currently supported in simulator).

    Per the System 7 announcement,

    Get the SDK

    The System 7 SDK beta is available today from the SDK Manager. You can try the new features using the epix2pro47mmsystem7preview device. If you have signed up for the device beta program, you will get beta firmware in January.

    ---

    And only devices that get System 7 will have it.  And only devices that have CIQ 4.2.x will get System 7.  Devices like the fr245 are pretty old, at end of life and probably won't be getting any non-critical firm wear updates at this point