Born to be wired

Archive pour la catégorie ‘Domotique’

 SMS automatisé – Extra Bonus Round Dash EX Plus Alpha

 28 décembre 2015  Domotique  Aucun commentaire

Contre toute attente, ce sujet dont je pensais avoir épuisé toutes les anecdotes techniques revient sur le devant de la scène. Pourquoi donc ? Car il y a peu de temps, après une longue période de fonctionnement sans faille, j’ai constaté que mon système d’envoi de SMS à base de modem GSM Wavecom n’était plus capable de communiquer. Impossible de finaliser le moindre envoi… Pourquoi ? Comment ? À quelques semaines de la Saint Sylvestre, je m’en serais voulu de ne plus être capable de spammer la bonne année à tous mes contacts. Retour arrière, à contrecœur, sur une solution qui donnait entière satisfaction.

Disons le immédiatement, je n’ai pas de certitude absolue quant à la cause du problème. Lors de la découverte, après les investigations de circonstance, j’ai noté les éléments factuels suivants :

(suite…)

 Winter is coming – S01E03

 10 novembre 2015  Domotique  17 commentaires

Précédemment, sur AlphaK.net : j’ai réussi à capturer les codes infrarouges envoyés par la télécommande de ma clim réversible Airton CSH-12, et à en comprendre le fonctionnement. J’ai même rédigé, avec rigueur et amour, un document de spécifications sur le sujet, que je ne peux malheureusement pas rendre accessible en libre téléchargement sur ce site, pour des raisons légales. L’étape suivante consiste à remplacer la télécommande d’origine par un Arduino et lui faire émettre les mêmes codes. Allais-je y arriver ? C’est sur ce cliffhanger insoutenable que l’épisode précédent s’était arrêté, plongeant l’ensemble de mes lecteurs dans un état d’angoisse sans précédent. C’est justement là que nous reprenons le fil de l’histoire. (suite…)

 SMS automatisé – Bonus round

 6 novembre 2014  Domotique  2 commentaires

Le thème de l’envoi automatisé de SMS, je pensais l’avoir traité en long en large et en travers, alors je m’étais jugé que je n’en reparlerais plus. Il faut dire que ça marchait plutôt bien. Ça fonctionnait tellement bien, que parfois, je recevais même des mignons petits messages de gentils inconnus qui s’étaient malencontreusement plantés de numéro, dans ce genre là :

sms-spam

Et il faut le dire, parfois, dans ce cas-là, j’hésitais à répondre. Et parfois, dans ce cas-là, le choix de réponse était cornélien, comme si cela entrainait des répercussions capitales sur tout le reste de ma longue et héroïque quête de l’aventure humaine : (suite…)

 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.

 SMS automatisé – Final round

 8 décembre 2013  Domotique  Aucun commentaire

Maintenant, terminé les enfantillages. Envoyer des SMS en ligne de commande à des gens avec un nom rigolo, c’est très amusant, mais ça montre rapidement ses limites. Pour aller plus loin, il faut mettre en place un système capable de gérer de manière autonome les échanges avec la carte SIM, et de proposer une interface de communication à la fois simple, robuste, et utilisable par un grand nombre d’applications.

La base de données est une interface idéale pour cela, et il existe justement un système qui peut l’utiliser comme backend pour communiquer avec le modem GSM. Ce système, c’est gnokii-smsd.

(suite…)

 Winter is coming – S01E01

 14 octobre 2013  Domotique  1 commentaire »

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.

 Kit de survie du VDI

 26 août 2013  Domotique  5 commentaires

Après avoir tant bassiné mon lectorat (lectorat au singulier, avec un seul lecteur dedans) au sujet de la mise en place d’un réseau voix/données/images dans une rénovation d’appartement, je ne pouvais tirer ma révérence sur ce thème sans donner un aperçu de quelques-uns des outils que je n’hésite presque pas à présenter comme étant le meilleur investissement de ma vie.

Absolument, sérieusement, car ces outils ont déjà sauvé des vies. Oui, sans déconner. Enfin je veux dire, ont déjà sauvé la vie de plusieurs personnes qui ne peuvent survivre sans internet (y compris l’auteur de cet article).

Sans plus attendre, voici un bref tour d’horizon des must-have de tout câbleur réseau un minimum sérieux : (suite…)