Tous les capteurs reliés au RPI par Wifi avec module ESP8266

[Veloce]

Salut Jean-Marie,

bravo et merci pour tes explications.
Finalement c'était une bonne idée d'utiliser un module pour émettre et un pour recevoir,
comme ça en une expérience tu peux tester les deux côté de la connexion.

Il est vrai que la ligne reliant le Tx de l'ESP au Rx de l'Arduino ou du convertisseur ne nécessite théoriquement pas de régulation, sauf que ... j'ai deux convertisseurs USB-Série et l'un d'eux a un marquage Rx/Tx inversé de sorte qu'il est très facile de connecter ces pins à l'envers. Voilà pourquoi il est prudent de sécuriser les deux lignes.

Bien sûr, tu as raison. Avec mon montage, si jamais j'inverse les fils RX et TX,
ou si je configure la patte en sortie au lieu d'une entrée, je risque de cramer mon module.
Mais je fais attention et de toute façon je vais souder tout ça sur une plaque à trous.

Code : Tout sélectionner

AT+CIPSEND=7: Commande d'envoi de 7 caractères (Maximum= 2048). La réponse est >. Après ce signe il faut impérativement décocher l'envoi de CR et LF.

Tiens c'est intéressant. Qu'est-ce qui se passe sinon ? C'est vrai que dans les exemples que j'ai trouvés,
on ne termine pas par "\r\n" comme on le fait pour toutes les commandes AT.
Est-ce que tu as essayé en mettant 9 comme longueur ?

Les caractères envoyés apparaissent alors dans le Terminal du PC n°1, sous la forme suivante:
+IPD,0,7:Bonjour

Oui, et pour compléter ton explication, ici le "0" est le numéro de la connexion. Pour répondre au PC n°2, il faut envoyer sur le PC n°1:

Code : Tout sélectionner

AT+CIPSEND=0,5
>Salut

Eh oui pas besoin d'ouvrir une nouvelle connexion puisque le client est déjà en ligne.


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 ?

Veloce

[Veloce]

En tous cas ton sujet a fait péter tous les compteurs.

J'ai relu les règles du forum, et ça va: on n'est pas forcément obligés de parler de framboise.
Ouf, on ne sera pas bannis.

Veloce

[Jean-Marie]

Hello Veloce,

Au sujet de la longueur du message envoyé par le PC n°2, j'ai fait l'expérience suivante:
J'ai envoyé la commande AT+CIPSEND=7 avec l'idée d'envoyer Bonjour suivi de CR+LF (les cases correspondantes restent cochées).
Résultat:

• wrong syntax
• ERROR
• SEND OK
• OK
• Unlink

490.jpg (114.73 Kio) Vu 7882 fois

Du côté du serveur, le message a bien été reçu mais il est suivi de l'avis Unlink

491.jpg (7.57 Kio) Vu 7882 fois

Du côté périph, je me relink au serveur avec AT+CIPSTART=.....
Le serveur reçoit Link.

Là, j'essaye de suivre ton exemple en tapant dans le serveur

AT+CIPSEND=0,5
>Salut

Sacrebleu, c'est fantastique. Ça marche super bien.
Le périph reçoit son Salut et est TRRRès content d'avoir été reconnu par le serveur.
Merci Veloce

[Jean-Marie]

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 !"

[smba38]

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

tableau_tests.JPG (88.64 Kio) Vu 7873 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

Web ethylomètre.JPG (23.8 Kio) Vu 7873 fois

Test N°5

Base de données thingspeak

ThingSpeak.JPG (17.38 Kio) Vu 7873 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.

[Jean-Marie]

J'ai trouvé cette information sur le Power management :

Power management.jpg (94.11 Kio) Vu 7873 fois

Il semble donc que le plus intéressant pour les batteries est de mettre le module OFF en commandant la pin CH_PD (Chip Power Down) par le µC externe.

[smba38]

Bonsoir Jean-Marie.

Avec le CH_PD off on perd l'état des registres et la connexion wifi est coupée.
Si l'on doit conserver des informations sur l'état en cours il faut les conserver sur la mémoire flash ou sur le micro qui gère la puce (si celui ci existe).

Si un micro géré le CH_PD de la puce, il faut également essayer de trouver une solution pour que celui ci ne consomme pas trop.

Le Deep Sleep est intéressant car il conserve des informations sur la connexion Wifi, mais il consomme plus.

Il est peut être possible pour se passer de microcontrôleur de concevoir un petite électronique pour gérer le CH_PD?.

Je pense que le concept esp8266 va rapidement évoluer et que des solutions seront trouvées.

A+
Michel.

[Jean-Marie]

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.

Si l'ESP est en commande AT, il peut carrément être en Power Down (Mode OFF du tableau d'Espressif) puisque le programme est dans un µC externe. D'ailleurs, le µC lui-même peut aussi être en Power Down. L'ATtiny85 consomme 2 µA en Power Down mais il a aussi besoin d'une interruption externe pour se réveiller.

Il est peut être possible pour se passer de microcontrôleur de concevoir un petite électronique pour gérer le CH_PD?.

Il existe des puces spécialisées comme le TPL5010 et TPL5110 de Texas Instrument (Ultra Low Power Timer) qui consomme 35 nano Ampère et peut compter des périodes jusqu'à 2H. Il peut réveiller soit l'ESP, soit le µC, soit activer un MOSFET qui alimente alors le µC et l'ESP. Malheureusement, le TPL5010 est nouveau et pas encore disponible sur eBay ou AliExpress. En petites quantités, il devrait coûter environ 1€ pièce.

[freedom2000]

Bonjour à tous,

Je n'ai pas de raspberry, mais j'ai un ESP8266 !
Pour l'instant réussi à le flasher en nodeMCU et retour AT firmware
Testé en connexion client TCP socket entre un PC + port série (commandes AT) et un android serveur TCP
Que du bonheur !

J'ai aussi installé le framework windows. Il suffit de suivre scrupuleusement les instruction et on arrive à compiler les exemples très vite.
Bon après de là à dire que la programmation en C est simpe... Pas tellement le langage, mais le manque de doc sur l'API Espressif.

Voila j'en suis là pour l'instant
JP

[freedom2000]

Il existe des puces spécialisées comme le TPL5010 de Texas Instrument (Ultra Low Power Timer) qui consomme 35 nano Ampère et peut compter des périodes jusqu'à 2H. Il peut réveiller soit l'ESP, soit le µC, soit activer un MOSFET qui alimente alors le µC et l'ESP. Malheureusement, le TPL5010 est nouveau et pas encore disponible sur eBay ou AliExpress. En petites quantités, il devrait coûter environ 1€ pièce.

ou alors une horloge temps réel capable de sortir une interruption "alarme". On en trouve chez Maxim
Comme c'est de l'I2C avec NodeMcu on peut facilement la programmer avec le ESP8266.
L’interruption servirait à réveiller le deepsleep

JP