Ajouter le bluetooth à Gladys 4

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” :slight_smile:
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 Like

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 :slight_smile:

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 Like

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 ! :slight_smile:

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 Like

@AlexTrovato J’ai vu ton boulot sur Github, c’est vraiment top!

Je peux merger maintenant ou tu as d’autres choses à faire dessus? :slight_smile:

Pour moi c’est bon pour le moment, même si pas de retour de tests.

1 Like

:star_struck:

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 :confused:

Je lèverai un ticket sur le github de la lib, mais week-end famille, pas d’avoir beaucoup de dispo

Mince, je viens de voir ton message!

Ca a crashé direct sans action de ta part? Tu es sur quel hardware exactement ?

Je fais tourner un Gladys sur Ubuntu server aussi, et je n’ai pas eu le problème. Il y a une erreur au démarrage mais qui ne fait pas crasher Gladys.

Il faudrait trouver un moyen de bétonner le code du core pour que ce genre de soucis n’affecte pas l’instance Gladys entière. J’ai déjà une todo en attente avant la RC qui est d’ajouter un listener sur le unHandledPromiseRejection error pour catcher les promises en erreur, mais ici j’ai plus l’impression que c’est un crash système impossible à catcher en node, je me trompe @AlexTrovato?

@pierre-gilles en effet j’ai l’impression qu’on est dans un cas non catchable. J’ai monté un ticket sur le github de noble pour savoir si on sait comment gérer ça.
Sinon je pensais faire un système dans Gladys, un paramètre qui dit si le démarrage du service s’est bien passé, sinon, au restart, “ignorer” le service, quitte à faire une page pour “forcer” le redémarrage du service. Et si ça plante à nouveau, recommencer ce process (changer le param de service pour dire que le chargement n’a pas réussi…).

Bonne idée ça ! ça nous éviterait bien des problèmes, parce que là potentiellement si un utilisateur novice avait le même bug que @VonOx, il aurait pas pu s’en sortir sans mettre les mains dans le cambouis (Watchtower ne met à jour que les containers qui tournent, pas ceux qui restart en permanence. En d’autres termes, si on fait crasher une version de Gladys, l’install de tout le monde est brické…).

Une autre option auquel je pensais (en complément de ton idée), c’est de faire tourner toute la partie services dans un worker node, on aurait donc un worker principal qui ferait la partie lib/API, et un worker secondaire pour les services. Après c’est un gros chantier donc c’est plus une idée “future”

Je ne suis pas contre un worker différent, mais à ce moment la, il faudrait voir même 1 worker par service.
En revanche, dans les 2 cas, c’est du boulot, mais je pense me pencher ASAP sur la première option, mais je ne suis pas capable de te donner un planning.
Si tu prends le sujet, préviens moi, qu’on se bosse pas en double, même si je pense que tu as bien d’autres tâches.

Aucune, watchtower a fait la mise à jour et crash

L’hôte n’a rien d’exotique, c’est un server Ubuntu 20.04 Xeon x64, pas de Bluetooth. J’ai que du docker dessus + Plex.

Je m’en suis rendu compte quand j’ai voulu géré mes hue car gladys plus m’affichait un dash vide ( d’ailleurs y’a un manque d’info si l’instance n’est pas up)

J’ai pas encore essayé de recréer le conteneur, je tente ça demain.