Présentation

L'ESP8266 est un petit module Wifi très bon marché (de l’ordre de 2,80€ port compris au jour de l’écriture de ce billet).
Il permet à l’origine de s’interfacer en serial avec d’autres périphériques et donc de faire de l’UART vers Wifi. Par exemple pour qu’un Arduino puisse se connecter à Internet pour récupérer la météo, ou envoyer la température d’un radiateur.
Son faible coût et ses capacités croissantes (firmwares alternatifs, nouvelles versions hardware) ont font un candidat sérieux pour tous les “objets connectés”.

Par rapport à un module 433MHz du même ordre de prix, les avantages principaux sont:

• Possibilité de se passer d’Arduino etc.. Le module peut etre flashé pour mettre son propre firmware et donc faire un peu ce qu’on veux (dans la limite de ce qu’autorise 80Mhz).
• On ne se soucie plus d’implémenter un protocole, de mettre du “manchester” etc… On est direct en TCP/IP classique pour nos applications.
• On bénéficie du chiffrement Wifi. (WPA/WPA2)
• Il y a des GPIOs (le nombre dépend des modèles)
• La portée semble tout a fait correcte et on pourra donc installer un module partout ou le signal Wifi peut être capté… Et donc généralement n’importe ou dans la maison.

Le seul bémol, c’est que le Wifi est assez consommateur de courant. Même si le but n’est par exemple de l’allumer que quelques secondes par heure pour envoyer la température etc… Donc a étudier ce que cela donne sur batterie et quels sont les moyens possibles d’optimisation. (Deep Sleep 10µA ?)

Hardware

Il existe à ce jour 12 versions de ce module. Voir ici
Je ne détaillerais donc pas les branchements dans le détail mais en gros, un Vcc, une masse, un TX, un RX et d’autres trucs (GPIOs).

/!\ Ce module est en 3.3V !
Ne PAS y mettre 5V …j’ai testé par erreur…je confirme… Il n’aime pas ;)

C’est valable pour l’alim et pour les niveaux TX/RX.
L’alimentation doit semble t-il pouvoir founir jusqu’à 215 mA suivant les paramètres et phases Wifi.

La plupart des versions n’ont pas le classique pas de 2.54 pour les connecteurs.. il faut donc bidouiller un peu pour les mettre sur nos breadboards ou se procurer une carte adaptateur.

Software

Il faut donc s’interfacer avec le module en sérial.

Tous les modules ne sont pas fournis avec la même version de firmware, et d’ailleurs on peut modifier le firmware.

Mon 1er module est arrivé en 9600 bauds. D’autres semblent etre en 57600 ou 115200.
Toutes les versions n’ont pas non plus les même CR/LF.

J’ai testé d’abord avec GNU Screen

Avec la version par défaut de mon 1er module, avec screen, il faut alors utiliser Crtl + m puis Ctrl + j pour indiquer les fin de lignes, et valider les commandes.

Sinon on peut utiliser un peu n’importe quel logiciel (minicom, picocom etc..)
En graphique, il y a aussi cutecom moins connu:

Commandes AT principales avec le firmware de base

• Test

AT  

doit renvoyer OK

Sinon vérifier le cablage, le baudrate, les fins de ligne etc..

• ReStarT du module

Permet également de voir version de firmware.

AT+RST

\0x04Z\0xcb  
@\0xfd\0x13:6\0xa0;\0xd8@\0xae\0xea\0xfa\0x11\0xc8V\0x0c.\0xea\0xaa\0xfe  
Vendor:www.ai-thinker.com Version:0.9.2.4

• Version du firmware

Get firMwaRe ?

AT+GMR
0018000902-AI03

• Mode de fonctionnement du Wifi

Wifi MODE

Il y a 3 modes: Station pour se connecter à un AP (1) / AP pour que des machines se connectent au module (2) / Combinaison des 2 ? (3)

AT+CWMODE=1

• Voir le mode de fontionnement

AT+CWMODE?
+CWMODE:1

• Lister les SSID

Wifi ListAP

AT+CWLAP

+CWLAP:(0,"SFR WiFi Mobile",-69,"xx:xx:xx:xx:xx:xx",1)  
+CWLAP:(2,"NEUF_1234",-69,"xx:xx:xx:xx:xx:xx",1)  
+CWLAP:(0,"SFR WiFi FON",-69,"xx:xx:xx:xx:xx:xx",1)  
+CWLAP:(2,"DartyBox_1234",-80,"xx:xx:xx:xx:xx:xx",6)  
+CWLAP:(4,"Livebox-1234",-76,"xx:xx:xx:xx:xx:xx",6)  
+CWLAP:(0,"orange",-77,"xx:xx:xx:xx:xx:xx",6)  
+CWLAP:(0,"FreeWifi",-46,"xx:xx:xx:xx:xx:xx",11)  
+CWLAP:(0,"FreeWifi_secure",-47,"xx:xx:xx:xx:xx:xx",11)  

Le 1er chiffre indique:

0: OPEN
1: WPA_PSK
2: WPA2_PSK
4: WPA_WPA2_PSK

• Se connecter à un SSID

Wifi Join AP

AT+CWJAP="NomSSID","motDePasse"

• Voir sur quel SSID on est connecté

AT+CWJAP?  
+CWJAP:"NomSSID"

• Voir son adresse IP

AT+CIFSR  
192.168.1.218

• Mode Client TCP

Ce mode permet au module d’aller se connecter vers un serveur.
Par exemple d’aller demander le contenu d’une page sur Internet.

• Activation des connexions multiples

0: Une seule connexion
1: Connexions multiples

Connection IP MUltiple ConneXions

AT+CIPMUX=1

• Ouvrir une connection vers un serveur

Connection IP START

AT+CIPSTART=4,"TCP","google.com",80

4 est le numéro de canal Le reste parle de lui même.

• Indiquer les données qui vont être envoyées:

Connection IP SEND

AT+CIPSEND=4,18
>

4 pour le numéro de canal

18 est le nombre d’octets qui vont être envoyés (GET / HTTP/1.0\r\n\r\n )

Un > indique que les données vont ensuite pouvoir être envoyées.

• Envoi des données vers le serveur

> GET / HTTP/1.1

SEND OK

• Réception des données depuis le serveur

+IPD,4,524:HTTP/1.1 302 Found  
Cache-Control: private  
Content-Type: text/html; charset=UTF-8  
Location: http://www.google.fr/?gfe_rd=cr&ei=1jrdVILoHonu8wfClICYBw  
Content-Length: 258  
Date: Thu, 12 Feb 2015 23:44:22 GMT  
Server: GFE/2.0  
Alternate-Protocol: 80:quic,p=0.08

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">  

302 Moved

The document has moved here.  
</BODY></HTML>

+IPD,4,524 signifie:
IPD: IP Data
4: Numéro de canal
524: Nombre d’octets de la réponse

• Mode Serveur TCP:

• Activation des connexions multiples

0: Une seule connexion
1: Connections multiples

AT+CIPMUX=1

• Mise en écoute du module sur le port TCP 80

Le 1er paramètre est 1 pour ouvrir le port, 0 pour le fermer.

Connexion IP SERVER

AT+CIPSERVER=1,80

• Test de connexion depuis une autre machine du LAN

$ telnet 192.168.1.218 80  
Trying 192.168.1.218...  
Connected to 192.168.1.218.  
Escape character is '^]'.  
AbcdEFGhi

Le module recoit bien les données:

Link  
+IPD,0,11:AbcdEFGhi  
OK

0 étant le numéro de canal
11 étant le nombre d’octets (avec \r\n\r\n )

• Répondre à la requète du client

Il y a a priori environ 1 minute de timeout pour répondre lors de mes tests (Message Unlink)

On indique le canal de réponse, le nombre d’octets, puis les données à transmettre:

AT+CIPSEND=0,9  
> POUET

Coté client, on recoit bien la réponse:

$ telnet 192.168.1.218 80  
Trying 192.168.1.218...  
Connected to 192.168.1.218.  
Escape character is '^]'.  
AbcdEFGhi  
POUET

• Fermeture de la connexion

On indique le numéro de canal 0

AT+CIPCLOSE=0

$ telnet 192.168.1.218 80  
Trying 192.168.1.218...  
Connected to 192.168.1.218.  
Escape character is '^]'.  
aaabbcc  
hello worConnection closed by foreign host.  
$

Conclusion

Ceci n’est qu’une présentation générale de l’ESP8266, et de son firmware par défaut.
Cela montre quand même qu’avec 2,80€, on peut se connecter “facilement” en Wifi.

Mais grâce au SDK, il est possible d’utiliser d’autres firmwares facilitant l’utilisation, et plusieurs projets sont en cours avec probablement le plus utilisé NodeMCU qui pourra être le sujet d’un autre billet.

Ammené à travailler avec le terminal, à travers des connexions série, on constate un problème d’ajustement de la taille après l’utilisation de certaines commandes telles que vi etc…

J’utilise généralement la commande suivante pour me connecter sur le port série /dev/ttyUSB0

screen /dev/ttyUSB0 115200

Le problème est que certains logiciels comme l’éditeur vi considèrent que le la fenêtre de terminal n’est que de 24 lignes.

Cela reste ainsi ensuite même après être sorti de l’éditeur, ce qui laisse une bande vide en bas empêchant d’utiliser toute la hauteur du terminal.

Le problème, expliqué par Akkana Peck sur son blog est que screen n’a pas de possibilité d’envoyer par le port série, la taille originale de la fenêtre du terminal, (alors que c’est ce qui se passe en SSH par exemple).

Il ne semble pas non plus y avoir une commande qui permet de demander au terminal sa taille.

Cela n’a pas l’air simple à résoudre, heureusement pour nous, Akkana partage un petit script en python qui ruse en allant déplacer le curseur pour trouver la bonne taille etc.. et permet de résoudre le problème.

On peut également le mettre par exemple dans le fichier .bash_profile pour qu’il se lance à l’ouverture de la session.

Je ne sais pas s’il quelqu’un connait une meilleure solution à ce problème ? Mais en tout cas cela fonctionne parfaitement pour moi depuis plusieurs mois… et je me suis dit qu’il pouvait être utile de partager l’astuce.

Voici comment j’ai branché un minitel avec un Raspberry.
Ou autrement dit, branché un minitel sur Internet ;)

J’ai trouvé plusieurs liens qui expliquent différentes manières de procéder, mais toutes imposent de créer un petit circuit électronique… et aucune ne propose d’utiliser le PL2303… Comme cette méthode me semble plus simple, j’écris ce billet.

Il vous faudra principalement:

• Un minitel avec prise DIN et touche Fonction (Recup ou ~ 5€)
• Un adaptateur USB/Serial PL2303 avec niveaux 5V (~ 1€)
• Une prise DIN (~ 1€)

Tous les minitels n’ont pas de port DIN. Il faut donc bien choisir.
Le minitel doit avoit cette prise au dos.. ainsi que la touche Fonction.

L’adaptateur USB/Serial PL2303 existe avec, soit des niveaux de 3V3, soit des niveaux de 5V.
Pour l’utilisation avec le Minitel il faut utiliser un PL2303 avec les niveaux 5V.

Comme on n’est jamais vraiment certain, il vaux mieux vérifier.

La prise DIN comporte 5 connecteurs.

1: RX : à connecter sur TX du PL2303
2: Masse: à connecter sur la masse du PL2303
3: TX : à connecter sur RX du PL2303
4 et 5 se sont pas utilisés ici.

On branche ensuite simplement le PL2303 sur un port USB du Rasp, et la prise DIN sur le Minitel.

Coté OS, il est maintenant nécessaire de dire à Raspbian “d’envoyer une console” sur notre PL2303 qui est reconnu par défaut en /dev/ttyUSB0

Comme expliqué entre autres sur Pila’s blog, on ajoute donc au fichier /etc/inittab la ligne:

T1:23:respawn:/sbin/getty -L -i -I "\033\143" ttyUSB0 4800 minitel1b-80

puis on exécute un sudo init q ou reboot pour appliquer la modification.

Coté Minitel, il faut lui dire d’utiliser la prise DIN, donc une fois allumé on fait:

Fnct + T, puis A (ou F) : passage en mode péri-informatique (80 colonnes).
Fnct + T, puis E : désactivation de l’écho local.
Fnct + P, puis 4 : réglage de la vitesse de transmission à 4800 bauds.

Avec cette méthode, le prompt de login ne s’affiche pas parfaitement, mais après avoir tapé quelques caractères, tout rentre dans l’ordre.

A quoi ca sert ?
A rien.. ok.. ;) Mais il faut bien recycler nos vieux Rasp modèles B !

Quelques autres liens sur le sujet:
Pila’s blog ici et ici / x0r ici et ici / xavier / Yip / ForumRaspberry / alphak / furrtek / Labomedia / Aplu

J’utilise généralement Shutter pour prendre des screenshots.

J’évite de stoquer ces screenshots sur les sites publics, donc jusqu’à présent, quand je voulais ensuite partager ce screenshot, en gros:

• je l’enregistrais localement
• je faisais un scp du fichier dans le répertoire qui va bien sur un serveur web
• Je faisais des copier/coller de l’URL avec le nom du fichier pour communiquer l’URL.

On peut faire des variantes avec sshfs, scripter quelques trucs.. etc.. mais c’est pas forcément l’idéal.

Mais ce coup ci, j’en avais plusieurs à faire et j’ai donc cherché un truc “propre” pour simplifier le process.

Au bout de quelques secondes de recherche, je suis tombé sur le bien nommé shutter-scp (voir aussi ici. Et c’est exactement ce que je voulais.

Pour l’installation, il suffit de copier un fichier dans le bon répertoire de Shutter (voir le README).
Pour la configuration, il suffit de renseigner où faire le scp (Serveur:Répertoire) ainsi que l’URL qui sera communiquée (à saisir dans le champs “Mot de Passe”).

Une fois le screenshot réalisé dans Shutter, un clic pour exporter, un autre pour valider le scp, puis un dernier pour copier l’URL complète.
Avec ma clé SSH chargée en mémoire, pas besoin de mot de passe, en 3 secondes, tout est fait.

J’avais testé Screencloud qui supporte le SFTP.. Mais il ne supporte pas (encore) l’authentification par clé publique… donc pas possible pour moi.

Introduction

Mon but était de pouvoir allumer le chauffage (chaudière) d’une maison secondaire à distance.

La chaudière est équipée d’un thermostat qui peut maintenir une température programmée automatiquement, mais le besoin est de pouvoir passer, à la demande, et à distance, du mode “Hors gel” au mode “JeVeux18°C”.

Par exemple X semaines sans rien chauffer du tout.. puis du jour au lendemain décider de vouloir 18°C. (Si vous pensez que ce n’est pas grave d’arriver dans une maison à 2°C, vous n’avez probablement pas encore d’enfants ;) )

Trève de blabla.. en vrac:

• La chaudière est équipée d’un “boitier/thermostat” filaire déporté, qui permet de contrôler la chaudière.
• La première idée était de voir si le fabriquant ne proposait pas un module permettant de réaliser ceci. -> Oui, a priori c’est possible mon bon Monsieur, en échange d’un peu plus de 300€ HT.
• Mmmm… j’achète 10 Rasp pour ce prix là moi
• On va donc partir sur l’utilisation du Rasp, qui de toute façon est déjà sur place ;)
• La seconde idée est de voir quel est le protocole utilisé entre le thermostat et la chaudière.. pour ensuite essayer de l’implémenter sur le Rasp.
• Après investigations, il s’agit du protocole eBUS
• A première vue, cela semblerais à peu près jouable de l’implémenter (UART etc.. ) même si le “projet” à l’air d’être complètement mort.
• Mais très vite, cela semble quand même bien galère… Une partie du peu de doc est en Allemand.. Risque de péter la chaudière et le thermostat, beaucoup de temps à passer pour (essayer d') implémenter le protocole et trouver les bons menus..le tout sans être sûr d’y parvenir..et le tout pour un protocole déjà mort.
• On en vient donc finalement rapidement à la 3ème idée: simuler la séquence d’appui sur les boutons du thermostat filaire existant, qui permet de passer du mode “HorsGel” au mode “JeVeux18°C”

Approche

• Démontage du thermostat existant.
• On trouve rapidement les contacts des 2 boutons utilisés pour aller dans les menus.
• On soude les 4 fils, on les fait sortir sur le coté.. et on referme le tout.
• Le thermostat pourra donc toujours être utilisé en “local” en appuyant sur les boutons.. mais ensuite en plus à distance par le Rasp.

• Maintenant il faut pouvoir faire “contact” entre les 2 fils de chaque bouton pour simuler l’appui.
• On est en courant continu.. et avec un ampèremètre, on le mesure l’histoire de voir.
• Plusieurs solutions sont envisageables pour créer le contact et donc simuler l’appui sur le bouton; transistor, relai “normal”, reed relay, circuit intégré, etc..
• J’écarte l’idée du transistor, car je ne sais pas ce qu’il y a devant et derrière les boutons “interrupteurs” du thermostat.. n’étant pas spécialiste, je n’ai pas envie de cramer le tout… (qui coûte certainement le même prix que le module de commande à distance.
• Après recherche sur le net.. le 74HCT4066 est censé faire l’affaire.
• Je prends mon 74HCT4066, je n’ai aucun problème pour allumer/éteindre une LED par exemple.. mais cela ne marche pas sur les contacts de la chaudière.. Je ne sais pas pourquoi… (Trop faible intensité ? J’ai bien mis à la masse les entrées non utilisées, j’ai aussi testé avec une résistance de 50 Ohms.. bref..)
• On passe à la solution de backup (c’est que l’hiver approchait .. des Reed Relay que j’avais en stock. (Commandés aussi pour un autre besoin).
• Les miens (1.8€) sont en “5V” (3,7V minimum pour se fermer) et un “level shifter” est donc nécessaire pour “monter” les 3.3V de la GPIO du Rasp à 5V.
• Je ne m’étend pas sur les Level Shifter dans ce billet. Cela pourra être l’objet d’un autre.
• L’intensité est largement en dessous de la limite.. donc c’est ok.

Schémas

Je n’ai pas vraiment le temps de faire un beau schéma sous Fritzing.
Donc vous aurez la version “moche/papier”

Mise en place

• Test sur breadboard avec donc les level shifter et 2 reed relais.
• Les entrées des relais sont donc commandées par 2 GPIOs du Rasp (17 et 18 dans mon cas).
• J’installe wiringPi parce que c’est plus simple (et parce que je le vaux bien).
• Je passe les 2 GPIOs en “sortie”

$ gpio mode 0 out  
$ gpio mode 1 out

• Je créé les contacts en passant à 1 les GPIOs pendant 0.3 secondes.
• Pour moi la séquence est assez simple (Bouton A / Bouton B / Bouton A):

gpio write 0 1 && sleep 0.3 && gpio write 0 0 && sleep 1 && gpio write 1 1 && sleep 0.3 && gpio write 1 0 && sleep 1 && gpio write 0 1 && sleep 0.3 && gpio write 0 0

• Les tests sont concluants… \o/

• On dégaine le fer à souder
• On soude le tout comme sur la breadboard de test..
• On rajoute un DS18B20 (1€) et sa résistance pour pouvoir connaitre la température à distance. (Je ne détaille pas cette partie, voir par exemple ici ou là.
• On rajoute une LED pour montrer que le montage est sous tension. (Et pour impressionner Madame).
• On force les GPIOs en mode “sortie” et à 0 dès le boot dans le /etc/rc.local
• On refait un petit script plus propre.
• On re-teste..
• C’est OK, on peut aller boire une bière.

Futur

• Finaliser le boitier et les câbles vers le thermostat
• Interface web (en plus de SSH) pour avoir la température et allumer la chaudière.
• Voir si on veut commander la chaudière par SMS avec Gammu
• Voir si on veut implémenter d’autres séquences (passage en HorsGel en cas d’oubli en partant)

Il n’y a pas difficulté particulière à réaliser ceci.. Et pas réellement d’intérêt à publier ces informations propres à une chaudière.. Le but est juste de montrer qu’avec un peu de motivation, un esprit un peu DIY et quelques Euros de composants, on peut facilement utiliser le Rasp pour domotiser plein de choses.. et j’espère que cela donnera des idées à certains pour mettre en place leurs propres projets domotiques.