Comme le dis Rpi, sans avoir la même config matérielle, cela risque d’être difficile.
Pour ma part, je sais que l’intégration matériel dans du docker peut s’avérer complexe dans certain cas (orchestrateur).
Tu utilises le logciel du synology pour lancer ton conteneur je suppose ? As tu essayé en mode overlay ?
Pourquoi ? cela afin de savoir si le fait d’être en mode host (ou cela fonctionne) en mode macvlan ou en mode overlay change quelque chose. Au final, tu bluetooth à besoin aussi d’une adresse mac pour fonctionner. Ne serais-ce pas lié ?
Non.
Docker compose en ssh
Ah !!! Dans ce cas, il faudrait que tu vérifie un petit truc.
Est-tu certains que tu mappes le bon devices à chaque redémarrage. Je m’explique, avec compose etc… il peux arrivé (surtout avec un hub) que le numléro de mappage oit différent. En effet, la numérotation est fonction de la détection du matériel et peux, parfois changer. D’où le fait que tu cherches à mapper un device qui en fait, n’existe pas.
As tu vérifiez à chaque fois la numérotation ?
Sinon, il y a un truc qui m’interpelles également.
Le privilieged: true. Il me semble que ça pose problème pour les device aussi. Je crois que j’avais un soucis avec ça, il me semble. Essaye de virer le privilieged pour voir.
Bonsoir @Gsyltc
Le privilieged ne change rien
j’ai fait des test avec la clé usb bluetooth seule
Quand je parcours le web, on lit toujours la m^me chose
Passez le conteneur en mode HOST
Ou une autre solution, c’est de creer un mini conteneur en mode Host rien que pour la clé
https://forum.jeedom.com/viewtopic.php?f=157&t=24980&sid=1e44d1f0f59819a1afa73fdb297af6c1&start=80
Ok pour privilieged. C’était jsute pour être sur. De plus, normalement le mode privileged ne t’oblige pas à mapper le device, il te donne accès a tout, device compris.
si tu fais un docker run -dit --privileged -p XX:XX image:tag, tu verras ton device sans avoir besoin de le mapper. Le problème c’est que tu donne accès à tout dans ton conteneur. et ce n’est pas safe.
Après pour l’obligation d’être en mode host, je ne suis pas d’accord. tu peux mapper des devices sans être en mode host.
As-tu essayé de lancer avec un commande docker normale ? juste comme cela
docker run -dit --device /dev/ttyUSBX -p XX:XX image:tag ?
vois tu ton bluetooth ?
Bonjour @Gsyltc
Mon problème est la …
Mon conteneur n’est pas en Host
Donc on en revient à mon message initiale …
Tu me demandes de faire une commande
docker run -dit --device /dev/ttyUSBX -p XX:XX image:tag ?
oui mais quel USB ? puisque je ne vois pas ma clé Bluetooth …
Attends il y a un truc que je pige pas.
Sur ton hôte (le syno), tu vois bien ta clé non ? C’est dans le conteneur que tu ne la vois pas ? Du moins, c’est ce que j’ai compris au fil des messages.
la commande étant à lancer sur l’hôte (en ssh par exemple), c’est l’usb de l’hôte qu’il faut mettre
J’ai exactement le même soucis que j’essaie de résoudre depuis plus d’une semaine … sans succès !
- soit je crée mon conteneur en mode « host » avec privilèges et je mappe « /dev/bus/usb » et ça fonctionne, mais mon conteneur n’est plus accessible via une IP distincte avec tous les problèmes que ça pose, de plus le SSH ne fonctionne pas,
- soit je crée mon conteneur en bridge ou en macvlan, mais je ne peux plus accéder à la clé USB Bluetooth
Pour résumer, les clés Bluetooth USB ne ‹ montent › pas de périphérique virtuel du style « ttyUSBx » dans /dev/
D’après ce que j’ai compris, le driver xhci qu’elles utilisent fait que le Bluetooth est plutôt considéré comme une sorte de carte réseau que comme un périphérique USB classique.
C’est probablement là que le bas blesse, car du coup on ne sait pas comment mapper ce périphérique vers le conteneur Docker 
Si quelqu’un a une solution QUI MARCHE, je suis preneur également 
Si ta clé Bluetooth USB te sert pour le plugin BLEA regarde ici
1 « J'aime »
Ha, merci, je vais tester ça
Donc ça fonctionne, j’ai accès en ligne de commande au SSH, ainsi qu’à la clé USB Bluetooth (« hcitool scan » et « hcitool lescan » par exemple me renvoient des appareils).
Par contre, dès que je veux utiliser la fonction d’antenne, tout se passe bien, pas d’erreur à l’installation des dépendances via mon Jeedom principal, le module distant fonctionne et répond, l’antenne passe au vert dans le Jeedom principal, aucune remontée d’erreur dans le log, bref tout semble bon … mais aucun périphérique BT ou BLE ne remonte via l’antenne BT, même plusieurs heures après.
J’ai rebooté le Syno hôte de Docker, mais pas mieux.
Nota : petite erreur dans ta commande docker-compose build pour créer l’image, indiquée dans le milieu de ton post. C’est « docker » tout court qu’il faut utiliser.
En passant, pour lui donner un nom parlant, on peut faire docker build -t jeedom/antenne-bt:1.0 . (ne pas oublier le « . » au bout), sinon l’image apparaît sans nom, juste avec son ID.
Désolé, je poste ici car l’autre topic est verrouillé.
Ton jeedom est également installé sur ton syno en docker ?
Non, mon Jeedom principal est sur un véritable RPi (un 3b+) qui ne sert qu’à Jeedom.
Uniquement l’antenne est dans un conteneur Docker hébergé sur mon Syno (en fait un XPenology installé sur un Intel Core i3 fanless).
La case que tu indiques en screenshot n’est pas cochée chez moi. Il faudrait donc la cocher ?
Je n’ai pas trouvé à quoi elle sert dans la doc ?
Si tu as un Jeedom sur rpi dans ce cas tu peux laisser cocher
Cela sert à désactiver l’écoute Bluetooth sur le Jeedom local
Si tout est au VERT et que ton syno snif en Bluetooth alors je ne comprends pas ce qui se passe
1 « J'aime »
Merci bien pour les explications sur la case à cocher
Sinon, j’ai avancé : en fait, ça fonctionne. Je ne m’en suis pas rendu compte plus tôt car il faut que j’approche mes équipements BT/BLE bien plus proche de la machine qu’avant, sinon je n’ai pas de détection : ça ne traverse même plus une cloison de placo standard.
Je ne sais pas trop pourquoi, mais on dirait que ça ne reçoit qu’une petite partie des trames BT qui passent. C’est comme si mon dongle Bluetooth portait un masque FFP2 
Probablement à cause de Docker sur un Syno DSM : même si j’ai désactivé la gestion du Bluetooth dans DSM, j’imagine que ça doit malgré tout scruter un peu quelque part et donc que ça perturbe l’écoute par le plugin antenne Jeedom.
Pour être sûr, il faudrait que je fasse une installation de Linux pur (pas le DSM de Synology donc), puis que j’installe Docker, et que je refasse mes images et conteneurs, mais bon, j’ai franchement pas le temps 
Donc un énorme merci pour ton aide et pour ce tuto sur la création d’un conteneur fonctionnel en SSH 
PS : penses à corriger dans ton tuto la commande de création de l’image avec
docker build -t NOMDELIMAGE .
au lieu de « docker-compose build » 
1 « J'aime »
Bon, en fait, je me rend compte que dès qu’on désactive la gestion du Bluetooth dans l’interface DSM du Syno, le simple fait de faire un « hciconfig hci0 up » la réactive et elle passe en « pscan », donc c’est totalement inutile.
Du coup, c’est probablement la cause des perturbations du BT.
Sur mon Syno le Bluetooth est activé. je n’y touche pas
Pour la portée de reception, j’avais également ce problème.
J’ai acheté une clé SENA Dongle USB Bluetooth longue portée UD100-G03
et une antenne
https://www.amazon.fr/gp/product/B07PJ6HYWT/ref=ppx_yo_dt_b_asin_title_o07_s00?ie=UTF8&psc=1
Je capte dans toute la maison 
Merci pour la correction du tuto … je fais la modif
Oui j’ai la même, comme beaucoup de gens du forum je pense
En fait j’en ai même acheté deux car la maison est de plein pied et une seule était un peu juste : j’ai mis une clé sur un RPi à chaque bout de la maison et là ça va bien, je capte même nos smartphones à plus de 50m de la maison 
Mais pour mes tests, j’ai utilisé une clé Trendnet qui marche pas mal aussi (classe 1 également et tiers du prix de la Sena), c’est pourquoi je ne me suis pas méfié du coup de la portée, j’étais trop habitué à ce que ça capte de partout.
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.