ESP8266 et Expect

Module FTDI & Esp-05 sur un breadboard.

L'Esp8266 permet d'accéder au WiFi via des commandes AT sur une connexion série... En principe 'Expect' (tcl) semble indiqué pour ce genre de chipotage... Voici, par exemple, un petit script qui interroge le chip en boucle pour connaître la liste des réseaux présents.

#!/usr/bin/expect -f

spawn -open [open /dev/ttyUSB0 w+]
stty raw -echo < /dev/ttyUSB0
fconfigure $spawn_id -encoding binary
send "AT\r\n"
while 1 {
  expect {
    "ready\r\n" {send "AT+CWLAP\r\n"}
    "OK\r\n"    {send "AT+CWLAP\r\n"}
    timeout     {puts "  ThisIsTimeout  "}
    eof         {puts "  ThisIseof   "}
    }
  }

Comme j'utilise très peu Expect, il est possible que cela ne soit pas vraiment optimal, mais cela donne une idée...

Dans le montage utilisé, on a un module ESP-05, une interface USB-Série (3.3V) FTDI232 et un 'MB102 breadboard power supply 3.3 volts module' et quelques fils (RX/TX & alimentation). Le module 'power supply', équipé d'un régulateur AMS 1117-3.3 semble optionnel, le 3.3 volts pouvant être délivré par le module FTDI. Je pensais que les resets intempestifs de l'esp8266 provenaient d'une faiblesse de l'alimentation par le FTDI mais ils persistent avec le module d'alimentation... Le problème doit venir d'ailleurs; il faut probablement mettre une 'pull-up' sur le reset de l'ESP-05 (?). Sinon, cela semble fonctionner. La version du firmware de l'ESP-05 (0018000902-AI03) communique en 9600 bps, 8-bits, nopar (et pas de contrôle de flux hardware), ce qui correspond aux valeurs par défaut pour /dev/ttyUSB0 sur mon GNU-Linux Ubuntu 14.04. L'Esp8266 fonctionne en 3.3 volts. Il est possible que l'interface USB-série soit autre chose que /dev/ttyUSB0, par exemple /dev/ttyUSBx (avec x =1,2,...) ou même /dev/ttyACM0 (1, 2,...). Il faut consulter dmesg(8) (et/ou faire 'ls -lrt /dev/tty*', lsusb,...).

Il est aussi possible d'utiliser 'minicom -D /dev/ttyUSB0' en terminant les commandes par ^M^J (\r\n) mais la pauvreté de l'interaction rend l'expérience rapidement frustrante (pas d'historique ni d'édition de ligne (?)). Avec Expect, 'spawn minicom ...' semble ajouter des caractères indésirables liés à la gestion d'écran de type VT100 (?) et je n'ai pas trouvé de solutions plus simples (tip?, cu?,...) mais je n'ai pas beaucoup cherché. Si on reçoit bien le prompt mais qu'on ne parvient pas à envoyer des caractères (et donc pas d'écho), vérifier que le contrôle de flux hardware est désactivé.

Le connecteur WiFi de l'Esp-05 est un U.FL (IPX). On trouve sur eBay des pigtails pour SMA et RP-SMA, N,...

Il faut noter qu'en ville, en Belgique, en 2015, les réseaux pullulent; j'en capte une quarantaine de ma table et une courte balade en rue m'en renseigne des centaines. Le wardriving a beaucoup changé depuis le début des années 2000. La plupart sont bien protégés (WAP), d'autres sont volontairement ouverts dans le cadre des offres de type 'Internet Everywhere' des fournisseurs d'accès dominants (PROXIMUS(_AUTO)_FON et VOO_HOMESPOT). Quelques-un sont probablement mal configurés...

On obtient des lignes du genre :

+CWLAP:(0,"PROXIMUS_FON",-44,"06:**:**:99:**:**",1)
+CWLAP:(4,"MonRezo",-87,"**:f8:**:**:**:9c",2)
...

qui renseignent le type de protection ( (encryption): 0 open; 1 WEP; 2 WPA_PSK; 3 WPA2_PSK; 4 WPA_WPA2-PSK), le SSID, la puissance du signal reçu (en dBm?), l'adresse MAC de l'access point et le canal WiFi. À noter que l'adresse MAC renseigne le type d'équipement via les octets qui désigne le 'manufacturer' (et donc probablement aussi les failles de sécurité propres à ce type d'équipement...).

AI-THINKER IoT

Acheté un peu plus de 6€ sur dx.com, ce bidule offre une démo clé en main. Une fois mis trois piles 'AA' (et décoché le jumper qui sert au re-flashage). Il existe (paraît-il) une application Android iot.apk mais il est possible de l'utiliser à partir d'un PC normal. Il suffit de se connecter au réseau AI-THINKER (mot de passe "ai-thinker") et de communiquer avec 192.168.4.1. Parfois cela 'se fait tout seul', sinon, faire quelque chose comme (à titre indicatif) :

$ sudo ifconfig wlan1 192.168.4.3
$ sudo route add -net 192.168.4.0 netmask 255.255.255.0 wlan1
$ # éventuellement utiliser : iwconfig, ifconfig, dmesg, lsusb,...

Le but étant de donner une adresse à l'interface WiFi et y faire transiter les paquets destinés au bidule.

On peut alors accéder aux GPIOs en JSON avec curl(1)

$ curl http://192.168.4.1/client?command=info
{
"Version":{
"hardware":"0.1",
"software":"0.9.2"
},
"Device":{
"product":"Light",
"manufacturer":"Espressif Systems"
}
$ curl http://192.168.4.1/config?command=light
{
"freq":100,
"io0":,
"io2":,
"io4":,
"io5":,
"io12":,
"io13":,
"io14":,
"io15":,
"rgb":{
"red":0,
"green":0,
"blue":200
}
$ curl -X POST -H Content-Type:application/json \
  -d '{"freq":100,"io4":0,"io5":0,"rgb":{"red":0,"green":0,"blue":200}}' \
   http://192.168.4.1/config?command=light

Voir http://www.electrodragon.com/w/ESP8266_IoT

Lua

Il est possible de reflasher les Esp8266 avec un interpréteur Lua. Pour cela, il faut connecter le GPIO-0 à la terre, faire un reset (reset->gnd; cela semble différer d'un power-up) et utiliser un outil comme Esptool (un utilitaire en Python)pour flasher un pre_build de firmware de NodeMCU :

$ sudo python esptool.py --port /dev/ttyUSB0 \
                         --baud 115200 \
                         write_flash 0x00000 \
                         ../lua/nodemcu_latest.bin

Après, voir cet exemple qui montre comment créer un fichier init.lua sur le SoC. Sur Wikipédia, ils conseillent de commencer par un file.format(). Voir l'API NodeMCU.

Voir aussi

Le petit bidule de 5x5mm² comporte un 'core' 32 bits tournant à 80 MHz, 512 Koctets de mémoire FLASH et quelques dizaines (?) de Koctets de RAM (plus tout ce qu'il faut pour recevoir/émettre du WiFi, quelques GPIO, ADC(?),...

• ESP8266 sur NurdSpace.nl
• ~ ESP8266 datasheet (page)
• http://www.electrodragon.com/w/ESP8266
• https://github.com/esp8266/esp8266-wiki/wiki
• AT commands