Following an exchange with the creator of Theengs / OpenMQTTGateway, a gap was identified: Gladys does have a Bluetooth integration, but it only covers a handful of devices — whereas the ecosystem of BLE sensors (temperature, humidity, plants, etc.: Xiaomi, SwitchBot, RuuviTag…) is enormous, and projects like Theengs can decode hundreds of them.
For me, this needs to be done through an external integration, not through code in the core. But today, the external integration framework does not provide access to the machine’s Bluetooth, and for good reasons: unlike a Zigbee key (a simple USB device that can be mounted in the container), giving a container access to Bluetooth implies giving it very broad network privileges on the machine, which is incompatible with the store’s security model (third-party integrations that are not audited, installable with one click).
The envisaged approach: a Bluetooth mediator access, on the same model as the network discovery already in place, the core listens to the radio and relays the raw frames, the integration decodes them and publishes sensors and states via the existing APIs. The adapter remains under the control of the core, which will in any case be indispensable when we do Matter/Thread commissioning in BLE.
Note: for those using ESP32 gateways with OpenMQTTGateway, an external integration is already possible today via MQTT, without changing anything in the framework.
The issue here is the use of the Bluetooth adapter of the machine running Gladys.