Born to be wired

Archive pour juillet 2014

 Winter is coming – S01E02

 29 juillet 2014  Domotique  22 commentaires

Publier un article qui traite du pilotage automatique du chauffage en plein été, il fallait oser. Mais bon, à mon rythme actuel de publication, le prochain article pourrait bien voir le jour en décembre 🙁

À vrai dire, le but de cet article étant le pilotage automatisé de ma climatisation réversible, des avancées sur le sujet sont toujours les bienvenues, été comme hiver.

Bref, pour ceux qui sont un peu largués, voici le résumé de l’épisode précédent : en branchant un récepteur infrarouge à un Arduino, j’ai pu commencer à récupérer les différents codes envoyés par la télécommande de ma clim réversible. Les codes en question étaient reconnus en tant que protocole NEC, mais l’appui sur différentes touches donnait toujours le même code. Il y avait donc un truc qui cloche, et j’allais devoir me creuser le citron pour trouver ce que c’était…

Avant d’aller plus loin : cet article est assez technique. Toute lecture effectuée cerveau débranché en période de congés se fait à vos risques et périls.

Donc, à ce stade de l’aventure, je me pose quelques questions sur la fiabilité de la bibliothèque de décodage de codes infrarouges (lib IRremote de Ken Shirriff) que j’ai récupérée. Celle-ci soutient que le protocole utilisé par ma télécommande Airton est du NEC, alors que de toute évidence ça ne peut pas être du NEC. Afin d’en avoir le cœur net, je tâtonne en regardant ce que la sortie du programme affiche avec différentes télécommandes. Le programme ne les reconnait pas toutes, mais il ne me sort pas forcément du NEC pour tout et n’importe quoi. J’obtiens un minimum de cohérence lors de mes essais.

Essais par tâtonnement  grâce aux diverses télécommandes à ma disposition.

Essais par tâtonnement grâce aux diverses télécommandes à ma disposition.

Laissons-nous un instant nous imprégner par l’esprit de déduction du grand Sherlock Holmes, légèrement imbibé à la cocaïne pour bien clarifier l’esprit : si le programme (en l’occurrence la lib de décodage) me soutient mordicus que ce que je lui envoie est du NEC, c’est parce qu’il croit que c’est du NEC. Magnifique démonstration de ce qui saute aux yeux. Il faut donc plonger à l’intérieur, comprendre comment il décode les différents signaux, et lui donner les moyens de différencier mon protocole Airton du protocole NEC. En parallèle, un peu de culture générale sur les protocoles infrarouges (ci-joint : document PDF) permet de mieux appréhender les différents concepts rencontrés dans le code.

Puisque l’appui sur des touches différentes de la télécommande donne le même code selon le programme, c’est certainement parce que celui-ci arrête le décodage du signal trop tôt. Élémentaire, mon cher Watson. Pour le protocole NEC, la limite est connue à 32 bits de données. Mais pour Airton le nombre de bits à décoder est peut-être plus important. Je modifie donc le programme pour continuer la détection sur du NEC même si les 32 bits attendus ont déjà été trouvés. Et là, c’est tout de suite probant ! Le programme me trouve toujours 32 bits pour une véritable télécommande NEC, mais 48 bits pour ma télécommande Airton. On peut donc commencer l’analyse en appuyant sur toutes les touches.

Le protocole Airton est maintenant clairement différencié du NEC.

Le protocole Airton est maintenant clairement différencié du NEC.

Malheureusement l’analyse est de courte durée, car malgré les 48 bits affichés, je trouve encore de nombreux boutons de ma télécommande qui affichent le même code. Alors, tel l’extracteur devant pratiquer une inception, je plonge dans un niveau encore plus profond du code. Et je découvre que le coupable, c’est un buffer, qui est utilisé tous protocoles confondus, dont la taille est trop faible. Ce buffer est capable d’enregistrer les durées relatives à 100 alternances de niveaux de tension hauts ou bas. M’étant au préalable documenté sur les différents protocoles IR, je sais qu’un bit est généralement codé par 2 niveaux de tension successifs dont les durées, ou dont la phase, diffèrent en fonction du bit à transmettre. Par exemple, pour NEC, un appui sur une touche de la télécommande génère un en-tête codé sur 2 niveaux de tension d’une durée spécifique, suivi de 32 bits, suivi d’un bit stop, ce qui donne 2+32*2+2 = 68 alternances, nombre inférieur aux 100 alternances enregistrables. Mais dans mon cas, avec un en-tête du même type, suivi de 48 bits, plus un bit de stop, on obtient un total de 2+48*2+2 =100 pile, comme par hasard. Je suis donc arrivé à la limite du buffer et je dois augmenter celui-ci pour capturer plus de bits. Je décide de le passer arbitrairement à 300. La taille du buffer est donnée par la constante RAWBUF dans IRremote.h.

Avec cette manipulation, j’arrive enfin à un signal décodé sur 120 bits (15 octets tout de même), codé sur 244 alternances, ce qui reste inférieur à ma nouvelle limite de 300 alternances capturables. Cette fois-ci, on peut reprendre l’analyse en appuyant sur toutes les touches de la télécommande et en relevant les codes affichés. Je me rends compte au passage que, même si cette fois-ci j’obtiens bien des codes différents pour chaque bouton pressé ou fonction activée, je ne comprends pas la logique dans le codage de la température souhaitée. Et pour cause, le signal est envoyé bit de poids faible d’abord (LSB first), comme pour NEC. En réalité, les deux protocoles ont de nombreuses similitudes, Airton s’étant probablement fortement inspiré de la structure du protocole NEC pour créer le sien. Un mode de transmission en LSB-first n’a donc rien d’étonnant. Je rajoute alors, dans ma version de la lib, une fonction permettant de convertir les données décodées avec bit de poids fort d’abord (MSB first) lorsqu’il s’agit de les afficher ; car en bons humains occidentaux moyens que nous sommes, on a plus de facilité à lire les nombres lorsque les dizaines sont indiquées avant les unités.

S’ensuit un appui sur toutes les touches de la télécommande, un dump complet des codes, un peu de réflexion pour faire correspondre un ensemble de bits à une fonction spécifique, et un petit cassage de tête sur le dernier octet qui ne correspond ni plus ni moins qu’à un checksum. Mais c’est la partie amusante de l’activité. J’arrive au final à comprendre l’intégralité de la structure des messages par rétro-ingénierie, que je consigne rigoureusement dans une documentation des plus carrées, que j’ai hâte de pousser sur la toile. Seul ombre au tableau à ce stade, je ne sais pas si un document obtenu par rétro-ingénierie du protocole dans un but d’interopérabilité est légalement diffusable. Je suis en train de me renseigner à ce sujet, je diffuserai donc le précieux document si j’en ai le droit dans un prochain article.

En attendant, ce que je peux diffuser sans problème, c’est l’adaptation de la bibliothèque IRremote qui est capable de reconnaitre le protocole Airton et d’en afficher les données brutes. La bibliothèque est dispo dans la section téléchargements (chercher « Airton Receiver for Arduino »). À ce stade, j’estime l’avancement du projet à environ 10%. C’est peu, il y a encore pas mal de boulot, mais avec un peu de chance certaines étapes seront plus simples. Ou pas.

La prochaine étape, pour moi, c’est maintenant l’émission d’un signal par l’Arduino, afin de valider qu’il est correctement envoyé et reconnu par le climatiseur. Pour cela, c’est très simple : on rajoute simplement une LED IR au montage. Le concept est le suivant :

ir-receiver-emitter-breadboard

ir-receiver-emitter-schematics

Mais le résultat de ce montage sera abordé ultérieurement.

Autrement dit, c’est tout pour aujourd’hui. Dans mon prochain article, je m’entrainerai à Surgeon Simulator sur un meuble Ikea.