Salut,
J’ai des valeurs que le plugin ne me montre pas
- trafic
- nombre de cpu, fréquence et température
En changeant les seuils de température, je l’obtiens pour me montrer la même chose pendant quelques minutes puis il disparaît
Une idée?
Bonjour,
Vous avez cela depuis quand ?
Sur quoi comme matériel ?
Avez-vous testé avec différent thèmes ?
Le plugin a toujours fonctionné comme ça pour moi.
Les autres questions ?
Sur quoi comme matériel?
Netbook avec Debian
Avez-vous testé avec différents thèmes?
même comportement avec le thème jour / nuit
Avec la dernière version du plugin, je ne rencontre pas ce problème sur des RPi.
Il faudrait regarder si les commandes que le plugin passe, fonctionne chez vous en SSH directement.
Qu’est-ce que la «personnalisation avancée»?
Je voudrais connaître les commandes exactes que le plugin utilise pour les tester dans la console ssh.
C’es très certainement que votre distribution n’est pas compatible avec ce plugin (pourtant : Debian natif semble ok)
Exemple des commandes à saisir :
lscpu | grep 'Processeur(s)' | awk '{ print $NF }'
cat /sys/devices/virtual/thermal/thermal_zone0/temp
Mais c’est vraiment dépendant du matériel.
Un autre plugin arrive, qui fonctionnera peut être nativement chez vous.
domotica@jeedom:~$ lscpu | grep 'CPU(s):' | awk '{ print $NF }'
2
domotica@jeedom:~$ cat /sys/devices/virtual/thermal/thermal_zone0/temp
60000
Nous attendrons ensuite le nouveau plugin
Donc là, cela semble fonctionner correctement.
2 CPU à 60°C
peut-être que cela a à voir avec le langage Debian
J’ai aussi ce type de comportement sur mes NUC Intel 8ixBEH avec Buster v10.7. Là c’est la température qui est affichée de type -261300. J’ai testé avec les commandes UNIX ad hoc et effectivement ce sont elles qui retournent des résultats qui soit ne sont pas prévus (les débits réseaux, par exemple) soit sont dans un format autre que celui attendu (la température des cœurs par exemple ) .
Effectivement passer par une GUI pour encapsuler les commandes Debian conduit à un résultat variable du au fait que la manière dont la distrib Debian a été compilée pour chaque architectures.matérielle ne donne pas forcément des résultats reproductibles pour une commande donnée. Cette différence est je pense la plus flagrante entre ARM71 (RPI) et AMD64 (X86) sans parler de Debian V9 et V10
Par exemple la commande
lscpu
ne retourne pas le terme « CPU » mais plutôt « Cœur(s) par socket » ou « Processeurs »
et la température des coeurs n’est pas donnée par la commande cat /sys/devices/virtual/thermal/thermal_zone0/temp
1 « J'aime »
hello @Fabrice
Désolé de m’incruster sur le post, mais je profite pour te poser la question.
Depuis que je suis passé sur un NUC, je nai plus la température. Ta commande me retourne : -263200
Aurais tu une idée pour la récupérer ?
EDIT: Je vois que Yves19 a le même soucis que moi. 
Je vous remercie.
Je pensais que j’étais le seul à avoir ce problème.
Je pense qu’il peut être résolu en utilisant les valeurs « perso » et en utilisant les commandes appropriées dans chaque cas.
Yes je te confirme
Bonjour’all
Pour info, la température du CPU ne fonctionne plus non plus depuis la mise à jour du Kernel 5.10 sur les Raspberry Pi en 64 bits.
Pour cela, il faut utiliser la commande :
/opt/vc/bin/vcgencmd measure_temp
Ou encore celle-ci, mais en adaptant la zone :
/sys/devices/virtual/thermal/thermal_zoneX/temp
C’est toute la difficulté de ce petit plugin qui au départ, était certainement fait pour l’usage personnel du développeur.
Oui c’est pour ça que les petits plug-- ins on sait faire avec même quand il y a quelques effets de bords sans conséquence . Plus ils sont petits plus ils sont mignons et on leur pardonne tout 
en regardant en interne Monitoring.class.php, je suis convaincu qu’il s’agit d’une mauvaise utilisation du langage
lscpu | grep 'Processeur (s)' | awk '{print $ NF}'
au lieu de
lscpu | grep 'CPU (s)' | awk '{print $ NF}'
l
C’est possible, mais s’il faut traiter cela aux cas par cas, cela va être dur 
1 « J'aime »