search

LEGO / lego-ble-wireless-protocol-docs

This repository contains information about LEGO Hubs (name, battery level, etc.) and to interact with any sensors and motors connected to it.
https://lego.github.io/lego-ble-wireless-protocol-docs
MIT License
334 stars 43 forks source link

Hub Attached IO init messages too fast #29

Open tthiery opened 3 years ago

tthiery commented 3 years ago

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 commented 3 years ago

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.