Suite à un échange avec le créateur de Theengs / OpenMQTTGateway, un manque a été identifié : Gladys a bien une intégration Bluetooth, mais elle ne couvre qu’une poignée d’appareils — alors que l’écosystème des capteurs BLE (température, humidité, plantes, etc. : Xiaomi, SwitchBot, RuuviTag…) est énorme, et que des projets comme Theengs savent en décoder des centaines.
Pour moi, ça doit passer par une intégration externe, pas par du code dans le core. Mais aujourd’hui, le framework d’intégrations externes ne donne pas accès au Bluetooth de la machine, et pour de bonnes raisons : contrairement à une clé Zigbee (un simple périphérique USB qu’on peut monter dans le conteneur), donner l’accès Bluetooth à un conteneur implique de lui donner des privilèges réseau très larges sur la machine, incompatible avec le modèle de sécurité du store (des intégrations tierces non auditées, installables en un clic).
La piste envisagée : un accès Bluetooth médié, sur le même modèle que la découverte réseau déjà en place, le core écoute la radio et relaie les trames brutes, l’intégration les décode et publie capteurs et états via les API existantes. L’adaptateur reste sous le contrôle du core, ce qui sera de toute façon indispensable le jour où on fera du commissioning Matter/Thread en BLE.
À noter : pour ceux qui utilisent des passerelles ESP32 avec OpenMQTTGateway, une intégration externe est déjà possible dès aujourd’hui via MQTT, sans rien changer au framework.
Le sujet ici, c’est l’utilisation de l’adaptateur Bluetooth de la machine qui fait tourner Gladys.