Je veux bien, mais je ne sais pas annuler ; SOLUTION
Bonjour
J’ai hésité à ouvrir un nouveau sujet car ma clé SENA est en local, mais je rencontre un problème très similaire
Ma configuration :
- NUC 6I5SYK
- VMWare ESXi 6.7.0 Update 3 (Build 14320388)
- Clé USB : SENA UD100
- Jeedom : 4.3.19
- Plugin TGW : Version 2023-11-16 01:20:01 (Info pour mémoire, le plugin n’ayant aucun lien avec le problème rencontré)
Cela fait quelque temps que j’ai basculé de BLEA vers Theengs gateway, en utilisant la même clé SENA (depuis des années) sur le même port USB de mon NUC.
HIer (21/11), je constate que les informations de tous mes NUT et boutons SHELLY ne sont plus remontées (rssi 200)
Exemple :
Mes deux ESP32 pour le coup sont d’un bon secours
Rien dans log Tgw_775 en mode defaut
Le service est détecté en ligne par le plugin TGW
Plus de remontée dans MQTT Explorer
Arrêt et redémarrage de l’antenne, après avoir mis les log en debug :
LOG TGW :
[2023-11-21 23:06:07][DEBUG] : local exec:hcitool dev | grep hci =>
[2023-11-21 23:06:10][INFO] : Arrêt de l'antenne 'Sena'
[2023-11-21 23:06:10][DEBUG] : Listening to topic:'tgw'
[2023-11-21 23:06:10][DEBUG] : local exec:sudo systemctl stop TheengsGateway.service =>
[2023-11-21 23:06:10][DEBUG] : handle Mqtt Message:{"tgw":{"775":{"LWT":"offline"}}}
[2023-11-21 23:06:10][INFO] : LWT update:offline
[2023-11-21 23:06:16][INFO] : (Re)Démarrage de l'antenne 'Sena'
[2023-11-21 23:06:16][DEBUG] : Listening to topic:'tgw'
[2023-11-21 23:06:16][DEBUG] : local exec:sudo systemctl restart TheengsGateway.service =>
[2023-11-21 23:06:16][DEBUG] : handle Mqtt Message:{"tgw":{"775":{"LWT":"online"}}}
[2023-11-21 23:06:16][INFO] : LWT update:online
Toujours pas de remontée dans MQTT
J’exécute la commande préconisée par @prfalken : sudo dmesg | grep Bluetooth
[ 7.988513] Bluetooth: Core ver 2.22
[ 8.007513] Bluetooth: HCI device and connection manager initialized
[ 8.007518] Bluetooth: HCI socket layer initialized
[ 8.007520] Bluetooth: L2CAP socket layer initialized
[ 8.007529] Bluetooth: SCO socket layer initialized
[ 8.476200] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 8.476203] Bluetooth: BNEP filters: protocol multicast
[ 8.476207] Bluetooth: BNEP socket layer initialized
[3201337.427916] Bluetooth: hci0: command 0x2005 tx timeout
[3201337.429331] Bluetooth: hci0: unexpected event for opcode 0x2005
Vérification sous ESXi
Je retourne dans la gestion de mon antenne TGW :
Je modifie le paramètre adaptateur (ce qui est très probablement inutile) : voir copies écrans suivantes
Je lance une installation d’antenne puis démarrage service : c’est ok
LOG TGW
[2023-11-21 23:15:09][DEBUG] : local exec:hcitool dev | grep hci => hci0 00:01:95:39:8D:70
[2023-11-21 23:15:50][DEBUG] : adapter changed
[2023-11-21 23:15:50][DEBUG] : Listening to topic:'tgw'
[2023-11-21 23:15:50][DEBUG] : Informations reçues de mqtt2: {"ip":"127.0.0.1","port":"1883","user":"jeedom","password":"xxxxxxxxxxxxx"}
[2023-11-21 23:15:50][DEBUG] : local exec:echo '{"adapter":"hci0","discovery_filter":["IBEACON","GAEN","MS-CDP","APPLE_CONT","APPLE_CONTAT"],"discovery_device_name":"Sena","log_level":"WARNING","host":"192.168.1.252","port":"1883","user":"jeedom","pass":"xxxxxxxxxxxx","lwt_topic":"tgw\/775\/LWT","publish_topic":"home\/TGW_775\/BTtoMQTT"}' | sudo tee /root/theengsgw.conf => {"adapter":"hci0","discovery_filter":["IBEACON","GAEN","MS-CDP","APPLE_CONT","APPLE_CONTAT"],"discovery_device_name":"Sena","log_level":"WARNING","host":"192.168.1.252","port":"1883","user":"jeedom","pass":"xxxxxxxxxxxxxx","lwt_topic":"tgw\/775\/LWT","publish_topic":"home\/TGW_775\/BTtoMQTT"}
[2023-11-21 23:15:50][INFO] : Configuration de l'antenne 'Sena'
[2023-11-21 23:15:50][DEBUG] : local exec:sudo systemctl stop TheengsGateway.service =>
[2023-11-21 23:15:50][DEBUG] : local exec:echo ' [Unit] Description=TheengsGateway Service After=network-online.target [Service] Type=simple ExecStart=/root/.local/bin/TheengsGateway Restart=always RestartSec=10 StandardOutput=append:/var/www/html/log/tgw_775 StandardError=append:/var/www/html/log/tgw_775 [Install] WantedBy=multi-user.target ' | sudo tee /etc/systemd/system/TheengsGateway.service =>
[2023-11-21 23:15:50][DEBUG] : handle Mqtt Message:{"tgw":{"775":{"LWT":"offline"}}}
[2023-11-21 23:15:50][INFO] : LWT update:offline
[2023-11-21 23:15:51][DEBUG] : local exec:sudo systemctl daemon-reload =>
[2023-11-21 23:15:51][DEBUG] : local exec:sudo systemctl enable --now TheengsGateway.service =>
[2023-11-21 23:15:52][DEBUG] : local exec:hcitool dev | grep hci => hci0 00:01:95:39:8D:70
[2023-11-21 23:15:52][DEBUG] : handle Mqtt Message:{"tgw":{"775":{"LWT":"online"}}}
[2023-11-21 23:15:52][INFO] : LWT update:online
[2023-11-21 23:15:54][DEBUG] : local exec:ls /tmp/ | grep -Ec tgw_install_in_progress => 0
[2023-11-21 23:15:55][DEBUG] : local exec:sudo /root/.local/bin/TheengsGateway -h | grep -Ecw "usage:" => 1
[2023-11-21 23:15:55][DEBUG] : local exec:sudo python3 -m TheengsGateway -h | grep -Ecw "usage:" => 0
[2023-11-21 23:15:55][INFO] : Lancement de l'installation de l'antenne 'Sena'
[2023-11-21 23:15:55][DEBUG] : local exec:sudo systemctl stop TheengsGateway.service =>
[2023-11-21 23:15:55][DEBUG] : local exec:sudo bash /var/www/html/plugins/tgw/core/class/../../resources/install_apt.sh http://192.168.1.252/plugins/tgw/core/php/jeetgw.php?id=775 > /var/www/html/log/tgw_775_update 2>&1 & =>
[2023-11-21 23:15:55][DEBUG] : handle Mqtt Message:{"tgw":{"775":{"LWT":"offline"}}}
[2023-11-21 23:15:55][INFO] : LWT update:offline
[2023-11-21 23:15:55][DEBUG] : step:0 for id:775
[2023-11-21 23:15:58][DEBUG] : step:1 for id:775
[2023-11-21 23:16:00][DEBUG] : step:2 for id:775
[2023-11-21 23:16:03][DEBUG] : step:3 for id:775
Le plantage s’est reproduit aujourd’hui vers 12H mais j’avais reparamétré les log en defaut
Ce problème est très ennuyeux, sachant que je n’avais pas rencontré de problème avec la clé SENA et le NUC durant des années (sous BLEA).
De plus, je dois ouvrir prochainement un autre sujet sur l’utilisation d’OMG avec mes deux AZDelivery ESP32 NodeMCU .
Après un « certain temps d’utilisation », je n’ai plus de remontées d’infos et de visu je constate que la led rouge des ESP32 est éteinte.
Je dois alors débrancher et rebrancher l’alimentation de mes ESP32
Complément d’information :
J’ai exécuté exactement la même manipulation que @anon53349806 « retourner dans l’antenne, reselectionner la clé BT, sauvegarder la config »… et en effet çà repart !
Jai mis en place l’autosuspend a -1 au lieu de 2. Depuis 5j pas de souci
Cà « sent » la commande linux … avec lesquelles je risque de faire des bêtises 
Bonsoir,
comment tu as fait pour modifier l’autosuspend ?
Comme l’a dit Fabrice ou comme le lien que j’aie posté plus haut?
Gérard
Rapel : je n’est pas de fichier grub
Bonsoir,
Pour info, j’ai tenté un passage sur TGW aujourd’hui sur un Odroid C2 sous Armbian (Debian 10) et j’avais Blea juste avant qui tournait depuis plusieurs années sur cet Odroid. Et bien j’ai les mêmes soucis que plusieurs d’entre vous : l’install du plugin TGW + MQTT Manager + MQTT Discovery se passe bien, install de l’antenne ok, service ok, tout va bien, il découvre mes périphériques, je suis tout content… et là… c’est le drame LOL, plus aucune info n’arrive, pourtant tout est au vert 
sous Linux, une commande « hcitool dev » ne me sort plus aucune clé, elle a disparu, et dans les logs du système, les messages pleuvent
Après un reboot, ca repart, mais pour quelques minutes / heures pour finir par planter.
Je vais regarder du côté du autosuspend si ca change qqch.
C’est dommage, c’était bien parti, mais sinon je remettrai un backup avec Blea dessus, et j’installerai tout cela sur un autre Odroid de tests pour débugger tout ca.
Ce qui est surprenant, c’est que pour tester, cela fait une dizaine de jours, que j’ai TGW en version Docker qui tourne sur une VM (sous un NUC10 en ESXi 8.0) et il ne plante jamais (là en ce moment il tourne, avec une clé BT sena lui aussi).
A suivre.
TiTidom.
Si je ne m’abuse, vos points communs sont odroid et clé sena et debian10.
Si qlqun a une autre clé qu’une sena ca serait intéressant d’éliminer ca de l’équation, il restera odroid et debian10.
Bonsoir.
J’ai deux clés Sena, une en local sur un RPI4B et une distante sur un Rpi3 : aucun problème depuis l’installation (10 jours).
Raspberry pi os 11 sur les deux. 64 bits sur le Rpi4B et 32 bits sur le Rpi3b.
Yep, je n’ai pas été clair: c’était au cas où le couple odroid + sena pose problème mais j’y crois pas.
Et moi j’avais testé un pi avec raspbian 10 sans soucis aussi.
Alors pour moi cela fait 10 jours que cela tourne sans plantage.
jeedom récupère bien les infos de l’antenne distante (pi 3 + sena) via mqtt discovery.
D’ailleurs via mqtt explorer, on constate bien l’activité de cette antenne.
Je me suis dis : et que donne TGW et là surprise.
Son status installation est ok mais le status service est lui « hors service »
Pourtant plus de plantage de cette antenne depuis 10 jours 
Bon je vais voir pour redémarrer cette antenne au niveau du plugin
Bonjour,
Sena sur VM debian 12.
BT intégré sur pi OS 11 (pi0)
RAS dans les 2 configs.
PS : si ça fonctionne même chez @Fabrice c’est que le bug n’est pas si courant que ça ! 
Pour ceux qui ont le problème : vous avez quoi comme périphériques BT ?
Ça me fait penser à un bug similaire sous BLEA avec certains périphériques qui envoyaient des messages mal interprétés.
Bon suite diag.
Le bluetooth de la carte mère était de nouveau actif.
Je l ai donc désactivé puis rebooter l’antenne distante.
Pour info pour les nouveaux , la conserver cause des problèmes
dans le plugin TGW, j ai bien la SENA en périphérique principal.
Le service est bien actif.
Reste plus qu’à faire de la surveillance…
Par contre je viens de m apercevoir que j ai cela dans le centre de message et 7772 fois et dont un à l’instant
La tâche plugin::cron n’arrive pas à finir à cause du plugin : tgw nous vous conseillons de désactiver le plugin et de contacter l’auteur
la log TGW de l’antenne distante reste vide malgré le mode debug.
vous avez une idée ?
ceux qui ont des problèmes , pourriez vous vérifier de votre côté ?
Bon je pense que ce message est du à la taille du fichier de log de l antenne distante.
j ai supprimé la log.
A présent plus de message dans le centre de message et je peux de nouveaux visualiser la log via le plugin
@Mips , les logs distantes sont elles prises en charge par le système de traitement de log de jeedom à savoir purge en fonction du nombre de lignes ?
Par sur le système distant, c’est le logrotate qui doit le faire, je dois vérifier ce point.
Bonsoir,
J’ai continué mes tests croisés pour essayer de voir d’où vient le problème, et je te confirme que le soucis n’est pas la clé SENA, mais bien du côté du Odroid C2.
J’ai changé de clé Bluetooth, pour mettre un « simple » dongle bluetooth que j’avais, et les plantages surviennent de la même manière (cf. ci dessous, et à noter la corrélation entre l’heure du dernier message d’erreur, et l’horodatage du device qui passe en « absent » 2 min plus tard).
J’ai également pris un autre C2 que j’avais sous la main, réinstallé Armbian bullseye (donc basé sur Debian 11) : même punition, cela plante avec les deux clés (la sena et le dongle).
Et ce malgré également un test avec le passage du autosuspend à -1, qui n’a pas eu d’effet particulier…
Je ne pense pas que cela vienne de l’alim des 2 odroid, qui sont en 5V 2A, et cela n’a jamais posé de problème (cela fait plusieurs années qu’ils tournent).
Par ailleurs, j’ai installé via le plugin TGW une antenne distante sur une VM qui tourne sous Ubuntu 22.04 (elle même sous ESXi), avec une clé SENA branchée dessus, et bien elle renvoit ses infos bluetooth au broker depuis sans broncher une seconde, et d’ailleurs, pas un message d’erreur dans les logs…
Conclusion pour mon cas en tout cas : le soucis vient du Ordoid C2.
La seule chose qui m’étonne, c’est que si je réactive BLEA sur ces 2 mêmes Odroid C2, il tourne sans broncher avec la clé SENA pendant des jours.
EDIT : en fait avec BLEA, les mêmes messages d’erreurs apparaissent, c’est juste que le plugin arrive à récupérer la main (ce qui explique les pertes de présence de certains de mes NUT à y réfléchir, alors qu’ils sont à la maison).
Bonne soirée,
TiTidom.
Ce qui serait intéressant si tu sais le faire, c’est dans la même config, testez theengs en docker sur cette machine au lieu de l’installer en local voir si le problème reste
Salut,
On a eu la même idée
Je viens de faire le test, donc sur un Odroid C2 (celui là encore sous Debian 10, pas envie de casser celui que je viens de réinstaller en Debian 11 
), avec Docker fraichement installé dessus et un docker-compose que j’utilise par ailleurs pour faire tourner un TheengsGateway.
Je te laisse juger ce qu’il s’est passé quelques minutes plus tard… :
Et Theengs (version docker) ne gère visiblement pas ce genre de « crash » du hardware (car la clé pour info reste visible via un « hcitool dev »), par contre si je relance le docker-compose (down puis up), (sans rebooter et sans rien faire de particulier d’autre) ca repart et j’ai de nouveau le RSSI qui est bien remonté sur mon jeedom de tests.
En même temps, que Docker se comporte de la même manière qu’en natif sur l’OS est plutôt « rassurant », car dans le docker il monte le volume « dbus » pour récupérer la clé bluetooth, donc quelque part, il s’appuie sur les drivers de l’hôte (de l’odroid donc).
Si tu souhaites d’autres tests, je suis à ta dispo.
Bonne journée,
TiTidom.