Non en effet, la présence d’un device n’est pas géré, la présence d’un utilisateur via un device non plus… c’est assez limité pour le moment : niveau de batterie et température si thermomètre… mais ça permet surtout d’ouvrir la voie aux autres services plus spécifiques.
2 « J'aime »
Oups j’ai loupé celui-là. Non je ne sais pas, pas poussé l’investigation sur ce point. Ce qui ne m’empêche pas de le faire. Je vais tout de meme surveiller les évolutions sur la lib et voir intégrer nouvelles features et fixes.
Je vous invite à créer un topic dédié dans la catégorie dev en cas de besoin. Je clos cette feature request pour que les jetons de votes soit libérés.
1 « J'aime »
Je reprend le sujet du bug Bluetooth (tracé dans un topic « Bluetooth: Xiaomi »).
Après quelques échanges, le problème venait d’une image docker custom d’ayant pas le bon paramètre --network=host.
Donc problème résolu.
A savoir que cette information est inscrite dans le README (dans le service Bluetooth).
1 « J'aime »
Ok top bon à savoir !
Est-ce que ça vaudrait pas le coup de mettre un bandeau warning dans le service Bluetooth si ce n’est pas le cas ? (le container n’est pas en NetworkMode=host?)
Pas bête, mais peut-etre en low-effort. Mais on peut garder ça dans la backlog 
1 « J'aime »
Ou désactiver le service si docker et si network n’est pas en mode host
Mm c’est vrai
Une première étape est de communiquer au moins dans l’UI, là actuellement l’utilisateur est un peu perdu.