Suite à mes posts différents, je suis passé de BLEA à MQTTD + TGW.
Cela fait donc quelques jours que je tourne dessus.
Au niveau installation :
une PI avec une clé SENA dans un coin de la maison (BT interne désactivé) en ethernet et démon TGW installé et fonctionnel
une VM Jeedom avec une clé SENA et un antenne locale TGW
une PI à l’extérieur de la maison avec son BT interne - cette antenne ne me sert que pour capter notre arrivée.
Premier constat, les Gtag, les NUTs remontent sans souci de présence (dit autrement, quand ils sont présents, ils le sont et ne décrochent pas sauf quand ils sont partis).
Second constat, tous les capteurs qui remontent des données (température, humidité) remontent mal.
Par exemple, un capteur à 50cm de l’antenne :
Un autre qui est à 10m d’une autre antenne avec 2 murs en béton :
D’autres capteurs ont été reconnus quand ils étaient dans une zone et depuis que je les ai installés, ils ne sont jamais revenus (j’ai tenté d’enlever la pile, etc).
Avant de « balancer » des logs, la configuration de l’équipement etc, j’ai remarqué que la commande hcitool lescan voit bien les devices en question sur leur antenne de zone ou même sur la voisine (on vient bien la mac de l’équipement qui ne remonte pas).
Si j’ai compris la logique du plugin, cela serait TGW qui ne voit pas les devices « correctement ».
Si j’ai bien compris la plateforme n’est pas gérée par l’auteur, je préfère poser la question pour savoir qu’est ce que je dois partager, envoyer ou tester.
Euh… y a rien d’autre sur la PI ou la VM Jeedom.
Sur les PI en question ça se résume à ça :
Debian, un utilisateur qui a les droits sans password, une installation de l’antenne via le plugin et basta.
Mes notes d’installation :
debian11 lite 64 bits
bluetooth interne désactivé, donc le hci0 pointe sur la clé sena
mon utilisateur sans mot de passe pour le sudo
et un simple script qui remonte à un virtuel jeedom si la clé est running toutes les 5min via le crontab
et ensuite, j’ai cliqué sur installation l’antenne.
La question est : pourquoi ça remonte en morceau ? Certains remontent bien, d’autres pas du tout.
je n’ai toujours pas compris pourquoi tu me dis que ça n’utilise pas le BT. Cela remonte comment ?
Quand je fais un scan via hcitool sur l’antenne de la zone, elle voit bien dans la minute tous les devices.
Alors que quand j’utilise le plugin, certains ne remontent jamais, voir remontent en morceau.
Autre question : est-ce que le fait que le plugin monitoring soit connecté en SSH peut bloquer ? (j’en doute mais je préfère poser la question).
Je vois que tu as supprimé mon tag plus haut :
j’ai installé Theengs gateway pour les raspberry et l’antenne locale
j’ai installé MQTTdiscovery pour récupérer les infos remontés par les antennes
Un sujet = une question sur un plugin avec une solution.
Je n’ai toujours pas compris quelle est la question et de quoi on parle, à chaque nouveau message tu changes de sujet.
Si ta question est: « est-ce que l’utilisateur doit se nommer ‹ jeedom ›? » Alors non, c’est un exemple.
Pourquoi parler des antennes à présent? Tu dis n’avoir aucune interruption sur tes nuts donc pas de décrochage d’antenne j’imagine. Un historique du statut « en ligne » de celles-ci?
Ensuite, pas de problème, je vais créer autant de posts que de questions.
Puisque visiblement, tu as du mal à me suivre, je vais résumer et paraphraser.
Les devices de marque Xiaomi (ATC ou MJ-HT) remontent quand ils ont envie.
Alors que l’antenne est en ligne, et qu’un scan BT les voit parfaitement sur l’antenne en question.
Pourquoi parler des antennes, car j’ai remarqué que si je redémarre le service, les devices reviennent en partie ; c’est tout.
J’ai activé l’historisation des antennes pour la journée, mais je n’ai aucun doute que ces dernières le soient. J’avais mis une action si l’antenne est hors ligne plus de 10min et je n’ai jamais reçu ce message.
Mais je vais te fournir tout ce que tu demandes.
Je prends deux exemples les plus parlant, un capteur ATC à moins de 50cm de l’antenne SENA d’une antenne installée sur une PI.
Un capteur MJ HT à 1m :
Les 2 devices en question ont leur MAC qui remontent via un scan sur l’antenne en question plus de 10 fois sur la même minute (même si tu m’as dit que ça n’utilisait pas le BT).
ca veut dire quoi « mal » ? un capteur ne remonte jamais des données à fréquences fixes, soit ca remonte quand y a changement soit … quand ca remonte, random, aléatoire, on ne sait pas dire… ca sera jamais en permanence,
donc j’en sais rien et pas la peine de créer un post pour ca: si l’antenne tourne et remonte des infos, l’installation de l’antenne est fonctionnel, la responsabilité de plugin-tgw s’arrête là.
pourquoi ton capteur ne remonte pas, je ne sais pas et je ne saurai jamais.
je ne sais pas ce que c’est
mais ca me parait normal, ca remontera toujours quand ils auront envie, j’en sais pas plus.
aucune idée de quoi tu parles
aucune idée de quoi tu parles… je ne comprend pas pourquoi tu fais des scans ni l’intérêt
Et forcément si tu utilises le bluetooth pour tes scans, il n’est plus dispo pour theengsgateway.
essaies sans antenne sena, plein de gens se plaignent de stabilité avec cette antenne
moi j’ai deux pi0 avec le bluetooth interne et ca bouge pas
quoi?
Mes plugins ne gère pas le bluetooth
mais l’application theengsgateway utilise le bluetooth évidemment !
mais je ne gère pas cette app, juste l’installation et son paramétrage.
les firmwares de ces capteurs sont réglés pour envoyer des données toutes les 1.5s (économie de pile). De base c’est 500ms.
quand on lance un lescan, on travaille avec la couche radio uniquement (mac) donc la clé est tout à fait capable de faire autre chose. Pour explication ton téléphone sait être connecté à quelque chose et scanner ce qu’il l’entoure.
c’est bien la première fois que j’entends que cette clé n’est pas stable. je vais le test de retirer cette clé donc et repasser sur le BT interne de la raspberry
quand bien même cela ne m’explique pas que je n’ai aucun problème de présence/absence de mes NUT ou gTag.
Personnellement, c’était bien l’inverse et cela depuis des années. Je suis passé sur des SENA il y a près de 7 ou 8 ans car justement j’avais des problèmes de couverture et qu’il fallait multiplier les antennes.
Le problème n’est pas une remontée de données quand le capteur a envie, c’est juste qu’il ne remonte pas. Point. Il n’est pas vu l’antenne ou le plugin qui le traduit. C’est ça que je ne sais pas.
Un exemple, ce capteur est à 50cm de l’antenne (et je suis gentil) :
Comme expliqué par le développeur (peut être de manière extrêmement factuelle ) ses plugins ne gèrent pas le Bluetooth, donc si tu as des problèmes avec des équipements qui ne remontent pas dans tgw, comme il l’a indiqué, il faut voir chez eux… ce plugin ne fait que mettre a disposition des jeedomiens une solution que plein de monde utilise (sous jeedom ou sous ha ou autre) : tgw. Le développeur ne peut donc pas connaître chaque équipement que tu peux potentiellement relier à tgw …
Je vois aussi que tes questions partent dans tous les sens, le but du forum c’est aussi d’aider les gens qui liront ta demande et sa solution (si trouvée) après, donc il est en effet conseillé pour la clarté et simplicité de faire une question = un sujet. (C’est le principe ITIL 4 si tu connais)
Rien ne t’empêche cependant de poser une question générale aux utilisateurs qui utilisent tgw ici et qui te répondront s’ils le peuvent (d’où il a retiré le tag).
Mais comme écrit dans le post qui explique comment poser une question (que tu connais je pense) il ne faut pas exiger d’un développeur qu’il te réponde en le taggant. Ni faire d’attaques personnelle en supposant ou interprétant le ton utilisé.
Et pourtant quelque chose me dit qu’on va me dire qu’il n’y a aucune modification en lien avec mon problème.
(le petit saut de 1 à 0 vers 18h le dimanche est un essai en retirant les piles de certains capteurs).
workflow qui n’a pas tourné sur master mais sur dev:
il m’était nécessaire d’avoir ce fichier sur master pour pouvoir faire mes tests sur la branche dev (renseigne toi sur l’action « workflow_dispatch » sur github qui n’est visible que si le workflow existe sur la branche principale même si on veut l’exécuter sur une autre)
mais qui suis-je pour dire tout ça… je n’y connais rien sur ce plugin (ni sur les actions github)
donc soit tu as résolu ton problème autrement, soit il va revenir…
Euh… il faut vraiment se détendre là, je ne t’ai rien dit du tout ! Le factuel vaut aussi pour toi.
J’ai même dit que j’étais persuadé que la mise à jour n’avait aucun lien avec mon souci.
Tu penses sincèrement que je ne regarde pas avant une mise à jour ce qui a évolué sur le plugin ?
C’était le sens de ma réponse de ce jour.
Et pourtant quelque chose me dit qu’on va me dire qu’il n’y a aucune modification en lien avec mon problème.
La seule chose qui a été faite par le plugin, c’est la réinstallation des dépendances (d’ailleurs le plugin proxmox au même instant s’est mis en KO). Et depuis, pas de souci.
Et pour le coup, au contraire, je pense que le problème a bien disparu !
PS : pas la peine de dérouler 15000 lignes d’explication ; je ne t’ai rien reproché.
