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

[Korhm]

Désolé, j'avais pas vu le lien
Dans tous les cas, je galère à flasher mon ESP8266.... hier soir j'avais réussi et croyais avoir compris comment, mais on dirait que non....

J'ai les branchement suivants pour entrer en boot flash
VCC + EN => 3,3V
GPIO0 + GND => GND
RX/TX => TX/RX
GPIO2 => rien

et quand je flash j'ai ceci

Code : Tout sélectionner

sudo ./esptool.py --port /dev/ttyAMA0 --baud 9600 write_flash 0x000000 nodemcu_float_0.9.6-dev_20150406.bin
Connecting...
Traceback (most recent call last):
  File "./esptool.py", line 479, in <module>
    esp.connect()
  File "./esptool.py", line 157, in connect
    raise Exception('Failed to connect')
Exception: Failed to connect

[Jean-Marie]

Hello SMBA38

J'ai lu ton article sur MQTT. Je comprends mieux ce qu'est un publisher, un subscriber, un broker. Le broker est essentiellement un centre de tri et de dispatching. Il reçoit tout ce que les publishers envoient et il distribue les messages reçus aux subscribers intéressés. Mais au-delà de ça, les exemples de programmes concrets dépassent de loin mon background quasi nul en la matière (MQTT, LUA, Python, etc...).

Mais qu'on fonctionne avec MQTT ou avec une Unité Centrale intelligente, j'ai l'impression que cela ne change pas grand chose aux modules capteurs (qui sont des publishers en MQTT), à part le fait qu'avec MQTT, le capteur doit joindre l'heure de la mesure puisque il ne sait pas quand les subscribers vont recevoir le message (à moins que le broker ne soit capable de l'ajouter à la réception).

Donc, avec MQTT il n'y a pas d'Unité Centrale intelligente (sauf la transmission des messages à qui de droit). Mais cela ne veut pas dire qu'il n'y a pas d'intelligence. En effet, chaque subscriber doit posséder l'intelligence qui lui permet de savoir quoi faire en fonction de l'information reçue. Autrement dit, l'intelligence est soit fragmentée dans chaque subscriber, soit rassemblée dans l'Unité centrale. MQTT permet de se libérer des tâches d'envoi et de réception puisque c'est un logiciel tiers qui s'en charge. La logique de fonctionnement entre les capteurs et les effecteurs reste évidemment à écrire.

Dans un système où il y a des centaines de capteurs et d'effecteurs, on y gagne certainement en confiant le dispatching des messages à un logiciel dédié, mais je ne suis pas encore convaincu que cela simplifie le fonctionnement d'une installation privée modeste. D'autant plus qu'il existe déjà des logiciels de domotique destinés à l'Unité Centrale et qui permettent d'ajouter des capteurs (publishers), des actions et des effecteurs (subscribers) et qui peuvent dialoguer avec les divers périphériques selon de multiples protocoles, y compris la simple transmission série (Rx/Tx) (qui risque d'être intéressante avec nos ESP). Je dois dire que je n'ai fait que survoler ces logiciels mais cela semble prometteur.

____________________________________________________________________________________________________________________________________

Hello Korhm

Je vais rechercher les infos, mais il me semble que pour flasher, GPIO2 doit être connecté à 3.3V

[Jean-Marie]

Hello Korhm

Voici les connexions que j'utilise pour le flashage de l'ESP:

Connections pour flashage.jpg (157.43 Kio) Vu 7199 fois

Si tu laisses GPIO2 en l'air et que c'est une pin "open drain", la lecture de son niveau est indéfinie et peut même changer en cours de flashage.
Ceci dit, ce n'est pas certain que c'est la cause de ton échec, mais comme de temps en temps ça marche, c'est plausible.

[Korhm]

Bonjour,

merci infiniment ! Pour la flashage, je crois que j'ai saisie. Effectivement en branchant le GPIO2 sur du 3.3V, sa valeur ne bouge pas. Ca semble logique.

Donc, maintenant, je me remet en mode boot normal (GPIO0 et 2 non branché) et je chargé le code de SMBA38 (que j'ai compilé, mais je pense que ça réagit pareil)
Voici mon output

Code : Tout sélectionner

>
> dofile("ntp_google.lc")
192.168.1.154   255.255.255.0   0.0.0.0
> DNS retry 1!
DNS retry 2!
DNS retry 3!
DNS retry 4!
DNS Fail!

Il y a un problème de DNS à priori.
Ce qui est bizarre c'est que la passerelle par défaut est 0.0.0.0 alors que j'ai précisé l'ip de mon routeur

Code : Tout sélectionner

cfg = { ip="192.168.1.154", netmask="255.255.255.0", gatway="192.168.1.1"}

Idem si je rentre ceci directement dans la console et non via fichier

EDIT : bon pour la passerelle c'est bon en fait, il y avait une coquille dans le code. Mais j'ai toujours le même problème

Code : Tout sélectionner

> dofile("ntp_google.lc")
192.168.1.154   255.255.255.0   192.168.1.1
> DNS retry 1!
DNS retry 2!
DNS retry 3!
DNS retry 4!
DNS Fail!

[smba38]

Hello korhm,

Dans la trace de lua, je vois que tu utilises un fichier compilé .
ntp_google.lc
si tu listes les fichiers de la mémoire flash il doit y avoir ce fichier.
Tu peux détruire ce fichier par un file remove.
Essaye de lancer le fichier ntp_google.lua.

Sur une LiveBox il faut appuyer sur le bouton Wifi (le bouton clignote un certain temps) pour autoriser une connexion Wifi.
La LiveBox peut également être configurée pour tester les adresses mac des cartes wifi qui veulent se connecter.
Regarde sur ta LiveBox si le filtrage par adresses mac est activé.
S'il n'est pas activé je pense que tu dois avoir la liste des adresses MAC / IP des cartes réseau WiFI qui se sont déjà connectées à la box.
Sur les anciennes versions de LiveBox on pouvait manuellement ajouter des entrées dans la liste.

Change le mode Wifi.setmode de STATION en STATIONAP.
A partir d'un Ordinateur / tablette / Smartphone peux tu voir le SSID de l'ESP8266 ( il se termine par les derniers caractères de l'adresse MAC de l'ESP8266).


Tu peux également mettre en commentaire la configuration WIFI de Lua, car une fois quelle est programmée, elle est conservée en mémoire Flash et au reboot le connexion WiFi est établie automatiquement.

Tu peux également essayer de forcer un reboot (mettre le GPIO RST à la masse)

En créant le fichier init.lua, celui ci est automatiquement lancé au boot.


A+
SMBA38.

[Korhm]

Bon,

pour voir si ça venait du firmware ou autre, j'ai mis un firmware de base et exécuté les commandes AT.
C'est pas mieux....

Code : Tout sélectionner

*** baud: 115200 ***
AT+CWMODE=1

OK
AT+CWJAP="HelloWorld!","motdepasse"
+▒▒jRjR2%15)▒▒PuTTY
ERROR

On dirait qu'il se passe quelque chose. La liaison série esssai de me dire qqch mais ça s'affiche mal
Un problème de baudrate ? (je suis connecté avec putty sur mon raspberry qui lui est connecté en série à l'ESP8266)
Un problème d'alimentation au moment de la conection ? A la base j'étais branché sur le 3.3V du raspberry. Maintenant j'ai mis du 5V avec un régulateur vers 3.3V. Mais c'est pas mieux.

Côté livebox, je n'ai pas de filtrage MAC, et j'ai toujours appairé mes différents terminaux sans appuyer sur aucun bouton.

J'ai pas encore testé en monde AP

[smba38]

Bonsoir,

Pour voir les messages du boot, il faut indiquer 74880 comme vitesse de la liaison série.
Essaye avec AT+CWMODE=3
AT+RST

---reboot
AT+CWJAP="ssid","12345678"
OK
AT+CIFSR
192.168.1.134



SMBA38.

[smba38]

Coucou Jean-Marie.

Je pense que tu as raison, pour faire un projet simple bien maitrisé il n'est pas nécessaire d'utiliser MQTT.

Les informaticiens aiment bien se faire plaisir avec les protocoles , les réseaux, les différents langages bref les usine à gaz.
Ils pensent toujours aux évolutions possibles, aux données pouvant être exploitées par différents moyens.
Il sont fidèles à leur devise: pourquoi faire simple quand on peut faire compliqué.

Le protocole MQTT est intéressant si l'on veut exploiter les données des capteurs de différentes façons:
Smartphones, Ordinateurs, Tablettes, Microcontrôleurs avec différentes présentations: compteurs, graphes, statistiques ...
La partie communications est simplifiée car il existe des clients MQTT sur toutes les plateformes.

Mais l'électronicien aime également bien la complexité.

Ou en est ton montage avec ESP8266, ds1337, Quartz, résistances, transistors CMOS, batteries, boutons, cellules photovoltaïques , Arduino (j'en oublie surement)

A+
SMBA38.

[Jean-Marie]

Hello SMBA38

En théorie je suis prêt à tester l'alimentation avec un système minimum comprenant une batterie 3.7V alimentant en direct la DS1337. L'alarme de celle-ci débloque le P-MOSFET et boote l'Atmega qui maintient son alimentation le temps nécessaire à ses tâches.
Mais un imprévu vient contrecarrer un peu mes plans. Je travaille habituellement sur un PC de bureau déjà assez agé, fonctionnant en Windows XP. Depuis quelques semaines, il se bloquait parfois sur un écran bleu (je suppose que tu sais ce que ça veut dire : nécessité d'éteindre l'ordi de force pour le relancer quelques secondes plus tard). Mais ces 3 derniers jours, ça s'est franchement aggravé: au moins 3 ou 4 écrans bleus par jour, y compris pendant que le PC est laissé à lui-même et que théoriquement il ne fait rien.
Ce matin, j'ai donc sorti mon portable qui est en Windows 8.1 avec l'intention de transférer toutes mes données sur cet appareil et d'y installer les logiciels que j'utilise habituellement. Ensuite, je réinstallerai peut-être WinXP sur le vieux PC, uniquement pour la sauvegarde des données sur un disque dur.

Hier, j'étais en train d'écrire le programme pour faire les tests de l'alimentation quand un écran bleu est survenu, me faisant perdre le travail en cours. Vraiment, je suis obligé de remédier à ça avant de continuer les tests. J'ai aussi l'intention de remplacer l'Atmega328 que j'utilise actuellement (32 Megas de flash et 28 pins en through hole) par un Attiny85 (8 Megas et 8 pins en SOIC), ce qui fait gagner beaucoup de place mais demande des adaptations logicielles car le Hardware des liaisons UART et I2C est plus simple que dans l'Atmega. Quant à l'Arduino, j'évite au maximum à cause de l'opacité des diverses librairies.

En ce qui concerne le MQTT, je suis loin d'affirmer que je n'y viendrai jamais, comme pour l'utilisation du SDK et de LUA. Mais tant que c'est possible je préfère maîtriser le système avec des moyens qui me sont plus familiers. Je comprends néanmoins que la mise en oeuvre d'un Atmega soit considérée comme un gros morceau pour quelqu'un qui l'aborde pour la première fois.

[Korhm]

Bonjour,

après m'être démené par mal de temps, je commence à cerner le problème.
* Sur mon réseau, le serveur DHCP est fait par un seveur debian, pas par la livebox. Dans la norme DHCP, les requêtes DHCPDISCOVER sont faites en broadcast (important pour la suite). Sur le logs du serveurs, je vois bienles DHCPDISCOVER arrivées et une réponse DCHPOFFER
* J'ai désactivé le DHCP sur mon Debian, et réactivé celui de la livebox : l'ESP8266 obtient bien une IP dans ce range là, et se connecte ! Youpi
* MAIS, depuis l'ESP, je n'arrive qu'à faire des requêtes TCP vers la livebox (mais vers aucun terminal sur le LAN ou sur l'internet)
* Et inversement, depuis le LAN, je n'arrive pas à atteindre l'ESP.

Pour information, si je mets mon iPhone en mode hotspot et que je me connecte dessus, j'arrive bien à atteindre internet.

Donc à priori ça semble un problème de routage côté livebox.....