J’ai ressorti mon nRF51-DK de la poussière en me disant qu’après deux ans d’absence dans ce projet-là, peut-être que les choses auraient changé concernant le monde mystérieux de l’interfaçage BLE. Je dirais oui et non, car si ça marche un peu plus que dans mes souvenirs, c’est encore plus ou moins sur la coche.
J’utilise bluez 5.50 sur Fedora. Pour une raison obscure, l’interface par défaut de KDE de bluetooth est très aléatoire. J’y vais donc avec le terminal. J’ai commencé par faire un restart : service bluetooth restart, ensuite bluetoothctl pour avoir l’interface de contrôle.
Avec power on et scan on/off, on peut pas mal tout faire.
Donc ce qui est bizarre aussi c’est que mon nRF51-DK doit être nouvellement programmé avec le code. J’utilise celui-ci pour tester l’uart : https://os.mbed.com/teams/Bluetooth-Low-Energy/code/BLE_LoopbackUART/
et j’alterne avec BLE puck juste pour être capable de voir ce qu’il se passe. Donc voici toutes les étapes pour arriver à me connecter avec mon nRF en mode uart. (Avec mbed, on peut compiler en ligne et glisser le fichier hex directement par usb)
power off -> loader le firmware puck ->power on -> scan on -> scan off -> power off -> loader le firmware uart ->power on-> scan on
Ensuite on peut se connecter avec l’interface graphique de bluetooth.
J’ai essayé le code d’Adafruit https://github.com/adafruit/Adafruit_Python_BluefruitLE , mais après beaucoup de gossage (j’ai enlevé le bout du code qui flush la cache pour être capable de voir mon périphérique), il arrive à le trouver et à identifier son UUID comme étant du uart, mais il bogue rendu à device.connect() :
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownObject: Method « Connect » with signature « » on interface « org.bluez.Device1 » doesn’t exist
Donc ça me semble être un bug dans la librairie d’Adafruit. Avec le connect de fedora, il l’enregistre comme un service uart, je ne sais simplement pas comment y avoir accès par la suite.