Retrieve paired host information for reconnection

[Mitch Cairns]

I'm using Pico SDK with BTStack. My question is straightforward

I pair my device (HID Gamepad) to a host. On the next initialization (reboot), what is the most straightforward way to retrieve the host information? I know BTStack stores a Link key, but I'm having trouble finding sample code on how to perform this process. If I need to just store the host address on my own terms that's fine but if there's a built in method that would be preferred. 

The end goal, of course, being to re-connect to the host or attempt reconnection. 

As an aside, will gap_delete_all_link_keys suffice to actually clear any paired hosts? 

Thank you,

Mitch

[Mitch Cairns]

Actually, now that I'm digging into it more, it's not clear that the device is storing anything on its own currently. When I go through a reboot and try to reconnect to a Windows host, it just hangs and never connects. I appreciate any insight on this.

[Matthias Ringwald]

Hi Mitch

To reconnect to a previously paired device, you can either iterate over the list of stored link keys, or, explicitly store the last used device in BTstack's persistent storage with the btstack_tlv.h API. In most cases, its probably better to store the last connected device.

To iterate over stored link keys, you can check out the gap_link_keys.c example.
The hog_host_demo.c, uses btstack_tlv to store and retrieve the last connected device.

if you have questions about stack behaviour, please always post an HCI packet log with ENABLE_LOG_INFO but without ENABLE_LOG_DEBUG. Please see pico-example/pico_w/bt/README.md

Cheers
Matthias

> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/btstack-dev/51c30b09-789d-4a0e-82dd-d91c96339850n%40googlegroups.com.

[Mitch Cairns]

Thank you for that response-- 

That makes a bit more clear that wasn't prior. the tlv api is strictly for storing arbitrary data. In my situation that's not necessary as I have a proprietary configuration dataset. 

What still is not clear to me is if I need to perform any particular different action to initiate a connection with a bonded host. In my test setup, when I use hid_device_connect with an appropriate host address (Nintendo Switch), I'm able to reconnect without much fuss. It's just Windows where I'm having this problem. 

Am I understanding correctly that once BTStack connects to a device, a link key is stored and no additional action is required on my part? Or am I misunderstanding this? I just want to make sure that I'm doing a proper implementation before I tear any hair out

[Matthias Ringwald]

Hi Mitch

Assuming BTstack is properly set-up (no reason to think otherwise yet..) and bonding is enabled (which it is by default), BTstack will automatically take care of link keys (store them, fetch them, etc...)

Can you try the hid_keyboard_demo for comparison to see if that one works with Windows as expected? If not, please get a HCI log. The console output can be converted into a .pklg file for Wireshark with tool/create_packet_log.py which helps to understand what's going on.

Best
Matthias

> To view this discussion visit https://groups.google.com/d/msgid/btstack-dev/5d5d4215-b693-40cc-90b0-cd5b5d451274n%40googlegroups.com.

[Mitch Cairns]

I will have to see if I can get the HCI log. The hid_keyboard_demo as compiled from pico_examples is not set up to connect on a fresh boot to its previously paired host. I think a modified example would be needed, I'll see what I can do tomorrow

Thanks,

MItch

[Matthias Ringwald]

Hi Mitch

That's true. However, there should be no difference between manually triggering the connect and doing that after receiving BTSTACK_EVENT_STATE with state HCI_STATE_WORKING

Cheers
Matthias

> To view this discussion visit https://groups.google.com/d/msgid/btstack-dev/21191e8b-fdfd-44c2-b80e-16a88683f458n%40googlegroups.com.

[Mitch Cairns]

Hi Matthias,

Is it best practice to initiate the HID connect function after receiving the HCI_STATE_WORKING event? I may be misunderstanding your message there. Or is it in that specific example, the disconnect+keystroke+that event results in a reconnect?

Thanks
Mitch

You received this message because you are subscribed to a topic in the Google Groups "btstack-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/btstack-dev/CACMFMCKEDg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to btstack-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/btstack-dev/262C36C8-EC54-433D-AF32-F90079607B1C%40gmail.com.

[Mitch Cairns]

It seems that only calling the hid_device_connect function within the BTSTACK_EVENT_STATE handler where HCI_STATE_WORKING is the state has resolved my particular issue. I'm now able to reconnect to Windows without much fuss. 

I can only assume that the HCI state is not fully set up/initialized if you try to call hid_device_connect too early or something along those lines. 

Thank you for that pointer, it helped me understand a bit where to look. I think that an example demonstrating saving/loading addresses for the hid_keyboard would be extremely useful. Or even a basic HID device that demonstrates all of these functions together. I think for an HID device that is the most typical use case anyways (re-connect to last paired host on boot)

[Matthias Ringwald]

Hi Mitch

It's recommended to start Bluetooth communication after the HCI_STATE_WORKING. BTstack tries to track user requests, e.g. gap settings, but we cannot guarantee that.

Good idea about extending the HID Keyboard & Mouse Demos.

Cheers
Matthias

> To view this discussion visit https://groups.google.com/d/msgid/btstack-dev/CALr4rgUhbnLQD8vMHb6EPne89racky9cHNSnaw8Tx_NgF4jGZQ%40mail.gmail.com.