Bonjour à tous,
Afin de garder un œil sur un petit serveur domestique que je suis en train de monter, je souhaite pouvoir consulter les températures internes en temps réel. La machine cible est un ordinateur personnel Lenovo Thinkcentre tournant sous Debian 9 sans serveur graphique et sans écran (ni clavier ni souris d'ailleurs). l'idée serait de fabriquer une sorte de rhéobus simpliste que j'intégrerais dans la face avant du boitier de l'ordinateur. Actuellement j'utilise le paquet lm-sensors par SSH pour afficher les températures des 4 cœurs du CPU mais c'est peu pratique au quotidien et nécessite un terminal.
Mes différentes recherches n'ont pas vraiment répondu à ma question : existe-t-il une bibliothèque permettant d'exposer ces températures afin d'être récupérées par une carte Arduino et d'être affichées sur un écran quelconque (LCD, OLED) ?
Une première piste serait d'écrire un minuscule script python qui balancerait les valeurs à travers un port COM à destination de l'Arduino mais je n'ai que peu d'informations à ce sujet.
Si une âme a déjà tenté l'expérience ou a quelques éléments de réponses, qu'elle n'hésite pas à nous en faire part 
Coco729
En fait, j'ai l'impression que vous voulez faire un tout petit émulateur de terminal avec l'arduino, qui peut être branché sur un port serie USB et est vu comme un port série. Côté PC, la commande "sensor" renvoye des tas de lignes lm-sensors / Wiki / Debian-facile, qui peuvent être filtrées par "
sensor | grep temp > ${nom_du_port_arduino}
" (lje ne me souviens plus du nom du port Arduino: ce n'est certainement pas un COM...)
pour tester cette ligne de commande, voir ce que donne "sensor | grep temp"
Coté Arduino, on peut finir le filtrage et afficher sur un petit écran ce que l'on recoit...
J'avais effectivement pensé à envoyer le résultat brut d'un sensors | grep vers le port USB mais cela me semblait être une méthode peu robuste dans le sens où si un jour la syntaxe de ce que renvoi sensors change, le grep risque de transmettre n'importe quoi à la carte.
Je vais tout de même explorer cette piste en premier
dans le sens où si un jour la syntaxe de ce que renvoi sensors change
Seulement si ton hardware change.
Éventuellement si tu veux te simplifier la vie tu peux retrouver les valeur dans /sys :
sensors
cat /sys/bus/platform/devices/coretemp.0/hwmon/hwmon2/temp1_input
cat /sys/bus/platform/devices/coretemp.0/hwmon/hwmon2/temp2_input
cat /sys/bus/platform/devices/coretemp.0/hwmon/hwmon2/temp3_input
cat /sys/bus/platform/devices/coretemp.0/hwmon/hwmon2/temp4_input
cat /sys/bus/platform/devices/coretemp.0/hwmon/hwmon2/temp5_input
Ce qui donne :
nouveau-pci-0100
Adapter: PCI adapter
fan1: 900 RPM
temp1: +33.0°C (high = +95.0°C, hyst = +3.0°C)
(crit = +105.0°C, hyst = +5.0°C)
(emerg = +135.0°C, hyst = +5.0°C)
asus-isa-0000
Adapter: ISA adapter
cpu_fan: 0 RPM
coretemp-isa-0000
Adapter: ISA adapter
Physical id 0: +38.0°C (high = +80.0°C, crit = +98.0°C)
Core 0: +36.0°C (high = +80.0°C, crit = +98.0°C)
Core 1: +37.0°C (high = +80.0°C, crit = +98.0°C)
Core 2: +35.0°C (high = +80.0°C, crit = +98.0°C)
Core 3: +33.0°C (high = +80.0°C, crit = +98.0°C)
38000
36000
37000
35000
33000
Si cela peut aider ...
Ça a l’air effectivement plus simple de récupérer les valeurs depuis le /sys.
En revanche un mystère subsiste quant à mon projet, je n’avais jamais vraiment remarqué que l’ouverture du moniteur série de l’IDE réinitialisait la carte, il en est de même pour une transmission de données depuis un terminal. De ce fait, le moindre envoi de données vers le périphérique ttyACM0 (carte Arduino branchée) provoque systématiquement un reset de la carte... Il m’avait pourtant semblé avoir réussi à afficher le résultat de la commande « ls > /dev/ttyACM0 » sur un écran LCD 2 lignes.
J’imagine que l’idee serait de maintenir active la connexion série avec la carte.
Le DTR d'un port série est toujours activé à l'ouverture. Côté ARDUINO le DTR est branché sur le reset, à travers un petit condensateur.
Solution : ouvrir le port de communication une bonne fois pour toutes côté PC
D’après le manuel de la commande stty, l’option -hupcl permet de désactiver l’envoi d’un signal de déconnexion sur la communication série spécifiée. Après essai, la carte se réinitialise une première fois puis reçoit les valeurs de température en continue.
Oui, mais il n'y a pas d'inconvénient à laisser un port ouvert ad vitam eternam.
Tout dépend de ce que tu vas mettre en place côté PC.
Si c'est un script python, autant laisser le port ouvert.
Si c'est un cron avec un script bash qui fait des echo > /dev/ttyUSBX, utilise la solution stty.
Si le device USB série est unique il s'appellera toujours /dev/ttyUSB0, par contre s'il y en a plusieurs ce ne sera peut-être pas le cas.
Afin d'éviter les problèmes d'ouverture, il y a moyen avec udev rules de fixer le nom du device et lui attribuer un nom fixe en fonction du idVendor et même du numéro de série du convertisseur.
https://www.raspberrypi.org/forums/viewtopic.php?t=90265
Mais tu sais peut-être déjà ...