Born to be wired
698236 visites
Uptime 22 days

Articles taggés avec ‘Arduino’

 Winter is coming – S01E02

 29 juillet 2014  Domotique  2 commentaires
winter-is-coming-s01e02

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.

 Winter is coming – S01E01

 14 octobre 2013  Domotique  1 commentaire »
house-stark-winter-is-comming

L’hiver vient. Après avoir automatisé le démarrage et l’arrêt des radiateurs de mon appartement grâce à l’installation de fils pilotes et d’une centrale de programmation, je souhaite vivement mettre en place une fonctionnalité similaire sur ma climatisation réversible. Elle constitue pour moi un moyen économique et rapide de chauffer ma pièce principale, il serait donc intéressant de pouvoir la déclencher de manière programmée, ou encore mieux, à distance, par exemple de manière automatique le matin avant que je me lève, ou manuellement à l’heure où je sors du travail, afin que la pièce soit déjà chauffée lorsque j’arrive chez moi.

Seulement, mettre en place un tel projet n’est pas évident. Ma clim de marque Airton n’est pas programmable. Je ne peux pas non plus automatiser son déclenchement en connectant son alimentation sur des relais, cela équivaudrait à couper brutalement le courant lorsque je demande un arrêt, ce qui n’est pas conseillé quand le climatiseur est activé.

Ma seule possibilité d’interaction avec l’appareil reste sa télécommande. Je dois donc trouver un moyen de récupérer les codes infrarouges envoyés par la télécommande et de les faire reproduire par un second dispositif automatisable.

Pour récupérer les codes de la télécommande d’origine, j’ai choisi de ressortir mon Arduino, qui jusqu’ici ne m’avait pas encore beaucoup servi, et de lui connecter un récepteur infrarouge issu d’un petit kit de développement commandé chez DealExtreme. J’ai effectué le câblage de la manière suivante :

ir-receiver-breadboardir-receiver-schematicsJe précise, pour ceux qui ne connaissent pas et qui voudrait réaliser des plans de câblage similaires, que ces schémas ont été réalisés avec le fabuleux Fritzing. Attention, selon le type de récepteur infrarouge utilisé, le brochage peut varier. Vérifiez la notice du composant en cas de doute.

J’ai récupéré et utilisé la bibliothèque de commande infrarouge pour Arduino développée par Ken Shirriff sur la page GitHub associée. Le blog de Ken Shirriff regorge également d’excellentes explications sur l’utilisation de cette bibliothèque.

J’ai enfin compilé et déployé le code suivant sur l’Arduino. C’est du quick and dirty, pour le test :

#include <IRremote.h>
int RECV_PIN = 11; //define input pin on Arduino
IRrecv irrecv(RECV_PIN);
decode_results results;

void setup()
{
	Serial.begin(9600);
	irrecv.enableIRIn(); // Start the receiver
	irrecv.blink13(true); // Blink LED 13 during IR reception
}

// Dumps out the decode_results structure.
// Call this after IRrecv::decode()
void dump(decode_results *results) {
	int count = results->rawlen;
	if (results->decode_type == UNKNOWN) {
		Serial.print("Unknown encoding: ");
	}
	else if (results->decode_type == NEC) {
		Serial.print("Decoded NEC: ");
	}
	else if (results->decode_type == SONY) {
		Serial.print("Decoded SONY: ");
	}
	else if (results->decode_type == RC5) {
		Serial.print("Decoded RC5: ");
	}
	else if (results->decode_type == RC6) {
		Serial.print("Decoded RC6: ");
	}
	else if (results->decode_type == PANASONIC) {
		Serial.print("Decoded PANASONIC - Address: ");
		Serial.print(results->panasonicAddress,HEX);
		Serial.print(" Value: ");
	}
	else if (results->decode_type == JVC) {
		Serial.print("Decoded JVC: ");
	}
	Serial.print(results->value, HEX);
	Serial.print(" (");
	Serial.print(results->bits, DEC);
	Serial.println(" bits)");
	Serial.print("Raw (");
	Serial.print(count, DEC);
	Serial.print("): ");

	for (int i = 0; i < count; i++) {
		if ((i % 2) == 1) {
			Serial.print(results->rawbuf[i]*USECPERTICK, DEC);
		}
		else {
			Serial.print(-(int)results->rawbuf[i]*USECPERTICK, DEC);
		}
		Serial.print(" ");
	}
	Serial.println("");
}

void loop() {
	if (irrecv.decode(&results)) {
		Serial.println(results.value, HEX);
		dump(&results);
		irrecv.resume(); // Receive the next value
	}
}

La carte est maintenant prête à recevoir les codes de quelques télécommandes. Afin d’afficher les codes IR reconnus par le dispositif, il est nécessaire de lancer le moniteur série de l’éditeur Arduino.

Montage sur platine d'essais, on ne peut plus simple.

Montage sur platine d’essais, on ne peut plus simple.

La plupart des télécommandes que j’avais sous la main ont été reconnues par le récepteur, à l’exception de ma télécommande Xbox. La LED du récepteur clignote lorsqu’il reçoit un signal IR. C’est d’ailleurs ce qui m’a permis de constater que mon écran PC parasitait le récepteur, j’ai donc pris soin de conserver une distance suffisante entre les deux appareils pour mes tests.

Je me suis par la suite focalisé sur le décodage des codes IR reçus, et affichés dans moniteur série. Sans surprise, la télécommande DealExtreme affiche les codes de télécommande NEC, tels que l’indique sa documentation.

La télécommande de mon climatiseur Airton est également reconnue comme utilisant le protocole NEC. En cherchant des informations sur ce protocole, j’ai trouvé entre autres cette synthèse, très bien réalisée. Elle m’a alors permis de vérifier si les codes IR reçus étaient cohérents par rapport au protocole reconnu.

decoded-ir-codes-with-raw-data

Attention, là, ça devient un poil technique :

La synthèse du protocole NEC m’apprend que celui-ci transmet une information sur 4 octets (soit 32 bits), plus un en-tête et un stop bit. Chaque bit 0 ou 1, ainsi que l’en-tête et le stop bit, sont codés par un niveau actif (émission de lumière IR) suivi d’un niveau inactif (pas d’émission de lumière), la durée de chacun de ces niveaux déterminant le type de bit codé. Pendant un niveau actif, l’émission de lumière n’est pas continue mais pulsée à la fréquence de 38 kHz. Enfin, sur les 4 octets, seuls 2 comportent une information utile, puisque les 2 autres contiennent un XOR de l’octet précédent avec 0xFF. Pour les novices en informatique, le XOR est un OU EXCLUSIF logique bit à bit, et n’a aucun rapport avec un personnage de fiction exerçant la profession de shérif de l’espace. Ici un XOR avec 0xFF revient à inverser chaque bit, donc 0 devient 1 et 1 devient 0.

Ainsi par exemple, au niveau de ma télécommande DealExtreme, le premier code remonté est FFA25D, ce qui correspond en réalité à une réception de 00FFA25D exprimé avec 32 bits. Les 4 octets sont 0x00, 0xFF, 0xA2, 0x5D. Le premier octet représente l’adresse (0), le second 0xFF correspond bien à l’inversion bit à bit de 0x00, le troisième octet 0xA2 représente la commande, et le quatrième 0x5D correspond bien à l’inversion bit à bit de 0xA2. Notez que la commande reçue 0xA2 est exprimée en LSB-first, bit de poids faible transmis en premier, et que si on la convertit en MSB-first, bit de poids fort transmis en premier comme l’être humain moyen a l’habitude de manier les nombres (en général on écrit les dizaines à gauche des unités), on obtient le code logique de commande 0x45, soit 69 en décimal.

La commande reçue correspond donc à un code 69 envoyé à l’adresse 0. Fin de la plongée dans le détail du protocole.

Si je regarde maintenant les codes reçus correspondants aux appuis de touches sur ma télécommande Airton, 2 points m’interpellent :

  • J’ai appuyé sur plusieurs boutons de ma télécommande, et tous sont décodés comme 6A8E0000 par le dispositif. Tous les boutons qui envoient le même code, c’est louche.
  • Au niveau de la structure du code reçu, si 0x6A est l’adresse, alors son inversion bit à bit devrait être 0x95, et non pas le 0x8E obtenu. De même, l’inversion bit à bit de 0x00 devrait être 0xFF, et non pas le 0x00 obtenu. Il y a donc vraiment quelque chose qui cloche.

Forcément, je m’attendais à ce que cela ne soit pas simple. La bonne nouvelle pour moi, c’est que le signal envoyé par la télécommande est bien perçu par le récepteur. La mauvaise, c’est que le récepteur ne semble pas décoder ce signal de la bonne façon. Il faut donc investiguer sur la bibliothèque de commande infrarouge, comprendre comment elle fonctionne, et probablement la modifier pour l’adapter aux spécificités de ma télécommande Airton. Mais ça, c’est pour une prochaine fois.

 Chauffage chauffage, plus loin que la nuit et le jour !

 7 octobre 2012  Domotique  1 commentaire »
Delta Dore Deltia 8.31

Comme certains le savent, mon activité rédactionnelle a été légèrement, mais alors très légèrement, perturbée par un déménagement survenu l’année dernière à peu près à la même époque. Déménagement qui fut suivi de quelques travaux de rénovation, qui, arrivant à leur terme, me permettent enfin de reprendre mon plus beau clavier pour narrer quelques effroyables expériences, et leur résultat, et en particulier celles contenant de vrais morceaux de high-tech dedans.

Le premier article de cette catégorie sera consacré à mes nouveaux radiateurs électriques. En effet, j’ai très vite voulu domotiser un minimum l’installation, et me donner la possibilité de réguler leur température de manière automatisée, en imaginant en point de départ le postulat basique suivant :

  • Lorsque je suis au travail, il n’est pas nécessaire de maintenir la température de confort dans l’appartement.
  • Le soir, la température de confort doit être rétablie juste avant mon retour.
  • Mes horaires de travail sont fixes d’une semaine sur l’autre.
radiateur

Radiateur aux commandes épurées : un bouton pour les gouverner tous.

Les premiers drafts

J’avoue que la première idée qui m’est passée par la tête, un peu avant d’emménager et lorsque j’ai commencé à m’intéresser à ces possibilités avec un collègue de travail qui avait la même problématique, c’est un système de relais qui coupe tout simplement l’alimentation des radiateurs lors des périodes d’absence. On imaginait déjà l’utilisation d’Arduinos pilotant des relais pour arriver à cette fin. Ce système présente néanmoins 2 défauts à mon sens :

  • Les notices des radiateurs, qui embarquent maintenant un peu d’électronique, préconisent de ne pas abuser de ce système consistant à couper violemment le courant.
  • En période d’absence courte (la journée de travail), il est recommandé de ne pas laisser la température trop chuter, sous peine de consommer plus d’énergie lors de la remontée en température suivante.

J’ai pensé qu’on pouvait faire mieux que ça.

Sur la piste du fil pilote

C’est en farfouillant le vaste monde d’internet à la recherche des notices PDF, puis en autopsiant le câblage électrique de mes radiateurs, que j’ai pris connaissance de l’existence d’un troisième fil en plus de la phase et du neutre, qui n’est pas un fil de terre : le fil pilote, aussi appelé contact auxiliaire. Pour les béotiens comme moi qui ne connaissaient pas cette fonctionnalité, c’est un fil de commande qui permet de passer le radiateur en mode confort, éco, hors gel, en fonction du signal envoyé sur le fil.

Courant à appliquer au fil pilote

Attention pour ceux qui seraient tentés de reproduire tout ou partie de l’expérience, même si l’ampérage est faible, c’est du 230V qui circule sur le circuit de commande, donc avant tout, prudence, et pas de conneries !

Problème de taille : le fil pilote n’était pas câblé jusqu’au panneau électrique. Seulement 3 fils circulent dans chacune des gaines : la phase, le neutre, et la terre. Des bidouilleurs peu scrupuleux pourraient avoir l’idée de réutiliser le fil de terre, qui ne doit pas être relié aux radiateurs, comme fil pilote, mais NAN, c’est pas bien, margoulins ! On fait les choses proprement, et pour cela, une seule solution : passer un quatrième fil dans la gaine. Ni une, ni deux, on s’y met. Je pars acheter 100m de fil noir au magasin de bricolage le plus proche (celui dont le jingle est « papadapa » et qui fait des marges horriblement outrancières sur chaque article, à un tel point qu’on se demande s’ils n’indexent pas le prix de la quincaillerie directement sur le taux de change de l’or). Je prends aussi un tire-fils en nylon d’une qualité exécrable, un paquet de talc en pharmacie, et tout mon courage. C’est parti pour l’opération « Décâblage / Recâblage ».

Opération « Décâblage / Recâblage / Pétage de câble »

À tous ceux qui ne savent pas : on ne tire pas un fil dans une gaine qui contient déjà des fils. C’est une connerie. Pour faire les choses proprement, on décâble la gaine et on recâble avec tous les fils d’un coup, unis et légèrement torsadé comme dans un triste triangle amoureux dont aucun d’entre eux ne sortira heureux. En l’occurrence, quand on commence ce type d’opération, on leur demande surtout de sortir de l’autre côté de la gaine, c’est déjà un objectif assez ambitieux en soi.

Là, je suis en train de me demander si je n’aurais pas dû intituler cet article « Câblage câblage, plus loin que la nuit et le jour ! » – Anyway…

Mes quelques conseils pour la bonne réussite de l’entreprise :

  • Attachez le premier fil dans le chas du tire-fils, recourbez l’extrémité du fil sur lui-même en l’entortillant sur une bonne longueur et en formant un « pas de vis » écarté.
  • Entortillez les autres fils sur le pas de vis ainsi formé. Chaque fil doit s’arrêter un peu plus loin, pour que le diamètre du tout grossisse progressivement et que ça ne forme pas un gros bouchon monobloc immonde qui va buter net dans le premier coude formé par la gaine.
  • Recouvrez le tout d’adhésif. J’ai utilisé de l’adhésif de masquage que j’avais sous la main. J’ai fait plusieurs épaisseurs contra-rotatives (ouahh, le terme ultra-technique pour se la péter dans les soirées de l’ambassadeur !),  3 épaisseurs en général, pour que le tout reste le plus solidaire possible.
  • Lubrifiez. Avec du talc. Mettez le paquet. À la place du talc il est possible d’utiliser du Yellow, il parait que ça fonctionne bien, je n’ai pas testé.
  • Ensuite, sortez votre joker « Coup de fil à un ami », ou « Coup de bigo à une proximité », selon votre longitude, et appelez une âme pure et musclée en renfort. Effectuer l’opération en solo relève du masochisme décadent. Et je sais de quoi je parle.
  • Positionnez une personne à chaque extrémité de la gaine, fraîchement équipées de gants. La première pousse dans la gaine et l’autre tire. Il est important d’effectuer ces actions en rythme. Communiquez.
  • Lorsque l’extrémité de la gaine accouche finalement d’un amalgame de fils électriques emmaillotés dans un adhésif qui aura probablement souffert pendant ce trajet éprouvant, savourez votre victoire autour d’une bonne bière.
Malgré tous ces judicieux conseils, il est possible que vous éprouviez quelques difficultés dans les situations suivantes :
  • Apprêtez-vous à souffrir si la longueur de la gaine est importante.
  • Apprêtez-vous à souffrir si le diamètre de la gaine est petit par rapport au nombre de fils à passer.
  • Apprêtez-vous à souffrir si le trajet de la gaine présente des coudes (surtout à partir du troisième).
  • Apprêtez-vous à être grave vénère et à avoir les boules au point de trucider la terre entière si le tire-fils pète au milieu du trajet (oui, c’est arrivé).
Malgré ces quelques difficultés, le recâblage de mes 3 radiateurs et de mon sèche serviettes s’est tout de même déroulé dans de bonnes conditions. Je remercie au passage Thierry qui a bien voulu se prêter à l’exercice calqué sur l’entrainement de l’équipe olympique de tir à la corde, tout ça pour mon bien-être futur.

Y’a-t-il un pilote dans le radiateur ?

En parallèle de la pose du fil pilote, j’avais commencé à imaginer des solutions bon marché pour lui transmettre l’information de commande. Là encore, pour actionner le mode confort et éco, j’avais immédiatement pensé à une programmation via Arduino et relais (décidément, c’est une maladie, je vois des Arduinos partout). Même si techniquement c’est déjà beaucoup plus propre que la solution précédente (car on actionne la commande et pas l’alimentation, et car centralisé au niveau du tableau électrique pour tous les appareils de chauffage…), et techniquement tout à fait viable, cela restait une solution trop custom à mon goût, présentant trop d’incertitudes. Je voulais pour une fois un équipement un peu plus professionnel. En parallèle, il existe sur le marché des centrales de programmation qui remplissent parfaitement ce rôle pour une centaine d’euros, et mon choix s’est porté sur l’une d’entre elles, la DELTA DORE Deltia 8.31.

Delta Dore Deltia 8.31

La suite au prochain article…

 Testons hardiment et ardemment le hardware de l’Arduino

 1 décembre 2010  Bricolage  Aucun commentaire
hello_arduino

Une fois n’est pas coutume, et sans vouloir céder à la tendance des déballages de produits qu’on rencontre de plus en plus sur la partie fadasse de la blogosphère 2.0, je vais exceptionnellement publier quelques photos d’un déballage maison et d’un petit test de matériel. Car j’ai eu la chance de me faire prêter, comme l’indique le titre, un Arduino ! Et même plusieurs !

Un grand merci à Romain pour m’avoir spontanément proposé de tester ce merveilleux matériel.

Mais je vois déjà mes (trois) lecteurs déconcertés, à la limite du décrochage, qui se posent des questions. Et je lis sur leurs lèvres : C’est quoi, un Arduino ?

Un condensé de technologie si flexible dans une si petite surface !

Un condensé de technologie si flexible dans une si petite surface !

Un Arduino, c’est un peu le rêve des bidouilleurs en herbe. C’est une plate-forme électronique open-source pouvant être programmée et interfacée avec de nombreux autres systèmes, par de nombreuses possibilités de communication. C’est encore trop vague ? Alors disons que c’est une carte qui permet à des bidouilleurs de faire communiquer très facilement des systèmes informatiques divers et/ou/avec des systèmes électroniques divers. Comme avec le Meccano, les possibilités sont infinies.

Une partie du matériel gentiment prété par Romain

Une partie du matériel gentiment prété par Romain

Il y a quelques mois en arrière, dans la même optique de bidouillage, mais dans un registre un peu différent, j’avais acheté un PIC et un peu de matos pour le programmer. L’ennui, c’est que même si un PIC est hyper flexible dans sa programmation, il n’en reste pas moins dénué de périphériques, et il faut donc avoir des connaissances un peu plus que basiques en électronique pour piloter des appareils externes. Je comptais d’ailleurs me limiter au pilotage de circuits TTL et de quelques LED avec cette puce.

Mais l’Arduino change tout. Disposant de bibliothèques pour la programmation, flashable par USB, connectable à différents modules dédiés et a des prix raisonnables, et enfin open source, le dispositif est très séduisant. Ça tombe bien, je me disais que ça serait le périphérique parfait pour gérer une installation domotique. Par exemple, on pourrait imaginer de lui greffer un détecteurs de gaz, des relais électriques, ou des détecteurs de portes ouvertes, ou même plusieurs de ces composants en même temps.

En bonus dans la boite, quelques relais, un buzzer, et un servo

En bonus dans la boite, quelques relais, un buzzer, et un servo

On pourrait imaginer plusieurs Arduino communiquant dans la maison ou l’appartement en mode maître/esclave via des liaisons RF.

Y'a qu'à demander, des modules radio en veux-tu en voila !

Y'a qu'à demander, des modules radio en veux-tu en voila !

On pourrait imaginer le maître relié au réseau local grâce à un module Ethernet, pilotable ou interrogeable via ce biais. Et on pourrait même envisager un affichage des information sur un écran à cristaux liquides, TFT, ou même un touch screen ! Il y a vraiment de quoi s’amuser.

Le shield Ethernet connecté sur l'Arduino

Le shield Ethernet connecté sur l'Arduino

À titre d’exemple, Romain voulait se servir de l’Arduino pour piloter ses radiateurs électriques, de manière automatique en fonction de l’heure, ou à la demande. Il est parti sur un petit bout de code que j’ai un peu étayé durant la période de prêt, afin d’obtenir un draft d’interface de pilotage via un navigateur web.

Le matériel de base pour mon expérience

Le matériel de base pour mon expérience

Pour mes essais, je suis parti avec le minimum de matériel : 1 Arduino, 1 shield Ethernet, une batterie, un câble USB. Et pour le confort : un switch, des câbles RJ-45, un PC pas trop à la ramasse et mes petits doigts pour coder. :)

On mélange les ingrédients, on ajoute une pincée de code, on enfourne 30 secondes et on laisse reposer à feu doux

On mélange les ingrédients, on ajoute une pincée de code, on enfourne 30 secondes et on laisse reposer à feu doux

Grâce au module Ethernet et aux bibliothèques qui gèrent son fonctionnement, je suis arrivé à obtenir en quelques lignes de code un petit serveur web personnalisé sur une carte électronique autonome de 10cm de long !

En quelques lignes de code, une page web commandant les périphériques !

En quelques lignes de code, une page web commandant les périphériques !

OK, les inconditionnels de l’embarqué et du temps réel me hurleraient dessus en voyant le code, tellement j’ai développé ça comme un porc en codant avec les pieds et dans la hâte. Mais le draft fonctionne et démontre les possibilités étonnantes qu’on peut obtenir de ce hardware en quelques minutes.

Dans mon cas, les radiateurs ne sont bien sûr pas branchés. Ça ne servirait à rien, de toutes façons. Je fonctionne au chauffage central.

Une petite réflexion pour finir, sur les optimisations possible d’un tel système : Compte tenu de la mémoire limitée dans ce type de matériel embarqué, on pourrait imaginer que l’Arduino renvoie simplement une page XML, donc non verbeuse et réduite au minimum, qui serait formatée via une XSL externe, et qui proposerait tout l’habillage CSS et Ajax pour se la péter quand on montre à ses potes comment on fait du remote-heating-control depuis le boulot. :)

C’est décidé, je mets l’Arduino sur ma liste de courses.