lego-ble-wireless-protocol-docs icon indicating copy to clipboard operation
lego-ble-wireless-protocol-docs copied to clipboard

Hub Attached IO init messages too fast

Open tthiery opened this issue 3 years ago • 1 comments

When the GATT device is connected, the characteristic instantly receives a series of Hub Attached IO messages with the purpose of declaring the internal devices of the hub and the currently connected devices. This is basically awesome for setting up the protocol state, however, in some environments (Chrome WebBluetooth) it is (to my experience) impossible to register the notification handler before the hub shoots their notifications. I am successfully doing and relying on that in my .NET/WinRT environment (which assumingly is just a bit closer the actual BLE stack than Chrome/WebBluetooth). IMHO, the existing JavaScript libraries are not relying on these information but instead utilize cached/hardcoded knowledge.

Can I/we hereby request a message which can explicitly trigger this initial Hub Attached IO dump/discovery/scan? Maybe in the general request/response pattern exposed in the LWP, this could be named "Hub Attached IO Request".

The alternative to hardcode or query a "Port Information Request" per imaginable number which would take too long and would not expose the IO Type.

tthiery avatar Sep 05 '20 19:09 tthiery

Just a short update: My StackOverflow question on this topic was filed as an issue with the WebBluetooth working group. Worthwhile read also in context of this request.

Issue is still in the protocol and not the stack / API.

tthiery avatar Sep 09 '20 19:09 tthiery