Est-ce possible de détecter un hci DOWN et de l’activer si c’est le cas avant de lancer le démon ?
Quand j’essaye de lancer le démon, ça me met lancement réussi alors qu’en réalité sur la machine distante le démon ne s’est pas lancé car l’interface est DOWN. Une fois UP, tout roule
Oui je sais, le but c’est d’automatiser l’action un maximum, surtout par un déclencheur fixe et non temporel. Dès fois que je débranche et rebranche une clé, ça ne veut pas remettre en UP et je n’ai pas toujours la console à portée de main.
Ben une fois le script dans le plugin script fait, avec un refresh toutes les minutes tu peux te remonter une info binaire et en fonction de cela déclencher ce que tu veux.
Je vois pas trop le souci.
perso pour mes clés usb j’ai cela pour savoir si plugguées ou pas car je jongle entre plusieurs jeedom pour les tests
Je préfère réduire un maximum les tâches planifiées dans Jeedom, il a déjà beaucoup à faire dans la maison^^
C’est cool ta vérification, ça évite les désarrois d’une panne, mais quand c’est bien géré, je trouve qu’on n’a pas forcément besoin en tant qu’utilisateur « lambda » d’ajouter cette couche de supervision.
Hello,
Je peux regarder comment ajouter ca dans le plugin , ca doit pas pas etre « rocket science ».
Ou au moins ne pas démarrer si l’interface nest pas up
C’est fait dans la derniere mise a jour du plugin, par contre il est possible qu’il y ait un probleme de droits d’execution des commandes hciconfig. Je vais regarder un peu plus tard ou demain, quand le pluie arrivera
Benoit
Tu as fait un sudo ? A priori ça ne devrait pas poser de problème de droits.
Par contre j’ai une interface hci1 et le démon se lance bien mais au bout d’un moment, ça s’arrête. Pas de souci avec une autre clé hci0.
Arret de l’antenne aaa because alive=0
Arret de l’antenne aaa suite a un probleme reporte par l’antenne.
0000|[2024-03-02 12:51:15]INFOroot : =========
0001|[2024-03-02 12:51:15]INFOroot : Start phone_detectiond
0002|[2024-03-02 12:51:15]INFOroot : Version: 2.2.4
0003|[2024-03-02 12:51:15]INFOroot : Log level : info
0004|[2024-03-02 12:51:15]INFOroot : Socket :
0005|[2024-03-02 12:51:15]INFOroot : SocketHost : 192.168.0.153
0006|[2024-03-02 12:51:15]INFOroot : SocketPort : 55009
0007|[2024-03-02 12:51:15]INFOroot : PID file : /tmp/phone_detectiond.pid
0008|[2024-03-02 12:51:15]INFOroot : Device : hci1
0009|[2024-03-02 12:51:15]INFOroot : Callback : http://192.168.0.120:9080/plugins/phone_detection/core/php/phone_detection.php
0010|[2024-03-02 12:51:15]INFOroot : Daemon Name : aaa
0011|[2024-03-02 12:51:15]INFOroot : Polling Interval when device is Absent : 10
0012|[2024-03-02 12:51:15]INFOroot : Polling Interval when device is Present : 10
0013|[2024-03-02 12:51:15]INFOroot : Threshold to consider device Absent: 30
0014|[2024-03-02 12:51:15]INFOroot : Python version : 3.7.3 (default, Oct 11 2023, 09:51:27)
0015|[GCC 8.3.0]
0016|[2024-03-02 12:51:15]INFOroot : Using bluetooth controller hci1 (id=1)
0017|[2024-03-02 12:51:15]INFOroot : HCI interface hci1 is already UP
0018|[2024-03-02 12:51:15]INFOroot : PageTimeout set to 1.5625s for controller hci1.
0019|[2024-03-02 12:51:15]INFOroot : Create phone_detection daemon
0020|[2024-03-02 12:51:15]INFOroot : Use TCP socket for Jeedom → daemon communication
0021|[2024-03-02 12:51:15]INFOroot : Get devices from Jeedom
…
0026|[2024-03-02 12:51:16]INFOroot : [1185] Starting monitoring for Téléphone mobile [xxx]
0027|[2024-03-02 12:51:16]INFOroot : Start heartbeat thread
0028|[2024-03-02 12:51:17]INFOroot : [1185] Set « Téléphone mobile » phone present [xxx]
0029|[2024-03-02 12:51:27]WARNINGroot : No response for mac xxx
…
0038|[2024-03-02 12:51:52]INFOroot : [1183] Set « Téléphone mobile » phone present [xxx]
0039|[2024-03-02 12:52:02]WARNINGroot : No response for mac xxx
…
0048|[2024-03-02 12:52:25]ERRORroot : Suspecting an issue with the bluetooth, stop monitoring
Le probleme n’a rien a voir avec HCI1 ou HCI0 dans le code, mais du fait que sur l’antenne ‹ aaa ›, il n’y a pas de reponse pour la mac xxx , et cela 5 fois de suite. Il n’ai pas normal de ne pas avoir de reponse, soit on a le nom du mobile, soit on a un ‹ timeout › renvoye par la stack bluetooth. ‹ No response for mac xxx › vient souvent du fait qu’on ne soit pas arrive a envoyer la demande de nom.
Dans la version 2.2.4, si cela se produisait sur un des mobiles, on comptait ca comme une potentielle erreur avec le bluetooth. Dans la version 2.2.5, il faut que cela se produise 5 fois de suite sur l’ensemble des mobiles.
J’ai un satellites pas toujours proche des équipements (garage au sous sol par exemple), d’où les non réponses je pense.
En tout cas, j’ai fais la mise à jour et je n’ai plus d’erreur. Merci encore pour ta réactivité et de la prise en compte de la demande initiale surtout On va surveiller tout ça pour voir comment ça tient dans le temps.