Vraiment bizarre… j’ai moi aussi testé sur Rpi 3b+, sans souci.
Tu n’as pas un autre Gladys qui fait du Bluetooth sur la même machine ?
Tu es sur que le Bluetooth est up ?
bluetoothclt
> agent on
> power on
pi@gladys:~ $ bluetoothctl
Agent registered
[bluetooth]# agent on
Agent is already registered
[bluetooth]# power on
Changing power on succeeded
[bluetooth]#
Non c’est la seule vm qui use du bluetooth
Dans les échanges sur le github noble, j’ai lu ça
May I sugggest to add a remark in your readme, that BLE adapter will not run when not running your container in host mode ?
En gros, je pense que tu vas devoir changer ton network docker 
En modifiant sur le port 80 par exemple ?
edit, modifier gladys-net par host, je comprends et je test ça
Y’a une histoire de permission (docker) si on veut quelque chose indépendant du network mode, je check ça ASAP
1 « J'aime »
Alors, pas de nouvelles ? Je suis en train de publier la version v4.0.0-bluetooth.4 avec certaines corrections graphiques et du nettoyage au niveau du code.
Je viens de voir l’avancement, vraiment cool !
Au final tu as choisis quelle option pour ta PR?
Déjà de retour ? J’ai choisi l’option “je ne fais pas sans voir avec PG” 
Il manque donc cette partie la.
J’avance en parallèle sur awox Bluetooth pour voir s’il y a des oublis dans la PR Bluetooth, validé que les services dépendants du Bluetooth fonctionnent bien.
Mais noble est rempli de bug, je suis limité à une connexion sur un appareil, apres il est perdu… j’attends une nouvelle version en cours qui permettra de corriger ça.
1 « J'aime »
Yes! De retour de vacances, je répond juste aux messages aujourd’hui, je reprend le travail sur Gladys sérieusement lundi.
Je suis d’accord pour la solution n°2, mais seulement si c’est fait proprement.
A mon avis, ce ne doit pas être un event « générique » qui doit être émit, mais un event différent par service, ce serait trop lourd d’envoyer à tous les services tous les nouveaux périphériques qui sont créé, il faut que chaque service ne reçoivent que les nouveaux périphériques de son service.
ça pourrait être quelque chose genre :
this.gladys.event.emit(`${EVENTS.DEVICE.DEVICE_CREATED}.${device.service}`, device);
Tu en pense quoi ?
Je pense qu’il serait intéressant d’avoir un event générique quand même, car pour le Google Home on pourrait ajouter les nouveaux devices de tous les services automatiquement pour qu’ils soient pris en compte dès leur création, sauf faire d’actions utilisateur.
Donc les 2 types seraient bien !
Tu peux me parler plus du use case Google home ?
Comme tu as pu le voir (je le précise pour les autres) j’ai répondu au use case GH sur le topic GH :
Sinon, pour répondre à ta question si l’état d’avancement, je corrige de petites choses sur le Bluetooth avec l’intégration du sous-service AwoX, mais j’attends surtout des retours des testeurs 
Je pense mettre la PR en revue ASAP, s’il a des changements, ils seront mineurs ou seront intégrés dans une PR d’un sous-service Bluetooth.
1 « J'aime »
Salut !
Chouette chouette cet avancement !
Tu finis l’integration AwoX dans cette PR bluetooth ?
Sinon, je vais essayer de tester quelques devices BT que j’ai !
J’aimerai intégrer les périphériques BeeWi/Otio, comment s’y prendre ?
les objets : prises connectée, capteur d’humidité/température, et ouverture de porte.
Je devrais pouvoir extraire quelques infos sur les UUIDs utilisables et leur fonction. Après comment l’intégrer à un sous-service ? Tu as déjà une idée de template ?
Salut,
Non AwoX a besoin de pages web et d’un workflow tres spécifique, ce sera donc dans un autre PR, mais tu peux déjà t’inspirer ce que j’ai fait pour creer tes propres services “spécifiques”. Ne regarde que la partie awox (le Bluetooth n’étant pas encore sur master, j’ai commencé Awox en partant de la branche Bluetooth).
1 « J'aime »
@AlexTrovato J’ai vu ton boulot sur Github, c’est vraiment top!
Je peux merger maintenant ou tu as d’autres choses à faire dessus?
Pour moi c’est bon pour le moment, même si pas de retour de tests.
1 « J'aime »
Gladys est broken chez moi depuis le dernier build. Le conteneur ne se lance plus.
/src/server/services/bluetooth/node_modules/@abandonware/noble/lib/hci-socket/hci.js:100
this._deviceId = this._socket.bindRaw(deviceId);
^
Error: ENODEV, No such device
at Hci.init (/src/server/services/bluetooth/node_modules/@abandonware/noble/lib/hci-socket/hci.js:100:35)
at NobleBindings.init (/src/server/services/bluetooth/node_modules/@abandonware/noble/lib/hci-socket/bindings.js:78:13)
at /src/server/services/bluetooth/node_modules/@abandonware/noble/lib/noble.js:60:24
at processTicksAndRejections (internal/process/task_queues.js:79:11) {
errno: 19,
code: 'ENODEV',
syscall: 'bind'
}
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! gladys-server@ start:prod: `cross-env NODE_ENV=production node index.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the gladys-server@ start:prod script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2020-10-16T20_07_23_616Z-debug.log
Edit: J’ai créé une issue github pour tracer
Salut ce n’est pas le problème que nous avons constaté avec l’histoire du network du container qui devait etre ‘host’ ?
Tu es bien sous docker ?
Sinon en run manuel, il faut exécuter
sudo setcap cap_net_raw+eip $(eval readlink -f "which node")
Ah mais je suis en host là. ( Docker sur Ubuntu server 20.04 amd64)
Ce matin j’ai tenter de brancher un dongle bluetooth 4.0 , pareil ça crash au démarrage. Sur l’hôte impossible de le détecter, donc c’est peur être pas côté Gladys le problème. Je continue d’investiguer 