Born to be wired

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.

22 commentaires pour “Winter is coming – S01E02”

  1. sylvain121

    Bonjour,
    Tu a tout a fait le droit de publier des spécifications techniques obtenu par reverse ingénierie au nom de l’interopérabilité.
    Si tu ne souhaite pas les publier, je suis malgres tout très intéressé par ton document, car j’ai également commencer l’analyse de la télécommande airton, mais a l’oscilloscope numérique.
    Ton aide me ferais gagner beaucoup de temps.
    merci

  2. AlphaK

    Ça me plairait vraiment de les publier. Mais l’article L. 122-6-1 du Code de la propriété intellectuelle comporte quelques aspects qui ne me paraissent pas aussi simplistes. Il faut que j’en touche un mot à une assistance juridique afin de lever les ambiguïtés, qu’il s’agisse de la diffusion publique ou de la communication à un tiers.
    J’ai besoin de quelques jours pour traiter ces aspects.

  3. Ohohuo

    Bonjour,

    Je me suis lancé bille en tête sur le projet de reguler mon climatiseur à l’aide d’un Arduino.

    Après quelques essais je suis vite tomber sur les premières aberration que tu as noté (meme code envoyé par différentes touches). C’est la que j’ai décidé de faire appel à la sphère internet, et je suis tombé sur ton site, qui m’a tout de suite éclairé sur les étapes suivantes à suivre.

    Mon climatiseur n’étant pas un airton, je vais devoir adapter un poil ta version de la bibliothèque Ir (c’est une premier pour moi de toucher au bibliothèque… J’espère aboutir rapidement).

    En tout cas merci pour cet article précis et pertinent… Il est pas impossible que je revienne te demander quelques explication sur la bibliothèque Ir si jamais je galère trop…

    Amicalement

  4. AlphaK

    Ravi de voir que mes pérégrinations dans le monde de l’infrarouge peuvent apporter un peu d’aide à ceux qui se lancent les mêmes défis 🙂

  5. Ced

    Salut,
    Ton article tombe a point ! Je suis en phase de recolte d’informations sur les ircodes Airton, et voila que je tombe la dessus… As tu progressé sur le decodage de la telecommande ? Je souhaite de mon cote l’adapter a ce fameux ESP8266 qui fait tant parler de lui actuellement.

    Cordialement

  6. AlphaK

    Bonjour,
    Alors j’ai une bonne, une mauvaise, et une bonne nouvelle.

    La bonne nouvelle, c’est que le décodage de la télécommande est entièrement terminé.
    La mauvaise nouvelle, c’est que si le reverse engineering est légal au nom de l’interopérabilité, la publication du résultat de ce reverse engineering n’est autorisée que dans un cadre extrêmement borné. À ce titre, je ne rendrai pas ces informations publiques, même si j’ai pu trouver au moins une jurisprudence que je qualifierais de « permissive » pour un cas de figure similaire.
    L’autre bonne nouvelle, c’est que j’ai un peu gambergé ces derniers jours, et que j’ai finalement trouvé une solution acceptable qui permettrait de répondre à ta requête. Il faut maintenant que je mettre cette solution en place, c’est l’affaire d’une ou deux semaines. Je sollicite donc encore un peu de patience, mais cette fois je tiens le bon bout…

    Concernant l’ESP8266, je vois que les grands esprits se rencontrent. J’ai découvert ce chip cet été, et n’ayant pas encore réalisé l’interco avec la partie radio, j’ai immédiatement pensé que ce chip serait une bonne opportunité de relancer le projet et de le terminer de belle manière. Affaire à suivre 🙂

  7. Ced

    Salut,
    Super, je vais attaquer l’emetteur IR pour mon groupe Fujitsu car j’ai pu trouver facilement les ircodes pour ce dernier et j’attend avec impatience ton retour pour les Airton !
    A bientot, donc

  8. squamata

    Bonjour,

    Merci pour ton travail. J’ai une PAC Airton mais j’ai du adapter tes sources pour que cela fonctionne chez moi.
    L’entête est différent, la longueur de trame aussi mais tout marche après quelques réglages ( réception et émission IR, encodage et décodage de trame).
    J’ai un petit problème sur le calcul du checksum qui est chez moi sur 4 octets, je n’arrive a calculé les 2 premiers octets mais j’arrive a allumer et éteindre la PAC dans le mode,température,vitesse ventillo et brassage voulu.
    Pour la communication, j’ai choisi un module rf433mhz ( j’ai un rfxcom ), j’attends de le recevoir.
    Cordialement

  9. AlphaK

    @squamata : chez moi, le checksum est sur un seul octet. J’avais également initialement prévu une commande sur 433 MHz grâce au RFXcom, mais n’ayant pas encore réalisé cette étape je suis en train de me réorienter sur un ESP8266. Affaire à suivre…

    À tous : après une période d’oisiveté prolongée, j’ai enfin repris un semblant d’activité sur ce sujet. D’ailleurs, un nouvel article tout frais tout chaud est là pour le prouver.

    Autre annonce concernant cette fois le document de spécifications, j’ai enfin trouvé et mis en place une solution. Les intéressés devraient recevoir un email d’ici une quinzaine de minutes, tout au plus.

  10. squamata

    Bonjour,
    J’ai une télécommande YR-H77 pour ma PAC Airton. Le checksum est effectivement sur 1 octet. L’avant dernier octet était en faite un code de touche.
    Ca marche complètement chez moi, Je n’ai pas été convaincu par les modules RF433. J’ai des murs de 80cm et même avec une antenne cela a du mal a passer. Il faut mettre l’émetteur sur du 12V, ça devient galère…
    En attendant la réception de l’ESP8266, je me suis rabattu sur un shield Ethernet qui traînait chez moi.
    Enfin voila, ma télécommande est presque retro-ingénieurés, reste plus que les contrôles des limites ( position interdit du sweep pour certain mode, température min/max, …)
    Cordialement

  11. AlphaK

    Excellente nouvelle !

    J’ai enfin commandé quelques ESP8266 pour avancer aussi dans cette direction, ils sont en cours d’acheminement. J’ai regardé très rapidement les divers documents que je possède sur ce chip, là où j’ai un gros doute, c’est sur sa capacité à générer du PWM à 38 kHz pour faire clignoter la LED IR. La limite semble être à 1 kHz.
    J’envisage dans ce cas 3 possibilités :
    – Ne pas faire de PWM et allumer complètement la LED sur émission d’un niveau haut, pas très élégant, mais sur un malentendu ça fonctionnera peut-être.
    – Utiliser un NE555 pour gérer le clignotement.
    – Envoyer les données à émettre à un petit chip type Attiny qui pourra se charger du PWM à la bonne fréquence.

    À ce stade, rien encore de très concret, mais ça pourra peut-être t’aider. N’hésite pas à partager tes avancées !

  12. squamata

    Si tu as une led IR en 38kHz ca ira,le PWM suivra.Je n’ai pas l’explication mais ca marche. Les librairies type IRremote le font très bien.
    Par contre la puissance est beaucoup plus faible qu’une télécommande normal. Il ne faut pas la mettre très loin du récepteur. Avec la camera d’un téléphone, on voit bien la différence entre les 2.
    J’ai aussi commandé un ESP8266 pour voir.
    On peut partager notre code, je suis parti de la version du github de IRremote, reporté tes modifications et adapté a ma télécommande.

  13. AlphaK

    Je ne suis pas sûr qu’on parle de la même chose : les libs IRremote pour Arduino génèrent effectivement du 38 kHz sans problème, en positionnant les valeurs adéquates dans les registres du chip, car celui-ci est en mesure de sortir cette fréquence (c.f. IRremoteInt.h). Mais le ESP8266 d’après ce que j’ai lu est limité à 1 kHz, et il s’agirait d’une limite matérielle.
    De plus la lib IRremote est compatible avec un ensemble de chips mais d’après la dernière version en date sur GitHub, l’ESP8266 n’est fait pas partie.
    J’ai donc encore encore de sérieux doutes sur la partie PWM et par mesure de sécurité j’ai commandé quelques NE555 avec mes ESP8266. On verra d’ici quelques semaines ce qu’il en est.

    Pour ce qui est de la puissance de ta LED, est-elle connectée directement en sortie de l’Arduino en série avec un résistance de 1 kΩ comme c’est le cas sur mon schéma ? Si c’est le cas, le courant la traversant est de l’ordre de grandeur de 4 mA, c’est une valeur volontairement peu élevée. Tu peux diminuer la valeur de R1 pour augmenter le courant et augmenter l’intensité lumineuse, dans la limite de ce que peut proposer l’Arduino et de ce qui est supporté par ta LED. À vue de nez je dirais de ne pas descendre sous la barre des 220 Ω.

    Pour ce qui est du partage du code, je mettrai en ligne le mien sur la page de téléchargements. Si tu as un lien vers le tien (GitHub ou autre) ce serait intéressant si tu pouvais le mettre en commentaire afin qu’il profite également aux autres lecteurs.

  14. Ced

    Je n’ai pas encore eu le temps de m’y attaquer, mais il semblerait que generer du 38Khz soit possible avec l’ESP8266 : lien pour info : http://internetofhomethings.com/homethings/?p=899

    A bientot

  15. AlphaK

    Merci pour le lien, l’article est très détaillé et très intéressant.

    La conclusion est donc que l’ESP8266 ne peut pas générer du 38 kHz par l’API PWM, mais qu’il peut le faire d’une autre manière, en l’occurrence la méthode utilisée utilise des sleep de quelques microsecondes. C’est moins élégant, c’est susceptible de poser des problèmes de transmission si des levers d’interruptions surviennent pendant les intervalles de sommeil (à confirmer), mais visiblement l’auteur de l’article a pu le faire fonctionner de cette manière, c’est donc une très bonne piste.

  16. squamata

    @AlphaK : Effectivement, on ne parle pas du même montage. Et je ne dois pas bien comprendre le fonctionnement de l’ESP8266
    Pourquoi utiliser l’API PWM de l’ESP8266 ? On a le module ESP8266 qui utilise que les pins TX/RX de l’arduino pour faire passer un message que l’on veut et la LED IR branchée sur une pin PWM de l’arduino. Pourquoi cela ne marcherai pas avec quelques lignes de code pour faire le buffer ?

    Mon module émetteur IR est comme ton module récepteur IR(sur ton schéma), c’est une petite carte avec une LED IR (38kHz) avec des résistances en CMS, donc pas de marge de manœuvre pour la puissance d’émission. Mais cela passe chez moi, c’était juste pour prévenir. Les télécommandes sont puissantes par rapport a un Arduino !

    J’aimerai bien qu’on en discute en MP pour le code.
    J’ai peut etre fait des choix douteux. Il y a sans doute un peu de taf avant la publication.

  17. Ced

    Je suis en cours d’implementation pour la version ESP8266, mais il y a une chose qui me laisse perplexe, quel sont les roles de « current temperature » et de « target temperature » ??
    @+

  18. AlphaK

    @squamata:

    Avant tout, il existe probablement un très grand nombre de solutions pour arriver au résultat que l’on souhaite. Le choix d’une méthode par rapport à d’autres peut être fonction de nombreux facteurs (composants électroniques disponibles, aspects pratiques, fiabilité, budget)…

    Alors, pourquoi je me focalisais sur l’API PWM de l’ESP8266 : parce que l’API PWM est un moyen rigoureux et fiable pour générer un signal carré. Rigoureux car une fois la broche mise à 1, le PWM est géré de manière autonome par le chip, en temps réel, jusqu’à ce que la broche passe à 0, et fiable car puisque le chip gère le signal PWM de manière autonome, il n’est pas nécessaire d’écrire du code qui va alterner explicitement les états hauts et bas sur la broche, ce type de code malgré son apparente simplicité pouvant se révéler complexe à gérer en fonction des interruptions, et donc au final pas obligatoirement exécuté en temps réel, et par effet de bord, non fonctionnel.

    Faire communiquer un ESP8266 et un Arduino par les pins Tx/Rx est tout à fait faisable, je n’ai aucun doute là dessus. En revanche, je garde à l’esprit 2 aspects :
    – La liaison série de l’ESP8266 fonctionne en 3.3V, celle de l’Arduino en 5V. Il faut donc obligatoirement prévoir un étage d’adaptation des niveaux de tension. Rien de dramatique ni de bien compliqué, mais ça rajoute des composants sur le montage. Si je pouvais trouver mieux, ça m’arrangerait.
    – Un Arduino tout entier à 25€ juste pour réceptionner un code de quelques octets sur une liaison série puis faire clignoter une LED, ça fonctionne, mais c’est un peu trop à mon goût. Je préfère conserver mon Arduino pour prototyper sur d’autres projets, et confier cette tâche à un AtTiny à 1€ par exemple, qui fera le même travail tout aussi bien 🙂

    OK, je comprends mieux pour ton émetteur.

    Pour la discussion autour du code de l’Arduino, je te remercie de l’intérêt que tu portes à ce montage, mais je préfère passer mon tour : transposer le code de la télécommande sur Arduino est un projet que j’ai terminé depuis déjà plus de 2 ans, mes articles récents consacrés à ce thème étant dus à un long retard dans le process d’écriture. C’est un sujet qui est clos pour moi, j’ai maintenant la suite en tête et plus vraiment de temps à consacrer à ce montage précis. Je pense que tu seras néanmoins en mesure de trouver des avis éclairés sur des forums spécialisés.

    @Ced:

    Target, c’est le plus évident, c’est la température souhaitée. Current, c’est la température actuelle de la pièce mesurée par la télécommande. J’imagine qu’en donnant à la PAC la température de la pièce, certains modèles sont capables d’ajuster la puissance pour atteindre plus efficacement la température souhaitée.

  19. Ced

    Salut, apres un long (…) moment, j’ai enfin reussi a trouver du temps pour bricoler l’IR de ma clim AIRTON… J’ai ete assez desapointe car ton papier ne correspondait pas a mon model (encodage temp, nombre d’octets envoyes, etc.), ma telecommande est de reference YKRH. Mais je n’ai pas desespere, je me suis achete un bitscope et j’ai pu faire une analyse des signaux envoyes. J’aurais bientot termine le module pour l’ESP qui fonctionne pour quasi toutes les fonctions sauf le balayage et la vitesse de ventilation. Si ca interresse quelqu’un, je pourrais rendre public les donnees.

    Merci en tout cas pour le point de depart !!
    ++

  20. Ced

    Bon, ben voila, c’est termine, toutes les fonctions sont operationnelles, du coup j’ai rajoute les IR codes pour les clims fujitsu (pas encore teste), c’est la prochaine etape pour ce soir 🙂

    Le code pour ESP completement libre de droits et facilement adaptables a d’autres uControlleurs : https://github.com/cedricp/espAirCond

    Pour l’IR j’ai opte pour la methode qui consiste a compter le nombre de cycles CPU (ici 38Khz avec un duty cycle de 33%) en ayant pris soin de desactiver les interruptions CPU pendant la transmission. je peux donc controller ma clim depuis mon smartphone Android maintenant (en plus de l’eclairage exterieur est le systeme de filtration de la piscine).
    En esperant que ca puisse servir a d’autres… Bonne bidouille 🙂

  21. AlphaK

    Je réponds avec beaucoup de retard, mais merci pour ce feedback, pour le partage de tes sources, et pour les explications qui vont avec sur le décompte des cycles CPU.
    J’ai du mettre temporairement de côté ce projet pendant quelques semaines, il me reste un article à rédiger sur la partie Arduino/Attiny, et je pourrai enfin entreprendre les travaux définitifs sur ESP8266. Ton code constituera une aide et un gain de temps précieux !

  22. Ced

    Si ca peut aider ! Au fait l’ESP tourne depuis 1 mois maintenant sans aucun probleme… N’hesite pas a me contacter si besoin de quoi que se soit.

Laisser un commentaire