29 résultats trouvés : mqtt

Requête recherchée : mqtt

par Jean-Marie
mer. 11 mars 2015 20:33
Forum : Et tout le reste
Sujet : Tous les capteurs reliés au RPI par Wifi avec module ESP8266
Réponses : 528
Vues : 179426

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Hello smba38

Hier j'avais essayé de nombreuses fois de repasser en commandes AT, aussi bien avec le NodeMCU Flasher qu'avec XTCOM_util.
Aujourd'hui, en consultant ton lien de NodeMCU_Studio, j'ai vu une version un peu différente du Flasher : le nodemcu_flasher32bit.exe disponible ICI. Je l'ai téléchargée et cette fois j'ai pu repasser sans problème aux commandes AT, version 09.5.
494.jpg
494.jpg (134.16 Kio) Vu 3413 fois
Tant que je ne me sens pas trop à l'étroit avec ces commandes, j'aime autant m'y tenir. Cela m'évite de devoir aborder un langage que je ne connais pas du tout. Il sera toujours temps d'essayer LUA ou MQTT quand je serai plus à l'aise.

En tout cas, merci pour tes précieuses indications.
par Jean-Marie
dim. 8 mars 2015 17:31
Forum : Et tout le reste
Sujet : Tous les capteurs reliés au RPI par Wifi avec module ESP8266
Réponses : 528
Vues : 179426

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

smba38 a écrit :Pour le DeepSleep, on laisse en permanence le pontage GPIO16 RST, c'est pas génant.
A la fin du node.dsleep un reboot à lieu et sur Lua si le fichier init.lua existe, ce fichier s'exécute.
Donc, c'est toi qui fixe la durée du DeepSleep (< 1 heure) et, au redémarrage, je suppose que le module recommence le programme LUA depuis le début.
Finalement, il semble que la méthode du "Power OFF" externe soit plus souple. Le µC externe maintient le Power OFF pour la durée programmée, sans limite (1 heure, 1 jour ou 1 mois). Au réveil, soit l'ESP reboot sur son programme, soit c'est le µC externe qui redémarre ses commandes AT.
(dans la question des collisions)... Il faut faire des tests pour voir à quoi correspond le N° de canal.
Si ce numéro permet à un client d'être connecté à plusieurs serveurs, ce N° sert au client à savoir quel serveur à répondu.
pour le réseau des capteurs, je vois un seul serveur (le poste central) et de multiples clients (les capteurs). Chaque capteur doit envoyer sa mesure au serveur. Les mesures qui parviennent au serveur sont accompagnées d'un n° de connexion allant de 0 à 4, donc apparemment 5 connexions simultanées possibles. Mais ces n° de connexion n'identifient pas quel capteur est à l'origine de l'envoi. D'ailleurs, ce n° se libère dès que le poste périphérique a refermé sa connexion (AT+CIPCLOSE) et le même n° peut être attibué à un autre capteur. Autrement dit, ce n° sert seulement à ce que le serveur dise au capteur "j'ai bien reçu ton message. Merci. Bonne nuit et à la prochaine". En conséquence, la mesure du capteur doit être accompagnée d'un identifiant de ce capteur.
Il faut vraiment que j'aie mes nouveau modules pour des tests concrets. Malheureusement, je viens seulement de recevoir aujourd'hui l'avis qu'ils ont été shipés, je veux dire envoyés ! J'en ai donc encore bien pour 2 à 3 semaines. Il aura fallu 8 jours entre la commande et l'envoi. Est-ce une indication du succès des modules ? J'ai le même coup avec les ATtiny85: commandés le 17 février, pas encore envoyés!
nodemcu a du être développé par des chinois car sur certaines documentations, c'est du chinois.
Je dirais même plus : pour toutes les documentations, c'est du chinois !
Merci pour tes efforts louables de m'expliquer les SDK, librairies, compilateurs, interpréteurs, MQTT, etc...
Je pressens que grâce à ta formation professionnelle tu baignes là-dedans comme dans du beurre ("J'ai pas encore tésté MQTT mis je pense le faire avec un client en Lua et un serveur (Broker) sur raspberry."). Quant à moi, je suis obligé de me restreindre à des tâches "low level", du genre "cette pin doit être high jusqu'à ce que cette autre pin présente un front montant" car la micro-informatique n'est qu'un hobby datant de quelques années.
par smba38
dim. 8 mars 2015 11:47
Forum : Et tout le reste
Sujet : Tous les capteurs reliés au RPI par Wifi avec module ESP8266
Réponses : 528
Vues : 179426

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Coucou Jean-Marie,
Jean-Marie a écrit : Que faut-il faire pour sortir du deepsleep ? simplement interrompre la liaison GPIO16-RST ?
Pour le DeepSleep, on laisse en permanence le pontage GPIO16 RST, c'est pas génant.

A la fin du node.dsleep un reboot à lieu et sur Lua si le fichier init.lua existe, ce fichier s'exécute.

J'ai indiqué dans un post précédent que le Dsleep pouvait durer plusieurs heures.
Je me suis un peu avancé rapidement.
Dans le langage Lua les nombres peuvent avoir de très grandes valeurs mais dans l'implémentation de ce langage sur l'esp8266 un nombre entier semble être un nombre codé sur 32 bits.
J'ai testé dsleep ça fonctionne sur 1/2 heure mais ça ne fonctionne par sur une heure.
La valeur maximum doit être celle d'un nombre entier signé (ce qui correspond à environ 2000 secondes).
Jean-Marie a écrit : Par ailleurs, il faut apprendre comment gérer les collisions, le fait que deux postes périphériques peuvent tenter de se linker et d'envoyer leur mesure en même temps à l'unité centrale. Pour tester ça, il faudrait disposer d'au moins deux postes périphériques. Donc, je dois aussi attendre mes nouveaux ESP-12.
Il faut faire des tests pour voir à quoi correspond le N° de canal.
Si ce numéro permet à un client d'être connecté à plusieurs serveurs, ce N° sert au client à savoir quel serveur à répondu.
Si le serveur conserve une table des adresse IP des clients avec le N° de canal utilisé il peut y avoir deux clients utilisant le même n° de canal.
De toute façon le serveur est obligé d'utiliser les adresses IP pour répondre.
Le nombre de clients simultanés va être fonction de la taille de la table utilisée par le serveur pour conserver les adresses IP des clients.
Jean-Marie a écrit : A ce propos, SMBA38, tu peux déjà m'éclaircir un peu les idées.
Est-ce que le Espressif IoT SDK a quelque chose à voir avec le firmware du NodeMCU ?
S'ils sont différents, peux-tu un peu expliquer leur usage et les différences ?
Et est-ce encore différent de MQTT ?
Espressif à utilisé un SDK pour développer le firmware des commandes AT des puce esp8266.
Ce SDK (Software Development Kit) Contient tout ce qui est nécessaire à la recompilation du firmware des commandes AT.
Je n'est pas trop regardé ce SDK mais je suppose que tout le code source n'est pas disponible, certaines parties doivent être sous forme de librairies.
Le Programming Guide est la liste des appels possibles à ces librairies depuis un programme écrit en C.

Il ne suffit pas d'avoir des sources et des librairies, il faut également des compilateur, des éditeurs de liens.
C'est assez compliqué de partir de zéro mais il existe de "ToolChain" , ensemble des paquets utilisés dans le processus de compilation d'un programme.
Il existe des ToolChain pour linux ou pour Windows, On peut installer une toolchain sur Raspberry.
Une toolchain n'est pas universelle, elle est différente en fonction du firmware à recompiler.
Espressif propose une machine virtuelle sous Virtualbox avec tout l'environnement (ToolChain) de développement déjà installé mais sans le SDK qu'il faut récupérer à part. .

A partir du SDK, des firmwares alternatifs sont apparus.
Des ajouts aux commandes AT, des serveurs Web, l'interpréteur Lua ...
En principe les fichiers nécessaires à la recompilation d'un firmware (SDK + ajouts propres au Firmware) sont disponibles sur http://www.github.com
Par contre les "ToolChain" ne sont pas livrées.

La recompilation d'un firmware génère des fichiers binaires à flasher sur l'esp8266.
Mais attention parfois il y a plusieurs binaires à flasher dans plusieurs offsets(Adresses) sur l'esp8266.
Par exemple le SDK est à flasher à une adresse et la patrie recompilée par l'utilisateur à une autre.
Le mieux c'est de disposer d'un binaire à charger en une seule fois à l'adresse 0x00000 (avec ls SDK intégré).

Attention il existe plusieurs version de SDK.
par exmple sur nodemcu.

Code : Tout sélectionner

NodeMCU 0.9.5 build 20150213  powered by Lua 5.1.4
lua: cannot open init.lua
> 
0.9.5 est la version du SDK et 5.1.4 est la version de Lua.
Si une nouvelle version du SDK sort, on peut recompiler Lua 5.1.4 avec ce nouveau SDK.
Ce qui compte c'est la date de la recompilation car on peut recompiler plusieurs fois avec le même SDK.

Pour les commandes AT la notion de firmware semble ajoutée, il est préférable de se baser sur la date.

Code : Tout sélectionner

AT+GMR
00200.9.5(b1) -> sdk 20 firmware 9.5
compiled @ Dec 25 2014 21:40:28
Les binaires peuvent être livrés sous forme de fichier .exe Windows avec une ou plusieurs parties autoextractibles.
C'est le cas de l'interpréteur Lua de nodemcu.
Nodemcu c'est un firmware et une carte de développement associée.

nodemcu a du être développé par des chinois car sur certaines documentations, c'est du chinois.
Je pense qu'au début Expressif ne divulguait pas sont SDK.
Au début seul le firmware des commandes AT existait, les puces sont généralement livrées avec les commandes AT.
Les Chinois sont peut être arrivés à faire un SDK alternatif (en décompilant le binaire) , mais c'est une supposition.

Le SDK contient tout ce qui est nécessaire au pilotage du WIFI de la puce.
Seul Espressif doit bien connaître le Hardware de sa puce et les fonctions de bas niveau( comparables à des drivers)
C'est la partie la plus compliquée à développer après faire un serveur WEB en utilisant le SDK, c'est du gâteau .

Jean-Marie si tu a un PC assez puissant essaye la machine virtuelle d'Espressif, c'est assez facile à utiliser.
La toolchain est sur la machine virtuelle, les fichiers du SDK sont sur un répertoire Windows partagé.

Mais pour programmer en Lua pas besoin de recompiler nodemcu sauf si l'on veut ajouter des fonctionnalités.
Par exemple une fonction pour faire des calculs ou la vitesse d'exécution de l'interpréteur Lua est pénalisante.

En ce qui concerne MQTT.
MQTT est un service de messagerie TCP/IP simple
Les messages sont envoyés par des publieurs (les publishers) sur un canal (une chaîne d’information ) appelé Topic. Ces messages peuvent être lus par les abonnés (les subscribers). Les Topics (ou les canaux d’informations) peuvent avoir une hiérarchie qui permet de sélectionner finement les informations que l’on désire.

j'ai copié sur http://blog.guiguiabloc.fr/index.php/20 ... simplement

Nodemcu dispose de fonctions simplifiant l'utilisation de MQTT.
J'ai pas encore tésté MQTT mis je pense le faire avec un client en Lua et un serveur (Broker) sur raspberry.

Au passage, mon nouveau Raspberry 2 se trainait lamentablement.
J'ai changé la carte SD par une microSDHC avec 90MB en lecture et 50MB en écriture et c'est le jour et la nuit.

A+
SMBA38
par Jean-Marie
sam. 7 mars 2015 21:16
Forum : Et tout le reste
Sujet : Tous les capteurs reliés au RPI par Wifi avec module ESP8266
Réponses : 528
Vues : 179426

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Hello,

Vous pouvez vous procurer le document suivant à cette adresse
493.jpg
493.jpg (63.09 Kio) Vu 3283 fois
A ce propos, SMBA38, tu peux déjà m'éclaircir un peu les idées.
Est-ce que le Espressif IoT SDK a quelque chose à voir avec le firmware du NodeMCU ?
S'ils sont différents, peux-tu un peu expliquer leur usage et les différences ?
Et est-ce encore différent de MQTT ?
par smba38
ven. 6 mars 2015 18:57
Forum : Et tout le reste
Sujet : Tous les capteurs reliés au RPI par Wifi avec module ESP8266
Réponses : 528
Vues : 179426

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Coucou,

J’ai posté sur le forum de framboise314 plusieurs messages sur la puce ESP2286 programmée avec le langage Lua.

De base cette puce possède un firmware permettant son utilisation sous forme de commandes AT.
Mais il existe d’autres firmwares :
Compilation de firmwares écrits en C avec un SDK.
Micro python.
Interpréteur LUA.

C’est ce dernier firmware que j’ai utilisé pour tester les communications entre des puces esp8266 et un serveur.

Voici un tableau récapitulatif de ces tests.
tableau_tests.JPG
Tableau tests
tableau_tests.JPG (88.64 Kio) Vu 3374 fois
Remarques :
1) Depuis un client Telnet, on se connecte en WIFI sur l’interpréteur Lua d’un esp8266 ,on peut mettre à jour le code Lua ou lancer des traitements à distance.
2) Avec le protocole UDP, on peut connecter plusieurs clients esp8266 à un serveur UDP, les puces peuvent seulement envoyer des informations au serveur.
3) Avec le protocole TCP, les clients esp8266 peuvent envoyer et recevoir des données.
4) Test d’un capteur Ethylomètre, les résultats s’affichent dans une page WEB.
Ce capteur retourne une valeur sur 10 bits, il faut donc l'étalonner.
5) Le client esp8266 se connecte sur une base de données orientée IOT (Internet of Things) thingspeak.Les données enregistrées sur cette base sont ensuite accessibles par un navigateur.
6) Exemple de serveur WEB écrit en C avec un sdk.
http://harizanov.com/2014/11/esp8266-po ... r-reading/
La société Espressif propose une machine virtuelle avec le l’environnement du SDK déjà installé.
7) Cet exemple permet d’envoyer un mail directement depuis l’esp8266.
8) Tests avec l’utilisation de commandes AT à la place du langage Lua.
Je n'ai pas utilisé de microcontrôleur mais seulement une console pour envoyer les ordres AT.
9) MQTT (Machine to machine) est un service de messagerie TCP/IP simple et extrêmement léger, prévu pour les objets connectés à Internet.

Et voici quelques images:
Test N°4
Web ethylomètre.JPG
Web ethylomètre
Web ethylomètre.JPG (23.8 Kio) Vu 3374 fois
Test N°5
ThingSpeak.JPG
Base de données thingspeak
ThingSpeak.JPG (17.38 Kio) Vu 3374 fois
Pour concevoir un système clients/ serveur fiable, il faut disposer de certaines fonctionnalités:
-Relance automatique des connexions en cas de reboot du serveur ou des clients.
-Traçabilité des erreurs de connexions (pour analyser les erreurs afin de les corriger) .
-Alertes en cas de disfonctionnement.

Lua est un langage orienté réseau (on retrouve ce langage sur des routeurs et sur des Box domotique), il permet de gérer finement les connexions.

Lua permet de gérer des fichiers sur la mémoire Flash on peut donc conserver des logs.

On peut envoyer un mail directement depuis Lua.

Je trouve Lua intéressant car il peut travailler en autonome.

Les programmes de tests que j'ai indiqués en exemples sont surement à améliorer pour essayer de concevoir des communications les plus fiables possibles.

En ce qui concerne la consommation des esp8266, la doc technique semble indiquer qu'il existe un état de veille duquel on peut sortir sans perdre l'état des programmes en cours.

Pour l'instant en Lua, seule l'utilisation de dsleep permet de mettre en sommeil la puce, mais à sont reveil, reboot de l'esp8266.

Je n'ai pas testé cette possibilité mais d'après la documentation il faut relier les pins PIN32(RST) et PIN8(XPD_DCDC).

Il faut espérer que dans les prochains firmwares dsleep soit amélioré.

La puce esp8266 nous réserve encore pas mal de surprises.

SMBA38.
par Jean-Marie
ven. 6 mars 2015 17:45
Forum : Et tout le reste
Sujet : Tous les capteurs reliés au RPI par Wifi avec module ESP8266
Réponses : 528
Vues : 179426

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Veloce a écrit :Bon c'est super, qu'est-ce que tu fais après ? Tu vas brancher un module sur le Raspberry Pi ? Pas de sockets pour l'instant alors ?
Trois bonnes questions !
Il est temps de faire le point.

Jusqu'ici, j'ai pu simuler l'envoi d'une mesure par un poste périphérique. Pour le moment, le poste périphérique, c'était moi aux commandes d'un PC. J'ai agi en surveillant l'écran du terminal. Mais en principe, tout cela devrait être automatisé et géré par un minuscule ATtiny85. Mes ATtiny85 sont commandés mais pas encore arrivés.

En attendant, il faut que je voie comment mettre l'ESP8266 en deep sleep et comment le réveiller car si le poste périphérique est autonome sur batterie, il doit consommer le moins possible et ne se réveiller que de temps en temps pour envoyer sa mesure au poste central.

Par ailleurs, il faut apprendre comment gérer les collisions, le fait que deux postes périphériques peuvent tenter de se linker et d'envoyer leur mesure en même temps à l'unité centrale. Pour tester ça, il faudrait disposer d'au moins deux postes périphériques. Donc, je dois aussi attendre mes nouveaux ESP-12.

L'unité centrale, je ne sais pas encore ce qu'elle doit être, un Raspberry ? C'est certainement possible. Un Arduino serait-il suffisant pour gérer une série de capteurs périphériques et, en fonction des mesures reçues, décider de mettre en oeuvre l'un ou l'autre effecteur ? Peut-être. Mais il ne suffit pas de recevoir des mesures et mettre en oeuvre des effecteurs de manière entièrement automatique. Il faut encore pouvoir informer le maître des lieux, en l’occurrence moi, et laisser à celui-ci la possibilité d'intervenir dans la gestion et de modifier le comportement automatique. En effet, je ne vais pas passer ma vie (ou ce qu'il en reste) à surveiller un terminal pour voir la succession des mesures périphériques et des effecteurs mis en oeuvre. Puisque ce petit bijou à deux balles qu'est l'ESP8266 nous en donne la possibilité, on va lui demander d'alimenter une page web présentant toutes les mesures reçues ainsi que les actions entreprises auprès des effecteurs, avec possibilité d'intervenir dans ces actions. Cette page devra être consultable at home mais aussi à distance.

On peut aussi imaginer qu'en cas de situation jugée sérieuse par l'unité centrale, celle-ci envoie un SMS (=TEXTO en France ?) automatique pour demander de consulter d'urgence la page web.

Face à tout cela, la question du langage de commande se pose. Ce n'est pas encore clair s'il est avantageux ou peut-être même indispensable de travailler en LUA, voire en MQTT ou en GCC ou bien si on peut continuer en commandes AT avec microcontrôleur derrière.

Voilà. C'est pas le pain qui manque sur la planche.

C'est fou car lorsque je suis tombé par hasard sur l'ESP8266, je n'étais pas particulièrement branché sur la domotique. J'essayais de me dépatouiller dans la tonne de nouvelles notions (pour un Windowsien) accompagnant le RaspBerry que j'avais reçu à Noël. Mais au vu du coût de l'ESP, ses possibilités énormes me l'ont rendu aussi irrésistible qu'un trou noir attirant les étoiles.
Je dispose de quelques connaissances dans la mise en oeuvre des microcontrôleurs Atmega. D'un seul coup, l'ESP m'a fait miroiter la possibilité pour un Atmega d'intervenir à distance et même sur Internet à peu de frais, aussi bien sur le plan pécuniaire que sur les efforts d'acquisition de notions nouvelles.

Bon, concrètement j'ai bien envie de chercher de la doc sur le deep sleep et le réveil.

Quant aux sockets, je dirais comme quelqu'un d'assez connu: "Père, éloigne de moi ce calice. Cependant, que ta volonté soit faite". Traduit en langage ESP, cela donne "si possible, évite-moi d'étudier les 95 pages. Cependant si cela s'avère indispensable, qu'il en soit ainsi !"
par Jean-Marie
mer. 4 mars 2015 12:33
Forum : Et tout le reste
Sujet : Tous les capteurs reliés au RPI par Wifi avec module ESP8266
Réponses : 528
Vues : 179426

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Hello smba38,
Dans un de mes messages j'ai indiqué mes essais sur les commandes AT.
J'ai utilisé la commande netcat sur Windows pour récupérer les données envoyées d'un esp8266 par des commande AT.
http://sourceforge.net/projects/nc110/
OK, mais il y a bien une raison pour laquelle Putty ne veut pas marcher. La raison est certainement à chercher dans le fait que je suis absolument novice dans ces questions de réseau et de communication.

En plus, ces moyens de communication du style Console, Terminal, Putty, Realterm ou autre ne me sont d'aucune utilité dans mon projet de domotique, sauf peut-être pour des tests. En effet, je cherche à relier (wireless) divers capteurs à une unité centrale de type Raspberry ou microcontrôleur, à l'intérieur d'un programme écrit par moi-même (de préférence en C), capable de prendre des décisions et éventuellement d'actionner une alarme, un éclairage, un moteur, une pompe .....

La question est donc double:
  • Comment s'y prendre pour qu'un ESP envoie "ABCD" à un Raspberry dont on connait l'adresse dans le réseau ?
  • Comment s'y prendre pour qu'un programme homemade tournant sur le Raspberry capte le "ABCD" ?
D'après ce que j'ai lu des commandes AT, l'ESP ne peut envoyer qu'en ouvrant une session "TCP" ou "UDP".
Le programme tournant sur le Raspi doit donc être capable de gérer le protocole TCP ou UDP.

Les choses sont-elles plus simples en Lua ?
On parle aussi du protocole MQTT implantable sur l'ESP ?
par smba38
mer. 25 févr. 2015 23:14
Forum : Et tout le reste
Sujet : Tous les capteurs reliés au RPI par Wifi avec module ESP8266
Réponses : 528
Vues : 179426

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Bonsoir Jean-Marie.

Si l'on utilise lua, on ne dispose plus des commandes AT.
Il est préférable d'utiliser lua en mode autonome car l'intelligence est dans le code lua.

Pour récupérer les données envoyées par l'ESP8266 plusieurs cas:

On récupère les données et on les traites ensuite en différé.
On veut traiter les données en temps réel quand elles arrivent dans ce cas, il faut programmer.
On ne peut pas se permettre de perdre des données.

On peut par exemple utiliser le langage python à travers des sockets.

Voici plusieurs exemples de communications.

Avec les commandes at:
dans les exemples suivant on utilise la commande nc (netcat) sous Windows ou sous linux pour écouter sur un port.
On peut en python écouter sur un port et faire des traitements en temps réel.

La difficulté est de prévoir les cas ou les connexions sont fermées.

Code : Tout sélectionner

AT
OK
AT+GMR
00200.9.5(b1) -> sdk 20 firmware 9.5
compiled @ Dec 25 2014 21:40:28

AT+CWMODE?  -> ? Utilisé pour interroger une valeur 
+CWMODE:3      -> 1=STA 2=AP 3=STA+AP

AT+CWMODE=3 -> = utilisé pour modifier une valeur
OK

AT+CWLAP  -> points d’accès à portée
+CWLAP:(3,"WRT54G_409B",-59,"00:12:17:b3:40:9d",1)
+CWLAP:(4,"larivoire234",-82,"34:8a:ae:3c:cc:44",6)


AT+CWJAP="WRT54G_409B","23423423423423423423423423" -> connexion au routeur WRT54G_409B
OK

On peut configure l’AP  (nom, pwd, authentification, sauf l’adresse IP qui est par défaut 192.168.4.1)
Par défaut pas de mot de passe et le nom du point d’accès est xxx_yyyy (YYY= fin adresse MAC du point d’accès).
AT+CWSAP="ESP8266","00000000",4,3 -> SSID, pwd,canal, authentification 1=WEP,2=WPA,3=WPA2,4=WPA+WPA2

AT+CIFSR -> Infos connexions 
+CIFSR:APIP,"192.168.4.1" 		 -> AP (Acces point) IP non modifiable par commandes AT
+CIFSR:APMAC,"1a:fe:34:9b:c8:31"
+CIFSR:STAIP,"192.168.1.17"		-> IP affectée par le DHCP du routeur WRT54G_409B
+CIFSR:STAMAC,"18:fe:34:9b:c8:31"
OK

Après connexion en WIFI au point d’accès 192.168.4.1 depuis un PC 
AT+CWLIF
192.168.4.101   f8:4e:06:1c:f2:b7  -> Adresse IP affectée par le DHCP du point d’accès 192.168.4.1

Dans une console sur un PC le ping répond  sur 192.168.1.17 ou 192.168.4.101
Réponse de 192.168.1.17 : octets=32 temps=4 ms TTL=255

AT+CIPMUX=1  ->multi connexions
OK
Sur le pc d’adresse IP 192.168.1.30 lancer la commande netcat pour écouter sur l’IP 192.168.1.17 port 4444
nc -l 192.168.1.17 -p 4444

AT+CIPSTART=0,"TCP","192.168.1.30",4444 -> connexion au PC d’adresse IP 192.168.1.30 sur le port 4444
0,CONNECT
OK

AT+CIPSEND=0,5 -> envoi sur canal 0, sur 5 octets
> aaaaa
SEND OK

Il existe des firmwares modifiés par exemple pour gérer les GPIO via des commandes AT http://www.electrodragon.com/w/ESP8266_Custom_AT_Firmware
AT + CIOADC command reads the ADC value Note: ADC input voltage 0,1V  0 to 1024,10 bit precision
AT + CIOREAD command reads the GPIO AT + CIOREAD = 0 reads GPIO0 level return 1 , 0 
AT + CIOWRITE command to set the GPIO AT + CIOWRITE = 0,0 setting GPIO0 level is low 
AT + CIOWRITE = 16,1 set of high level GPIO16
Je viens de tester un solution d'envoi de données par mail directement depuis lua.
Cette solution à l'avantage de régler les cas ou le serveur qui écoute les esp8266 est hors fonction.

Pour comprendre le protocole utilisé par un serveur de mails SMTP (mails sortants)
On peut simplement utiliser un client telnet sur le port 25
Et répondre aux messages du serveur SMTP.
Ne pas oublier le point (.) en fin de message.
Par exemple depuis une ligne de commande CMD sous Windows (sous linux c’est le même principe).

Code : Tout sélectionner

telnet smtp.orange.fr 25
220 mwinf5d23 ME ESMTP server ready
HELO orange.fr
250 mwinf5d23 hello [90.15.24.192], pleased to meet you
MAIL FROM: <SMBA38.esp8266@orange.fr>
250 2.1.0 <SMBA38.esp8266@orange.fr fr 
> sender ok
RCPT TO: <esp8266.michel@orange.fr>
250 2.1.5 <esp8266.michel@orange.fr> recipient ok
DATA
354 enter mail, end with "." on a line by itself
Reply-to: <SMBA38.esp8266@orange.fr>
Subject: test envoi mail par esp8266
Et en plus ça fonctionne
C’est super 
SMBA38 
.
250 2.0.0 wYzq1p00Q48gNr603Z0e5d mail accepted for delivery
QUIT
221 2.0.0 mwinf5d23 ME closing connection
Perte de la connexion à l'hôte.
Et bien sur on peut faire la même chose en LUA

Infos récupérées sur http://www.esp8266.com/viewtopic.php?f=24&t=1231

Le programme utilise une table d’états step[].
A chacune des 8 étapes le code renvoyé par le serveur SMTP doit être correct pour passer à l’état suivant.
A la fin de l’envoi d’un mail on peut choisir de ne pas quitter le programme, de rebooter
Ou de se mettre en veille « node.dsleep() » (mais il faut PIN32(RST) et PIN8(XPD_DCDC) reliées).
En fin de veille, l’esp8266 effectue un reboot.
Le Reboot est conseillé car le ramasse miettes « collectgarbage() » ne semble pas sur et le second mail n’est pas envoyé , mais le troisième est envoyé ? ( A creuser).
Il faut modifier l’avant dernière ligne du code pour indiquer :
les adresses mails de l’émetteur, du récepteur, le sujet le corps du mail et le serveur SMTP.

Code : Tout sélectionner

-- Fonction d'envoi d'un mail   (sur une idée de http://www.esp8266.com/viewtopic.php?f=24&t=1231)
-- avec le traitements des Evenements associés à la vie de la connexion TCP
-- le traitement du mail comporte 8 étapes enchainées au fur et à mesure des réponses du serveur SMTP
-- A chaque étape "handle_response est appelé"
-- Problèmes a voir: pas de "de" dans les messages reçus, pas d'envoi au second appel de send mail.
-- Idées d’améliorations : création fichier log des alertes envoyé en pièce jointe
-- + Récupération  de la date sur un serveur NTP.

sendmail=function(from,to,subject,body,server)
-- reponses au message reçus du serveur SMTP 
   local handle_response = function(conn,response,step,state) 
      --print("handling state:" .. state  .. "Heap=" .. node.heap() .. "expecting:" .. step[state].expected  .. " got:" .. response)
      if response:match(step[state].expected )
      then  -- c'est le code attendu du serveur SMTP
          print ("(" .. state ..") OK")
         if step[state].request  -- il existe un request dans la table 
         then
            conn:send(step[state].request .. "\r\n")  -- envoi contenu message request au serveur SMTP
         else
            conn:close()   -- pas de request dans la table step[state], on ferme la connexion 
         end
         state = state + 1  -- on passe à l'état suivant
     else
         conn:close()  -- la réponse attendue n'est pas la bonne on ferme la connexion
      end
      return(state)  -- Etat en cours en retour
   end
-- gestion des états 
   local step={}
   local smtp_server,smtp_port
   smtp_server,smtp_port = server:match("(.*):(.*)")
   local domain=from:match("@(.*)$")
-- table des états de connexion
   step[1]={expected="^220",request="HELO " .. domain}
   step[2]={expected="^250",request="MAIL FROM: <" .. from ..">"} -- from
   step[3]={expected="^250",request="RCPT TO: <" .. to .. ">"}  -- to
   step[4]={expected="^250",request="DATA"}   -- données
   step[5]={expected="^354"} -- SMTP pret à recevoir des données
-- A addapter en fonction des serveurs de mail  on peut utiliser: To:,  From:,   Reply-to, …
-- A tester pour que le mail ne soit pas considéré comme un Spam.   
-- le From peut être différent du MAIL FROM: (c'est l'adresse mail de retour).
  step[5].request =string.format("From:<%s>\r\nSubject:%s\r\n\r\n%s\r\n.",from,subject,body)
   step[6]={expected="^250",request = "QUIT"} -- headers/message
   step[7]={expected="^221"}  -- quit
-- step[8] se produit sur Evenement "disconnection"

-- création connexion TCP   et traitement des Evenements conn:on("evenement", ...)
   local conn=net.createConnection(net.TCP, false) 
   local state=0
-- Réponses aux Evenements    conn:on 
  conn:on("connection", function(conn)                     -- Evenement connexion OK 
      print("connected") 
      state = 1  
      end )                                                    
                                       
   conn:on("receive", function(conn, payload)            -- Evenement : un message vient d'arriver 
      --print("received:" .. payload)                            -- log du message
      state=handle_response(conn,payload,step,state) -- réponse au message envoyé par SMTP
   end )
   conn:on("sent", function(conn)                              -- Evenement message envoyé
      --print("sent data")  
      end )
 
   conn:on("disconnection", function(conn)                 -- Evenement deconnexion
      print("disconnected:".. state .."Heap="..node.heap())  
-- plusieurs façon de terminer le traitement du mail 
-- fermer seulement la connexion, Reboot, ou se mettre en veille  (avec pin32 et pin8 reliées) avec un boot à la sortie de veille.
      conn:close()  conn=nil
      collectgarbage()  -- ramasse miettes pour faire le ménage dans la mémoire
      print("Finramasse miettes"   .. "Heap=" .. node.heap() )
      node.restart()  -- reboot 
      -- node.dsleep(5000000)  -- reveil dans n microseconds selement si   PIN32(RST) et PIN8(XPD_DCDC)  reliées
   end )

-- Fin réponses aux Evenements

-- on se connecte au serveur SMTP
-- la fonction sendmail va se terminer mais elle sera reveillée par les Evenements conn:on("xxxx" ...)
   print("connecting to " .. smtp_server .. ":" .. smtp_port)
   conn:connect(smtp_port,smtp_server)
end  -- fin fonction sendmail

-- connexion au WIFI en mode Station 
wifi.setmode(wifi.STATION)
wifi.sta.config("SSID","xxxxxxxx")
print(wifi.sta.getip())  -- Adresse IP allouée par le DHCP du routeur
print(wifi.sta.getmac())  -- Adresse MAC esp8266

-- Envoi d'un mail
-- sendmail("from@xxx.yyy","to@xxx.yyy","subject","body1\r\n body2 …","smtp.server.xxx:25")
sendmail("michel.esp8266@orange.fr","esp8266.michel@orange.fr","test envoi mail par esp8266   ","test   \r\n  à 15H17 ","smtp.orange.fr:25")
print("fin" ..node.heap())   -- attention le print s'execute avant la fin de l'envoi du mail
Donc un module esp8266 < 3€, deux piles AAA, et un capteur suffisent pour envoyer une alerte par mail.
On pourrait améliorer le principe en ajoutant un fichier log pour tracer les alertes.
C’est assez facile en lua car on a toutes les fonctions sur fichiers nécessaires :
open, close, readline, writeline, read, write, flush, seek, list, format, rename
Un appel à un serveur NTP pourrait permettre de dater les alertes.
Et pourquoi ne pas envoyer le fichier log en pièce jointe.

Cette puce esp8266, elle à tout d’une grande.

En principe les serveurs de mails sont toujours actifs.
si l'on veut perdre aucun mail, il faut mettre en file d'attente dans un fichier les mails en erreur d'émission (en testant les codes retour envoyés par le serveur SMTP). pour les envoyer plus tard.

On peut si l'on veut traiter les mails en provenance des esp8266 écrire un programme par exemple en python sur un Raspberry qui récupéré des mails structurés d'une certaine façon et qui les traite.

Prochaine étape, tester le protocole MQTT (machine to machine) prévu dans lua.
Ce protocole va peut être s’imposer dans l’Internet des objets (IOT : Internet Of Things).

Mais avant un exemple simple d'utilisation de python pour se connecter sur un esp8266 configuré en serveur Telnet

SMBA38.
par smba38
mar. 24 févr. 2015 20:41
Forum : Et tout le reste
Sujet : Tous les capteurs reliés au RPI par Wifi avec module ESP8266
Réponses : 528
Vues : 179426

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Utilisation d’une puce ESP8266 avec le kit de développement nodemcu..
Voici quelques informations sur ce kit : https://github.com/nodemcu
Et http://www.electrodragon.com/product/es ... ent-board/

Pour utiliser le langage Lua (langage orienté réseau) du kit de développement nodemcu (ou d’une puce ESP-XX) il faut :
Flasher le firmware de l’Esp8266 avec le Flasher : https://github.com/nodemcu/nodemcu-flasher
Télécharger la release 32 ou 64 bits (sous Windows, pour linux il existe un programme python esptool.py).
Un firmware est contenu dans l’exécutable, choisir le port, cliquer sur Flash, appuyer sur le bouton Flash du Kit.
le flasher peut également flasher un firmware à partir d'un fichier binaire .bin
Pour avoir le dernier firmware http://bbs.nodemcu.com/t/nodemcusan-xiao-shi-ru-men/104
Il faut décocher dans l’onglet Config du flasher toutes les lignes INTERNAL et ajouter le PATH du firmware (Avec un Offset=0)

En se connectant sur le port de COM à 9600 bauds 8N1 on a accès à l’interpréteur Lua .

Code : Tout sélectionner

> ŠHlèˆbEC[1A]ù<C[0F]$dñlb<l¬ñ[07]yI[08]€[00]àø
NodeMCU 0.9.5 build 20150213  powered by Lua 5.1.4
> 
Attention au reboot de l’ESP8266 des caractères bizarres sont affichés à 74880 bauds ?.

Via le port série on injecte des programmes lua , ces programmes sont conservés en mémoire flash sous forme de fichiers au format spiffs .

La puce ESP8266 peut être configurée en point d’accès WIFI, en station ou les deux à la fois.
Par défaut l’adresse IP du point d’accès est 192.168.4.1 (IP non modifiable).

On peut programmer facilement des serveurs http, telnet, des sockets , des capteurs (I2C,SPI,Onewire,PWM,ADC), il existe également le protocole MQTT (machine to machine).
Avec un ESP-XX configuré en serveur telnet on peut accéder à distance à l’interpréteur lua.
Une fois programmée la puce ESP8266 peut être autonome, il suffit d’ajouter une alimentation.

Il existe plusieurs modules ESP-XX, pour avoir une entrée ADC il faut un module ESP-12.
Le kit nodemcu dispose d’un module ESP-12.
Les modules ESP-XX diffèrent par le nombre de GPIO, la forme de l’antenne (PCB, céramique, pas d’antenne ) , la mémoire flash, la protection contre les interférences.
http://l0l.org.uk/2014/12/esp8266-modul ... ch-em-all/

Pour limiter la consummation on peut mettre en veille l’ESP8266 par -> node.dsleep().
Au reveil l’esp8266 effectue un reboot.
Pour la liste des Api :
https://github.com/nodemcu/nodemcu-firm ... nstruction


Pour gérer les fichiers de la mémoire flash, on peut utiliser un des programmes :
NodeMcu studio: http://bbs.nodemcu.com/uploads/default/ ... 6986d8.rar
Le programme java: http://esp8266.ru/esplorer/

Le fichier init.lua est lancé automatiquement au boot.
On peut compiler un fichier Lua ->node.compile(“init.lua”) va créer un fichier bytecode “init.lc” dans la mémoire flash.

Voici un exemple de programme lua qui liste les noms des fichiers contenus dans la mémoire Flash.
Pour enregistrer un programme en mémoire, on utilise le module File.
Pour executer un programme: dofile(“xx.lua”)

Code : Tout sélectionner

> file.remove("list.lua")
> file.open("list.lua","w+")
> file.writeline("l = file.list();")
> file.writeline("    for k,v in pairs(l) do")
> file.writeline("      print(\"name:\"..k..\", size:\"..v)")
> file.writeline("    end")
> file.close()

> dofile("list.lua")

name:init.lua, size:2698
name:myfile.lua, size:234
name:list.lua, size:90
name:init - Copie.lua, size:1456
name:init.lc, size:3232
>
-- a simple http server

Code : Tout sélectionner

srv=net.createServer(net.TCP) 
srv:listen(80,function(conn) 
    conn:on("receive",function(conn,payload) 
    print(payload) 
    conn:send("<h1> Hello, NodeMcu.</h1>")
    end) 
end)
Quelques exemples de programmes en lua : http://nodemcu.com/index_en.html#fr_547 ... 501100000f

La suite au prochain numéro.

Retourner vers « Tous les capteurs reliés au RPI par Wifi avec module ESP8266 »