[TUTO] Lire niveau de batterie de vos Gigaset G-Tag

Plugins Communication
, , ,
66

L’update où la fonction a été supprimée date à priori de juillet 2019 d’après ce que je peux lire ici : Plugin blea - Page 163 - Forum Communauté Jeedom
ça n’est jamais revenu depuis :frowning:
Si j’ai bien compris, c’est du à une modif des bibliothèques utilisées par le plugin BLEA

Concernant la monopolisation du BT par le plugin BLEA : ça fait longtemps que ça a été abordé :grin:
Récupérer le niveau de batterie des Nut Mini ET des Nut Find 3 - Page 3 - Forum Communauté Jeedom

image
image1159×598 58.3 KB

Edit : le script dans le premier post du lien que je viens de mettre ci-dessus est beaucoup plus élaboré que le mien et comprend une fonction de check et de relance du port HCI utilisé : tu pourrais l’incorporer dans mon script pour voir si ça fonctionne chez toi éventuellement :wink:

67

Hurmf, tu as testé ton code ?
Me semble que ton code ne tient pas compte de l’argument -i… car hci1 est codé en dur… :wink: .

Il y a un souci sur la ligne du log.

./g-tag.sh: ligne 39: /var/www/html/log/gtag-jeedom.log: Aucun fichier ou dossier de ce type

J’ai modifié pour écrire le log en local.

EDIT : j’ai tenté de refaire marcher le script pour mes nuts 3 en modifiant le lien.
Il n’arrive pas à récupérer la batterie.

Redémarrage hci0...
hci0 redémarrée

==============
lundi 14 novembre 2022, 18:49:22 (UTC+0100)
Démarrage de l'analyse du Nut CD:98:B8:19:3D:E8...
  Récupération du handle avec la commande sudo hcitool -i hci0 lecc  CD:98:B8:19:3D:E8 | awk '{print $3}'
Could not create connection: Connection timed out
  KO: pas de handle pour CD:98:B8:19:3D:E8 !
Une erreur s'est produite...
68

Normal : je ne tient compte d’aucun argument en ligne de commande :rofl:
Donc oui il faut modifier le port directement dans la ligne du script qui balance la commande, c’est ce que j’ai mis dans les explications du tout premier post : renseigner le port dans la variable « v_retour » :wink:

ça marche bien chez moi, je n’ai pas les soucis que tu rencontres :frowning:

69

J’ai modifié le script, il tourne bien. J’ai gardé le reboot par sécurité pour l’heure.
Merci.

70

PS : pour le log : oui comme tu es sur une VM et pas sur la machine Jeedom, mon propre chemin ne fonctionnera pas :wink:

71

@benj29 je tombe sur ce topic par hasard : Arrêt de surveillance sur antenne déportée - #6 par benoit5672
Si tu utilises ce plugin, cette mise à jour va peut-être solutionner ton problème en tout ou partie :wink:

72

J’utilise déjà la surveillance de BLEA que j’avais mis en place et effectivement on peut faire la même chose avec phone_detection, bonne idée.

blea::launch_allremotes();  
phone_detection::launch_allremotes();

Sauf que dans mon cas mes PI servent aussi à d’autres choses (franchement 3 ou 4 antennes BT ça fait mal juste pour du BT :D). Compteur d’eau, 5 compteurs pulse élec, 6 températures, niveau d’eau etc. Donc je me vois mal les redémarrer en plein comptage…

J’utilise ce code déjà pour vérifier s’il y a un problème et ça relance le démon.

$remotes = blea_remote::all();
foreach ($remotes as $remote) {
  //$last = $remote->getConfiguration('lastupdate','0');
  $last = $remote->getCache('lastupdate','0');
  $_remoteId = $remote->getId(); 
  if ($last == '0' or time() - strtotime($last)>65){
    $scenario->setLog('Antenne BLEA : '. $remote->getRemoteName() . ' , état KO, redémarrage du démon');
    message::add('networks','Antenne BLEA : '. $remote->getRemoteName() . ' , état KO, redémarrage du démon');
    //blea::launchremote($_remoteId);	  
  } else {
    $scenario->setLog('Antenne BLEA : '. $remote->getRemoteName() . ' , état OK');
  }
}
1 « J'aime »
73

Hurmf, doit y avoir un souci avec le type ou la valeur.
J’ai voulu juste mettre une alerte si niveau trop bas (15 alerte, 25 warning) mais visiblement… ça ne marche pas.
75 > 25 ou 15… pour lui c’est l’inverse. J’ai tenté avec % ou non ; pareil.

1243×195 12 KB

1848×560 52.5 KB

1 « J'aime »
74

Hello.
Ça me rappelle un problème que j’ai eu y’a très longtemps avec un de mes scripts, mais pas moyen de me rappeler quoi exactement ni lequel :frowning:
Je me souviens avoir tout tenté, jusqu’à la formule de conversion avec le tag mais sans succès, puis tout est rentré dans l’ordre, mais je ne me souviens pas du tout de ce que j’ai dû faire pour ça.
Si ça me revient je te dirai.

En tout cas j’ai toutes mes valeurs ok dans jeedom actuellement, sans aucune formule d’appliquée pour forcer quelque chose. Et mes valeurs sont bien en type « info/numérique », bien sûr sans le symbole % comme sur ta capture.

75

Je vais passer les alertes en scénario tant pis. Voir si jamais ça change.

76

J’ai tout refouillé mon Jeedom et je n’ai rien trouvé, désolé :frowning:
Moi ça marche bien tel quel avec mes 4 GTags, sans rien faire de plus.

Essaie de :

  • créer un nouveau virtuel
  • lui ajouter une info numérique
  • y mettre manuellement au moins une valeur numérique (non nulle éventuellement)
  • modifier mon petit script pour y ajouter une ligne supplémentaire d’envoi vers Jeedom pour l’ID du nouveau virtuel que tu viens de créer

=> supprimer l’ancien virtuel parce que ça va marcher
=> ou bien continuer à t’arracher les cheveux qui restent qui restent parce que non ça ne marche pas mieux :grin:

77

Bon devant la galère de blocage régulière de la clé qui sert à la présence des nut et des gtag mais aussi au relevé de la batterie ; j’ai changé ma manière de faire.

Pour rappel, le fait de demander la batterie pour les gtag même une fois par jour bloque souvent (pas tout le temps, j’ai passé par exemple 5 jours cette semaine sans blocage), le démon BLEA de cette même VM. Du coup, le NUT ou le gtag qui doit être récupéré par BLEA en même temps que le code de batterie reste en présent même s’il disparait.

Sur le même code que j’utilise pour vérifier si un démon ne remonte pas d’info ; ici, c’est sur le capteur qui n’a pas communiqué depuis un certain temps. Le seul problème c’est que ce code n’est pas devin. Il ne sait pas si on ne communique pas car on n’est pas là (porte clé bluetooth est hors zone) ou vraiment car l’antenne est bloquée. Les puristes raleront sur le break mais c’était pour voir dans le principe.

$eqpts_BLEA = eqLogic::byType('blea');
foreach ($eqpts_BLEA as $eqpt_BLEA) {
  $lasteqpt_com = $eqpt_BLEA->getStatus('lastCommunication','0');
  $eqpt_BLEA_ID = $eqpt_BLEA->getId(); 
  $scenario->setLog('Equipement ID: '. $eqpt_BLEA_ID .' - Lastcom : '. $lasteqpt_com);
  if (time() - strtotime($lasteqpt_com)>300){
      $scenario->setLog('Redémarrage des démons BLEA (délai:)'. time() - strtotime($lasteqpt_com)>300 .'s');
      message::add('networks','Redémarrage des antennes BLEA');
      blea::launch_allremotes();  
      break;
  } else {
      $scenario->setLog('Check OK Lastcom');
  }
}

Au final, pas trop de choix. Il faut relancer les démons régulièrement.
J’ai donc fait autrement.
Un scénario toutes les 15 */3 * * * va récupérer le niveau des batteries par un SSH commander qui lance le script sur la VM BLEA.

878×265 10.2 KB

Je pourrais relancer uniquement le démon de la VM de la clé SENA qui sert à ça (il semblerait que ce ne soit qu’elle qui bloque tout).

1913×364 32.6 KB

EDIT : bon bein même ça, ça bloque encore.
Obligé de rebooter totalement la VM et là à la relance du démon, ça marche.
Je commence à me demander si ce n’est pas le fait d’avoir cette clé sur une VM dédiée.
Sinon on vivra sans les niveaux de batterie.
@LMQT, tu utilises quoi et comment (une clé sena dans une VM/non VM jeedom ou sur une vm dédiée à BLEA) ? Tu n’as que des gtag ? Je remarque que ce sont les NUT3 qui bloquent visiblement.

1 « J'aime »
78

J’utilise une clé Sena aussi dans un mini-PC en Jeedom principal, et une seconde dans une antenne déportée, aussi dans un mini-PC (j’en avais marre du manque de stabilité des R.Pi quand on leur demande un peu trop).
Sur le principal, j’utilise le BT interne en secondaire pour le plugin de détection de téléphones.
Jamais de plantages du tout sur aucun des deux (je touche du bois).

Moi ce sont les Google Home de mémoire qui provoquent des messages d’erreurs dans la clé SENA (j’ai du les bloquer dans les logs pour éviter la saturation).

J’avais des Nut mini, mais je ne m’en sers plus, j’ai basculé sur des GTags il y a quelques années.

79

Bon, comme mon problème semble localisé à la clé SENA de la VM dédiée à BLEA, on va essayer d’isoler.

Point intéressant, tu me dis que la clé SENA pour PhoneDetection n’est pas sur ton jeedom mais sur une machine séparée. J’ai ça aussi comme principe, il est dans une VM dédiée.

A ce stade, je suis obligé de rebooter quasi systématiquement dès que j’ai exécuté le code pour récupérer les batteries des gtag.
Ensuite, cela semble lié au nut et non pas au gtag. Du moins, ce sont les états de présence des nuts qui restent figés.
Un redémarrage du démon via le code proposé en haut ne suffit pas. Il faut totalement rebooter la VM ! trop lourd.

Je vais déjà remettre la clé SENSA sur la VM locale Jeedom. Initialement, c’était dû à des soucis de stabilité de jeedom 2 en debian 7 et de fuite mémoire associée (oui, il ne doit pas y avoir beaucoup de monde sur le forum qui a connu ça…).

On va voir déjà comment on s’en sort…

80

Pas tout à fait, j’ai du mal m’exprimer.
Je tente de résumer ma conf si ça peut t’aider :

Jeedom principal (mini-PC) :

  • plugin BLEA => sur clé USB SENA (hci0)
  • plugin Phone_Detection => sur clé Sena aussi (hci0)
  • mon script batterie GTags => sur le BT interne (hci1)

Jeedom déporté (mini-PC) :

  • antenne BLEA => sur clé SENA (hci0)
81

OK, étonnant tu utilises la même clé pour PD et BLEA… waow !
J’avais trop de problème quand j’ai tenté de le mettre en place du coup, j’ai une SENA dédiée.
Par contre tu utilises un autre BT pour le script.
A ce jour, j’ai tout coupé (sur la récup de batterie) et je regarde déjà si je n’ai plus de souci d’avoir rapatrié la clé sur la VM de jeedom (alors qu’avant c’était une VM dédiée).

82

Ouaip, BLEA et PD ensemble : j’estime qu’ils vont mieux cohabiter car ils ont gestion des erreurs, de plus ils tournent en permanence donc un loupé n’a pas d’importance.
Mon script n’en a pas, de plus il ne tourne qu’occasionnellement, donc un loupé a de l’importance.
:wink:

83

Bonjour
j’essaye sans succès de faire fonctionner le script avec un G-Tag.
Quand le lance, il m’affiche
/ G-Tag XXX ______________________
[&h64] 100%
Poursuite en arrière plan, PID 4662.

Mais le virtuel n’est pas mis-à-jour. Du coup j’ai deux interrogations :

  • Pour la clé API, laquelle prendre ? Celle de l’API globale de Jeedom ou celle de l’API Jeedom du plugin Virtuel ?

  • Pour l’ID du virtuel, si c’est l’ID du virtuel où je mets des valeurs de batterie, comment le script fait le lien avec la bonne valeur ? Faut-il ajouter l’ID de la valeur au bout de la chaîne ?

Par avance merci du support

84

Je me réponds à moi même

c’est l’API du plugin virtuel qu’il faut utiliser
et l’ID de la valeur dans le virtuel (pas l’ID du virtuel).

Maintenant tout est ok pour moi

merci pour le script !

85

@benj29 as tu réussi à utiliser ce script avec les nut ?