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

Parce que les applications du Raspberry Pi sont illimités...

Modérateur : Francois

smba38
Modérateur
Messages : 193
Enregistré le : mar. 24 févr. 2015 09:28
Localisation : Bourgoin

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

Message par smba38 » dim. 8 mars 2015 11:47

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
Modifié en dernier par smba38 le lun. 9 mars 2015 07:19, modifié 2 fois.

Avatar du membre
Jean-Marie
Raspinaute
Messages : 240
Enregistré le : sam. 24 janv. 2015 18:01
Localisation : Arlon, Belgique
Contact :

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

Message par Jean-Marie » dim. 8 mars 2015 17:31

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.

Avatar du membre
Jean-Marie
Raspinaute
Messages : 240
Enregistré le : sam. 24 janv. 2015 18:01
Localisation : Arlon, Belgique
Contact :

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

Message par Jean-Marie » dim. 8 mars 2015 18:26

Hello SMBA38,

J'ai enfin eu le temps d'examiner un peu plus en profondeur ton message du milieu de la page 8.
Je crois que j'ai à peu près compris ce que tu as fait.
Certainement que les programmes Lua sur ESP et Python sur RaspBerry offrent beaucoup de possibilités mais j'ai quand même l'impression qu'on aurait pu obtenir la même chose de manière plus simple avec les commandes AT.

Cela me fait penser qu'il y a quelques jours, tu a donné une adresse web ouvrant sur 3 fichiers. J'ai oublié l'objet du premier. Le deuxième se nommait "AI-v0.9.5.0 AT Firmware.bin" et le troisième était un fichier .log
Impossible de retrouver cette adresse. Je suppose que le deuxième fichier correspond aux commandes AT v09.5. Correct?
Mes modules ont la version AT+GMR:0018000902-AI03.
Sais-tu où trouver la différence entre ces deux versions? Je voudrais savoir ce que je gagnerais à flasher la nouvelle version.
Comment puis-je trouver la dernière version firmware des commandes AT et où puis-je retrouver ma version si nécessaire ?
D'une manière générale, je trouve que l'information sur les ESP et leur firmware est très éparpillée. On ne sait jamais si ce qu'on lit n'a pas été revu et corrigé à un autre endroit 2 semaines plus tard. A moins que je ne sache pas comment m'y prendre avec ces centaines de GitHub. Je dois dire qu'avant d'aborder le RaspBurry, je travaillais sur des Atmegas et je n'étais jamais confronté à ces GitHub. Atmel, le fabriquant des Atmegas, disposait d'outils et d'une documentation officielle à laquelle on pouvait se fier.

smba38
Modérateur
Messages : 193
Enregistré le : mar. 24 févr. 2015 09:28
Localisation : Bourgoin

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

Message par smba38 » dim. 8 mars 2015 20:45

Bonsoir Jean-Marie.
Jean-Marie a écrit : Cela me fait penser qu'il y a quelques jours, tu a donné une adresse web ouvrant sur 3 fichiers. J'ai oublié l'objet du premier. Le deuxième se nommait "AI-v0.9.5.0 AT Firmware.bin" et le troisième était un fichier .log
C'est peut-être mon message du Mer 4 Mar 2015 17:52.

https://drive.google.com/folderview?id ... lvSkJmNU0
Le premier fichier est le mode d'emploi du programme permettant de flasher la version 9.5 des commandes AT.
Il faut indiquer le PATH du binaire el l'offset=0x00000 avant de flasher.
Le second fichier est le fichier binaire des commandes AT en version 9.5.
Le dernier fichier est un fichier des dernières corrections ou améliorations apportées par la version 9.5.

Pour télécharger le programme qui sert à flasher, voir mon message du Sam 7 Mar 2015 11:16

A+
SMBA38

Avatar du membre
Jean-Marie
Raspinaute
Messages : 240
Enregistré le : sam. 24 janv. 2015 18:01
Localisation : Arlon, Belgique
Contact :

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

Message par Jean-Marie » dim. 8 mars 2015 22:32

Merci Michel / smba38

J'essaye demain sur l'un de mes ESD.

Veloce
Messages : 79
Enregistré le : sam. 24 janv. 2015 20:12

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

Message par Veloce » lun. 9 mars 2015 20:56

Bonsoir les amis

J'ai la grippe en ce moment, donc au lieu de sortir me promener ce week-end,
et d'aller bosser aujourd'hui, et ben je fais la sieste et je programme un petit peu. :(

Pour ne pas pourrir ton post, Jean-Marie, je vais créer un autre sujet.
J'ai donc un serveur web avec un Arduino Uno et un ESP8266, qui pour
l'instant me sert à allumer et à éteindre une LED.

Mais je compte bien intégrer mon code de thermostat de maison, pour régler la
température de ma chaudière à partir de n'importe quel navigateur...

A suivre dans un autre post, donc

Veloce ;)

Avatar du membre
Jean-Marie
Raspinaute
Messages : 240
Enregistré le : sam. 24 janv. 2015 18:01
Localisation : Arlon, Belgique
Contact :

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

Message par Jean-Marie » lun. 9 mars 2015 21:31

Hello smba38
J'ai passé une bonne partie de l'après-midi à débiter du bois (Samedi, on avait abattu un arbre dans mon jardin). Le reste de la journée, j'ai cherché à flasher la dernière version des commandes AT. Le fichier bin se trouve bien à l'adresse que tu as donnée mais je ne trouve pas le programme de flashage. J'ai beau relire plusieurs fois ton message du 7 mars, je ne vois pas ce programme ou son adresse.

J'ai trouvé cette page concernant la mise à jour du firmware de commandes AT et qui contient un lien vers le programme ESP_Flasher.exe. Le site semble bien expliquer la procédure mais il y a plusieurs fichiers à flasher et pas un seul comme ce que tu proposes. Je suis perplexe.

smba38
Modérateur
Messages : 193
Enregistré le : mar. 24 févr. 2015 09:28
Localisation : Bourgoin

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

Message par smba38 » lun. 9 mars 2015 21:56

Coucou jean marie,

Voici le fichier binaire de la version 9.5 (un seul fichier à flasher).

https://drive.google.com/folderview?id= ... 1lvSkJmNU0

Ne laisser qu'un seul fichier à flasher à l'adresse 0x0000

Voit mon message du Sam 7 Mar 2015 11:16 ou il y a une copie d'écran en exemple.

A+
Michel.
Modifié en dernier par smba38 le mar. 10 mars 2015 21:33, modifié 3 fois.

Avatar du membre
Jean-Marie
Raspinaute
Messages : 240
Enregistré le : sam. 24 janv. 2015 18:01
Localisation : Arlon, Belgique
Contact :

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

Message par Jean-Marie » mar. 10 mars 2015 00:21

Merci Michel
Je préfère ne pas laisser de binaires sur le forum.
Je ne vois pas le risque, mais enfin, pas de problème tu peux effacer. J'ai ce bin depuis ce matin.

Par contre, le nom du flasher prête à confusion et laisse penser qu'il s'agit d'un flasher dédié au NodeMCU firmware.

smba38
Modérateur
Messages : 193
Enregistré le : mar. 24 févr. 2015 09:28
Localisation : Bourgoin

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

Message par smba38 » mar. 10 mars 2015 09:00

Bonjour Jean-Marie.

Le flasher de nodemcu peut être utilisé pour flasher d'autres binaires que nodemcu.
Version 64 bits du flasher https://github.com/nodemcu/nodemcu-flas ... lasher.exe
nodemcu est flashé en plusieurs parties Lua, le SDK, Etc.
Pour les commandes AT, Il suffit de décocher les cases cochées par défaut et de rajouter une ligne avec le PATH du binaire des commandes AT et d'indiquer l'adresse 0x00000 (offset) et de cocher la case de la ligne ajoutée.
Il faut ponter temporairement GPIO0 sur GRND pour pouvoir flasher et j'ai également lu qu'il fallait relier le GPIO15 à la masse si GPIO15 existe sur le PCB mais je n'ai pas utilisé le GPIO15 avec le module ESP-01.

Tu peux également flasher nodemcu (Lua) en utilisant les valeurs par défaut du flasher.
Il n'y a pas besoin de fichier binaire pour flasher en nodemcu, il y a plusieurs binaires contenus dans le fichier .exe (auto extractibles).
Ces fichiers auto extractibles sont notés INTERNAL dans l'écran du flasher nodemcu.
Il faut cocher les 4 cases INTERNAL et décocher la case du fichier des commandes AT.

Je modifie le message précédent et je remplace le téléchargement par un lien https://drive.google.com/folderview?id= ... 1lvSkJmNU0

A+
Michel.

Répondre

Retourner vers « Et tout le reste »