Déconnexion régulières

[ronanb]

Bonjour,

certains d’entre vous auraient ils des déconnexions intempestives sous TGW ?

Informations configurations :

Ainsi depuis mon passage à debian 11 et avec les conseils et l’aide de @Fabrice et @Mips , j’ai pu configurer les plugins et avoir une remontée de mes nuts.
Cependant, de façon aléatoire et sans en connaitre/comprendre l’origine, j’ai des déconnexions, tous les nuts passent absents d’un coup.
J’ai trouvé une solution, en cliquant sur :

Forcément, ce n’est pas pérenne dans le temps.

J’ai tenté de relancer les dépendances de ZwaveJS et ZigbeeLinker, car je me demande si le problème ne serait pas lié à MQTT plutôt qu’autre chose… lié réinstall complète RPI/jeedom avec import sauvegarde ???

dans MQTT j’ai également suivi un tuto de @MrGreen indiqué ici erreur sur le service Z2M car j’ai eu pas mal de message toute la journée indiquant que le service s’arrêtait, mais, sans rien dans l’analyse santé de jeedom par exemple.
De fait, je refais les mises à jour, relancé le RPI plusieurs fois ce jour.

j’ai parcouru le forum et suis tombé sur un post ou MIPS demande des informations via ces commandes,

hciconfig -a

hci0:   Type: Primary  Bus: USB
        BD Address: 00:01:95:57:59:BF  ACL MTU: 310:10  SCO MTU: 64:8
        UP RUNNING
        RX bytes:2363765 acl:0 sco:0 events:74765 errors:0
        TX bytes:46017 acl:0 sco:0 commands:5091 errors:0
        Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'jarvis'
        Class: 0x2c0000
        Service Classes: Rendering, Capturing, Audio
        Device Class: Miscellaneous,
        HCI Version: 4.0 (0x6)  Revision: 0x2031
        LMP Version: 4.0 (0x6)  Subversion: 0x2031
        Manufacturer: Cambridge Silicon Radio (10)

sudo journalctl -u TheengsGateway.service -e

janv. 11 18:02:27 jarvis systemd[1]: TheengsGateway.service: Consumed 21.071s C>
-- Boot 846e76cd369649ffb15b36f2bc84401b --
janv. 11 18:02:43 jarvis systemd[1]: Started TheengsGateway Service.
janv. 11 18:07:19 jarvis systemd[1]: Stopping TheengsGateway Service...
janv. 11 18:07:19 jarvis systemd[1]: TheengsGateway.service: Succeeded.
janv. 11 18:07:19 jarvis systemd[1]: Stopped TheengsGateway Service.
janv. 11 18:07:19 jarvis systemd[1]: TheengsGateway.service: Consumed 1.576s CP>
janv. 11 18:07:20 jarvis systemd[1]: Started TheengsGateway Service.
janv. 11 18:56:23 jarvis systemd[1]: Stopping TheengsGateway Service...
janv. 11 18:56:23 jarvis systemd[1]: TheengsGateway.service: Succeeded.
janv. 11 18:56:23 jarvis systemd[1]: Stopped TheengsGateway Service.
janv. 11 18:56:23 jarvis systemd[1]: TheengsGateway.service: Consumed 49.749s C>
janv. 11 18:56:23 jarvis systemd[1]: Started TheengsGateway Service.
janv. 11 19:18:01 jarvis systemd[1]: Stopping TheengsGateway Service...
janv. 11 19:18:01 jarvis systemd[1]: TheengsGateway.service: Succeeded.
janv. 11 19:18:01 jarvis systemd[1]: Stopped TheengsGateway Service.
janv. 11 19:18:01 jarvis systemd[1]: TheengsGateway.service: Consumed 27.149s C>
janv. 11 19:18:27 jarvis systemd[1]: Started TheengsGateway Service.
janv. 11 20:55:09 jarvis systemd[1]: Stopping TheengsGateway Service...
janv. 11 20:55:09 jarvis systemd[1]: TheengsGateway.service: Succeeded.
janv. 11 20:55:09 jarvis systemd[1]: Stopped TheengsGateway Service.
janv. 11 20:55:09 jarvis systemd[1]: TheengsGateway.service: Consumed 1min 56.3>
janv. 11 20:55:09 jarvis systemd[1]: Started TheengsGateway Service.
lines 28-50/50 (END)
janv. 11 18:02:27 jarvis systemd[1]: TheengsGateway.service: Consumed 21.071s CPU time.
-- Boot 846e76cd369649ffb15b36f2bc84401b --
janv. 11 18:02:43 jarvis systemd[1]: Started TheengsGateway Service.
janv. 11 18:07:19 jarvis systemd[1]: Stopping TheengsGateway Service...
janv. 11 18:07:19 jarvis systemd[1]: TheengsGateway.service: Succeeded.
janv. 11 18:07:19 jarvis systemd[1]: Stopped TheengsGateway Service.
janv. 11 18:07:19 jarvis systemd[1]: TheengsGateway.service: Consumed 1.576s CPU time.
janv. 11 18:07:20 jarvis systemd[1]: Started TheengsGateway Service.
janv. 11 18:56:23 jarvis systemd[1]: Stopping TheengsGateway Service...
janv. 11 18:56:23 jarvis systemd[1]: TheengsGateway.service: Succeeded.
janv. 11 18:56:23 jarvis systemd[1]: Stopped TheengsGateway Service.
janv. 11 18:56:23 jarvis systemd[1]: TheengsGateway.service: Consumed 49.749s CPU time.
janv. 11 18:56:23 jarvis systemd[1]: Started TheengsGateway Service.
janv. 11 19:18:01 jarvis systemd[1]: Stopping TheengsGateway Service...
janv. 11 19:18:01 jarvis systemd[1]: TheengsGateway.service: Succeeded.
janv. 11 19:18:01 jarvis systemd[1]: Stopped TheengsGateway Service.
janv. 11 19:18:01 jarvis systemd[1]: TheengsGateway.service: Consumed 27.149s CPU time.
janv. 11 19:18:27 jarvis systemd[1]: Started TheengsGateway Service.
janv. 11 20:55:09 jarvis systemd[1]: Stopping TheengsGateway Service...
janv. 11 20:55:09 jarvis systemd[1]: TheengsGateway.service: Succeeded.
janv. 11 20:55:09 jarvis systemd[1]: Stopped TheengsGateway Service.
janv. 11 20:55:09 jarvis systemd[1]: TheengsGateway.service: Consumed 1min 56.393s CPU time.
janv. 11 20:55:09 jarvis systemd[1]: Started TheengsGateway Service.
~

Si toutefois, il fallait plus d’informations, je ferai au mieux pour y répondre.
Par avance, merci de vos retours,

[anon53349806]

Y a eu un sujet la dessus, perso jai du enlever leconomie denergie sur le port usb de ma.cle bt pour plus avoir ce phenomene

[ronanb]

bonsoir @anon53349806,
j’ai effectivement vu passer des sujets similaires, pour debian 10 donc j’ai passé mon chemin mais surtout pour les clé SENA UD100, qui par ailleurs est mon matériel.
Serais tu sur celle-ci aussi ?

comment as tu procédé ? je ne savais même pas qu’il y avait une économie d’énergie à vrai dire

[ronanb]

j’ai lu aussi que dmesg pouvait donner des infos, et effectivement… ça renvoie bcp d’éléments, cependant je ne sais pas quoi chercher mise à part la fin :
dmesg_log.txt (101,5 Ko)

[14269.149747] Bluetooth: hci0: Opcode 0x200c failed: -110
[14269.149773] Bluetooth: hci0: Unable to disable scanning: -110
[14269.395634] Bluetooth: hci0: Opcode 0x2005 failed: -16
[14281.761777] Bluetooth: hci0: sending frame failed (-19)
[14296.767533] Bluetooth: hci0: sending frame failed (-19)

des dizaines de lignes de ce type

[Mips]

Salut,

Pour le coup y a trop d’info

Pourquoi 2 pages santés? Y a 2 jeedom?

Ne parlons pas de mqtt, mqttdiscover, zigbee ni zwavejs ici, ça n’a aucun rapport.

Même le plugin-tgw ni est pour rien (si l’antenne est en ligne)

Si j’ai bien compris c’est theengsgateway qui perd la connexion avec le bluetooth c’est ça?

Log de l’antenne dit quoi?

[anon53349806]

@ronanb

clé SENA UD100, qui par ailleurs est mon matériel.
Serais tu sur celle-ci aussi ?

Oui c’est bien une clé SENA dont je dispose.

@ronanb

comment as tu procédé ?

En SSH :

Dans /sys/module/usbcore/parameters
Editer le fichier autosuspend et mettre -1

Editer le fichier /etc/default/grub

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.autosuspend=-1"

C’est cette dernière ligne à modifier

Ensuite lancer update-grub

Voila, perso, sur VM en debian 11 cela a résolu le souci qui est bien coté OS

[ronanb]

bonjour @Mips ,
erreur de manipulation, j’ai ajouté deux fois la page santé dans le post sans le vouloir. il n’y a donc qu’une page santé et un seul jeedom.
Régulièrement, page santé reste intacte, pas de notion de déconnexion sur TGW, tous les nuts sont déconnectés en simultanés. solution trouvée : relancer l’antenne pour que ça revienne.

Voici 2 logs issues du TGW
tgw_291_update.txt (5,7 Ko)
tgw_291.txt (240,2 Ko)

@anon53349806 merci de ton retour ! avant de tester je vais patienter que Mips puisse voir mes logs au cas où il me demande une autre information.
Cependant je confirme avoir ce ressenti que ce n’est pas la domotique en elle même ou au plus une incohérence avec MQTT (conflit quelconque ??).
Je dis MQTT car j’ai remarqué un comportement bizarre de ZigbeeLinker qui m’informe de l’arrêt d’un service mais encore une fois pas de message en centre notif, page santé OK… et parfois indique zigbee2mqtt arrêté.

Ton expérience et cette notion de « mise en pause » du port USB est toute à fait cohérente, sait on si il y a eu une mise à jour lié à l’OS de ce côté ? merci encore.

[Mips]

Donc c’est (encore) l’erreur avec bluez: [org.bluez.Error.InProgress] Operation already in progress

discussion intéressante ici par exemple: Bluetooth scanner conflict results in org.bluez.Error.InProgress · Issue #76186 · home-assistant/core · GitHub

quelques pistes:

• mise à jour des paquets (puisque bluez est le stack official debian pour intégration bluetooth, le fix doit venir de là je pense
• changer la clé de port usb (ca fonctionnerait mieux avec un port usb2?) ou utiliser un hub?
• changer de clé
• pas d’autres process qui utilisent le bluetooth sur la machine?

[ronanb]

discussion intéressante ici par exemple: Bluetooth scanner conflict results in org.bluez.Error.InProgress · Issue #76186 · home-assistant/core · GitHub

J’avoue ne pas tout comprendre, j’ai trouvé ce lien https://f-a.nz/dev/bluez-5-66-on-debian-bullseye-pi4-cm4/, faut il faire une telle mise à jour ?

sur le site BlueZ » Download ils parlent de la 5.66, en revanche bluez - Debian Package Tracker évoque des versions autres, mais sauf erreur ce sont des beta.

• mise à jour des paquets (puisque bluez est le stack official debian pour intégration bluetooth, le fix doit venir de là je pense

sudo apt update && sudo apt full-upgrade -y
a été fait.

sinon en faisant ‹ systemctl status bluetooth ›

* bluetooth.service - Bluetooth service
     Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2024-01-11 18:02:33 CET; 17h ago
       Docs: man:bluetoothd(8)
   Main PID: 529 (bluetoothd)
     Status: "Running"
      Tasks: 1 (limit: 8754)
        CPU: 1min 22.470s
     CGroup: /system.slice/bluetooth.service
             `-529 /usr/libexec/bluetooth/bluetoothd

janv. 11 18:02:32 jarvis systemd[1]: Starting Bluetooth service...
janv. 11 18:02:33 jarvis bluetoothd[529]: Bluetooth daemon 5.55
janv. 11 18:02:33 jarvis bluetoothd[529]: Starting SDP server
janv. 11 18:02:33 jarvis systemd[1]: Started Bluetooth service.
janv. 11 18:02:33 jarvis bluetoothd[529]: Bluetooth management interface 1.22 initialized
janv. 11 18:02:34 jarvis bluetoothd[529]: profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
janv. 11 18:02:34 jarvis bluetoothd[529]: sap-server: Operation not permitted (1)
janv. 11 18:02:34 jarvis bluetoothd[529]: Failed to set privacy: Rejected (0x0b)
janv. 11 18:02:38 jarvis bluetoothd[529]: Endpoint registered: sender=:1.28 path=/MediaEndpoint/A2DPSink/sbc
janv. 11 18:02:38 jarvis bluetoothd[529]: Endpoint registered: sender=:1.28 path=/MediaEndpoint/A2DPSource/sbc

• changer la clé de port usb (ca fonctionnerait mieux avec un port usb2?) ou utiliser un hub?

Je test cela, j’ai un hub sur lequel est actuellement connecté la clé Zwave aotec Gen5 et Zigbee conbee 2 avec plusieurs usb je vais la mettre dessus.

• changer de clé

je n’ai que le BT du Rpi 4

• pas d’autres process qui utilisent le bluetooth sur la machine?

comment le définir ? j’utilise le BT pour détecter les téléphones portables (2 ios et 1 android via Détection de téléphone (Bluetooth) (phone_detection) - stable)

[Mips]

@ronanb

comment le définir ? j’utilise le BT pour détecter les téléphones portables (2 ios et 1 android via Détection de téléphone (Bluetooth) (phone_detection) - stable)

Voilà c’est ça.
Il ne faut pas avoir 2 plugins/process qui utilisent le bluetooth sur la même machine sinon il y a conflit entre les deux

[ronanb]

ok ! migrer cette utilisation sur MQTTDiscovery donc.
comment explique d’avant je n’avais pas ce soucis ? j’ai ce plugin depuis le début et ajouté les nuts après sur BLEA.

nota : comment enlever tout cela (idem dans les inconnus) pour s’y retrouver?
dumoins outre le supprimer, tout retirer d’un coup ou éviter qu’il s’en crée en boucle.
je vais aller creuser le forum si tu as déjà répondu

[Mips]

Lis le community sur ces deux plugins.
Tu trouveras des dizaines de posts avec le même retour: de base ca devrait pas fonctionner, en tout cas il y a certainement des conflits entre les deux. Parfois ca marche ou marchotte plus ou moins sans que l’impact ne soit visible puis ca marche plus.

Tout dépend de la fréquence du scan probablement et du temps d’utilisation du bluetooth par chacun. Si le premier libère à temps pour le suivant alors tant mieux sinon … crash.

[Fabrice]

Bonjour,

Pour supprimer toutes ces détections, il y a 2 actions à faire.

La 1ere, pour ne plus que cela arrive, il faut mettre en exclusion ces « Modèle », a faire depuis chaque antenne.
En image :

1. on créer les exceptions
2. on sauvegarde
3. on relance le service
4. on vérifie
   => à faire sur chaque antenne

La 2ème action, ne sera plus a faire à l’avenir (car les exceptions vont faire leurs travail) :
Depuis le logiciel MQTT Explorer (sur PC par exemple) il faut mettre à la corbeille ces découvertes.
Il faut se connecter sur le Jeedom qui avec les identifiants qui se trouvent dans MQTTManager

Et supprimer ce qui est découvert dans homeassistant

Ensuite, il faut redémarrer le demon du plugin MQTTDiscovery et tout doit disparaitre.

[ronanb]

merci à vous !
entre temps j’avais ajouté ces exceptions et supprimé « à la main » (suppr + ok) toutes les lignes

je garde ton fonctionnement pour l’avenir en tête au cas où ! je vais devoir supprimer la règle pour inclure mes iphone puis la remettre.

A confirmer, mais depuis 12H je n’ai pas eu de déconnexion de l’antenne (désactivation du plugin cité au dessus)

[Fabrice]

Chez moi, cela n’a pas supprimé mes périphériques enregistrés.
Ils sont revenu tout seul, dans MQTT Explorer
Dans Jeedom, il n’y a pas eu d’interruption.

[ronanb]

Il semble que ta solution de désactiver le plugin détection phone ait fonctionné.
depuis ce midi je n’ai eu aucune détection de perte de nut malgré un scénario de surveillance.

J’ai une dernière question sur ce sujet. j’ai ajouté mon iphone et celui de ma fille, tous deux détectés au début, j’ai coupé le BT sur les équipements pour tester le ON/OFF de leur état. (manque un android, non détecté).

Je ne lis pas d’éléments faisant état de réelle compatibilité avec les téléphones, probablement que ce n’est pas pris en compte, question pour confirmation.

Depuis plus rien, j’ai testé un re démarrage du RPI sans résultat.

[Fabrice]

L’adresse mac est certainement aléatoire (j’en avais 1893 chez moi)

Regardez s’il y a une option pour ne plus avoir d’adresse mac aléatoire.

[ronanb]

il s’agit effectivement de ce principe dans un but de sécurité mis en oeuvre par la pomme d’après mes lectures. C’est la boulette .
déblocable sur WIFI mais pas sur Bluetooth semble t il.

Tant pis pour ce fonctionnement alors.

[Madcow]

Bonjour,

Les développeurs de Theengs sont en train de tester des choses pour solutionner ce problème :

Apple device et Bluetooth aléatoire

Pas tout à fait, @koen a ajouter la detection d’adresse privèe dans la dernière version de Theengs gateway, il faut utiliser l’IRK afin de permettre à Theengs de resoudre l’adresse de l’Iphone. A considerer comme une beta:

[Mips]

Dans les prochaines versions de theengsgateway (l’app pas le plugin) cela sera peut-être possible via récupération d’une info / configuration additionnelle (je n’ai pas encore bien lu ni compris du coup j’avoue)

Edit: voir message de @Madcow qui est arrivé juste avant le mien