Tous les capteurs reliés au RPI par Wifi avec module ESP8266
Modérateur : Francois
Re: Tous les capteurs reliés au RPI par Wifi avec module ESP
Coucou Jean-Marie,
peut être récupérer l'heure et la date avant d'envoyer via l'ESP un message sur un serveur.
On peut ainsi dater les messages.
Pour récupérer l'heure et la date on peut se connecter sur un serveur NTP.
J'ai lu que c'était possible via des commandes AT.
Ceci n'est peut-être à faire que durant l'initialisation (changement des piles) et ensuite une seule fois par jour .
Dans ce cas il faut tester les valeurs RS1 ,RS2 et INTCN du registre de contrôles.
Cette option est intéressante si l'on veut par exemple avoir des mesures à des heures assez précises.
Sinon on peut ne pas tenir compte de l'heure et de la date que l'on force au 01/01/2015 à 0h00 sur le DS1337.
Et pour l'alarme on ajoute le nombre d'heures et de minutes.
Mais dans ce cas on risque des décalages au bout d'un certain temps.
Cette option peut-être utilisée si la notion d'heure n'est pas importante par exemple pour la constitution d''un graphique avec des captures assez rapprochées.
SMBA38.
peut être récupérer l'heure et la date avant d'envoyer via l'ESP un message sur un serveur.
On peut ainsi dater les messages.
Pour récupérer l'heure et la date on peut se connecter sur un serveur NTP.
J'ai lu que c'était possible via des commandes AT.
Ceci n'est peut-être à faire que durant l'initialisation (changement des piles) et ensuite une seule fois par jour .
Dans ce cas il faut tester les valeurs RS1 ,RS2 et INTCN du registre de contrôles.
Cette option est intéressante si l'on veut par exemple avoir des mesures à des heures assez précises.
Sinon on peut ne pas tenir compte de l'heure et de la date que l'on force au 01/01/2015 à 0h00 sur le DS1337.
Et pour l'alarme on ajoute le nombre d'heures et de minutes.
Mais dans ce cas on risque des décalages au bout d'un certain temps.
Cette option peut-être utilisée si la notion d'heure n'est pas importante par exemple pour la constitution d''un graphique avec des captures assez rapprochées.
SMBA38.
- 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
Hello SMBA38
Tout ce que tu proposes est évidemment possible mais je suis parti de l'idée que tu avais formulée il y a quelques jours, à savoir que ce qui consomme le plus pour la batterie, c'est la communication wifi de l'ESP. J'essaye donc de limiter au maximum la connexion wifi. Je suppose que ce qui dure le plus longtemps est d'établir le contact avec l'unité centrale. Si tu essayes de récupérer l'heure d'un serveur NTP, c'est un deuxième contact et de plus par Internet. Cela peu ramer.
En fait, l'heure et la date peuvent être maintenues par l'unité centrale qui la met à jour journellement ou hebdomadairement avec un serveur NTP. Cette heure est alors ajoutée par l'unité centrale à chaque mesure provenant des modules capteurs périphériques. En réalité, le capteur périphérique n'a pas vraiment besoin de l'heure et de la date. Il doit essentiellement savoir dans combien de temps il va être réveillé. C'est la fonction de la DS1337 qui lui est associée. Il existe d'autres moyens électroniques de décompter le temps mais l'avantage de la DS1337 est sa consommation minime. Donc, on pourrait très bien remettre l'horloge à zéro à chaque boot et simplement inscrire dans l'alarme la "durée de l'endormissement".
Lorsque le capteur périphérique s'est connecté à l'unité centrale et lui a envoyé la mesure, l'unité centrale peut lui répondre en lui transmettant la prochaine "durée d'endormissement", exprimée par exemple en nombre de secondes (1 h = 3600sec, 1 jour = 86400sec et 1 semaine = 604800sec, donc un entier long sur 4 bytes est très largement suffisant). Je crois qu'il vaut mieux renvoyer à chaque fois ces 4 bytes plutôt que de les enregistrer dans l'EEPROM du µC. C'est plus souple car cela permet à tout moment de modifier la fréquence des connexions dans l'unité centrale.
Ceci dit, si on préfère que le capteur envoie sa mesure à heures fixes, il vaut peut-être mieux que l'unité centrale envoie l'heure actuelle et l'heure de la prochaine alarme. De toute façon, je pense que ce qui prend le plus de temps dans le wifi, c'est d'établir le contact avec le routeur et le poste distant, mais une fois que le contact est établi, cela ne doit pas faire beaucoup de différence de transmettre 4 ou 8 bytes. Donc, je serais plutôt partant pour cette solution.
Qu'en penses-tu ?
En ce qui concerne la question de gagner du temps en connexion wifi, j'imagine que le fonctionnement de l'ESP en LUA ou en C est nettement plus rapide que si l'ESP est commandé par un µC externe en commandes AT transmises par liaison série. Avec un µC, il n'est pas trop difficile de faire des mesures de temps précises entre la première commande AT et la fin de la réception de la réponse de l'unité centrale en utilisant un Timer 16 bits et en tenant compte de la fréquence du µC. Je ne sais pas si c'est facilement faisable avec l'ESP. Mais cela ne répondrait pas encore à la question principale qui est combien d'énergie j'ai consommé durant toute la durée du réveil (avec µC externe + ESP ou avec l'ESP seul).
Tout ce que tu proposes est évidemment possible mais je suis parti de l'idée que tu avais formulée il y a quelques jours, à savoir que ce qui consomme le plus pour la batterie, c'est la communication wifi de l'ESP. J'essaye donc de limiter au maximum la connexion wifi. Je suppose que ce qui dure le plus longtemps est d'établir le contact avec l'unité centrale. Si tu essayes de récupérer l'heure d'un serveur NTP, c'est un deuxième contact et de plus par Internet. Cela peu ramer.
En fait, l'heure et la date peuvent être maintenues par l'unité centrale qui la met à jour journellement ou hebdomadairement avec un serveur NTP. Cette heure est alors ajoutée par l'unité centrale à chaque mesure provenant des modules capteurs périphériques. En réalité, le capteur périphérique n'a pas vraiment besoin de l'heure et de la date. Il doit essentiellement savoir dans combien de temps il va être réveillé. C'est la fonction de la DS1337 qui lui est associée. Il existe d'autres moyens électroniques de décompter le temps mais l'avantage de la DS1337 est sa consommation minime. Donc, on pourrait très bien remettre l'horloge à zéro à chaque boot et simplement inscrire dans l'alarme la "durée de l'endormissement".
Lorsque le capteur périphérique s'est connecté à l'unité centrale et lui a envoyé la mesure, l'unité centrale peut lui répondre en lui transmettant la prochaine "durée d'endormissement", exprimée par exemple en nombre de secondes (1 h = 3600sec, 1 jour = 86400sec et 1 semaine = 604800sec, donc un entier long sur 4 bytes est très largement suffisant). Je crois qu'il vaut mieux renvoyer à chaque fois ces 4 bytes plutôt que de les enregistrer dans l'EEPROM du µC. C'est plus souple car cela permet à tout moment de modifier la fréquence des connexions dans l'unité centrale.
Ceci dit, si on préfère que le capteur envoie sa mesure à heures fixes, il vaut peut-être mieux que l'unité centrale envoie l'heure actuelle et l'heure de la prochaine alarme. De toute façon, je pense que ce qui prend le plus de temps dans le wifi, c'est d'établir le contact avec le routeur et le poste distant, mais une fois que le contact est établi, cela ne doit pas faire beaucoup de différence de transmettre 4 ou 8 bytes. Donc, je serais plutôt partant pour cette solution.
Qu'en penses-tu ?
En ce qui concerne la question de gagner du temps en connexion wifi, j'imagine que le fonctionnement de l'ESP en LUA ou en C est nettement plus rapide que si l'ESP est commandé par un µC externe en commandes AT transmises par liaison série. Avec un µC, il n'est pas trop difficile de faire des mesures de temps précises entre la première commande AT et la fin de la réception de la réponse de l'unité centrale en utilisant un Timer 16 bits et en tenant compte de la fréquence du µC. Je ne sais pas si c'est facilement faisable avec l'ESP. Mais cela ne répondrait pas encore à la question principale qui est combien d'énergie j'ai consommé durant toute la durée du réveil (avec µC externe + ESP ou avec l'ESP seul).
Re: Tous les capteurs reliés au RPI par Wifi avec module ESP
Bonsoir Jean-Marie.
Je pense que nous avons deux façon de voir les choses.
Tu utilise l'esp8266 + un microprocesseur pour dialoguer avec un serveur sur lequel se trouve l'intelligence.
Tous les capteurs / actionneurs sont gérés par un seul serveur.
De mon coté je résonne plutôt avec des capteurs / actionneurs autonomes qui disposent de leur propre intelligence.
Pour faire dialoguer entre eux les capteurs actionneurs je pense utiliser un broker MQTT qui ne sert que pour mettre en relation ces capteurs (publieurs) / actionneurs (souscripteurs) et des programmes de traitement des données(souscripteurs) le broker ne dispose pas d'intelligence.
Par exemple je peux avoir:
des esp-xx avec un capteur de température, qui met sont horloge à jour via NTP une fois par jour et qui envoi une mesure une fois par heure(publieur de données).
des esp-xx avec un petit affichage de température et une alimentation sur secteur(souscripteur).
un raspberry station météo (souscripteur) .
un raspberry broker MQTT (qui peut être le même que celui de la station météo).
Si je veux que l'horloge des DS1337 soit le plus possible à jour c'est pour avoir les réveils des ESP-xx à des heures précises.
La station météo ne gère pas les ESP-XX capteurs de température elle récupère seulement via MQTT les valeurs envoyées par les capteurs.
A+
SMBA38.
Je pense que nous avons deux façon de voir les choses.
Tu utilise l'esp8266 + un microprocesseur pour dialoguer avec un serveur sur lequel se trouve l'intelligence.
Tous les capteurs / actionneurs sont gérés par un seul serveur.
De mon coté je résonne plutôt avec des capteurs / actionneurs autonomes qui disposent de leur propre intelligence.
Pour faire dialoguer entre eux les capteurs actionneurs je pense utiliser un broker MQTT qui ne sert que pour mettre en relation ces capteurs (publieurs) / actionneurs (souscripteurs) et des programmes de traitement des données(souscripteurs) le broker ne dispose pas d'intelligence.
Par exemple je peux avoir:
des esp-xx avec un capteur de température, qui met sont horloge à jour via NTP une fois par jour et qui envoi une mesure une fois par heure(publieur de données).
des esp-xx avec un petit affichage de température et une alimentation sur secteur(souscripteur).
un raspberry station météo (souscripteur) .
un raspberry broker MQTT (qui peut être le même que celui de la station météo).
Si je veux que l'horloge des DS1337 soit le plus possible à jour c'est pour avoir les réveils des ESP-xx à des heures précises.
La station météo ne gère pas les ESP-XX capteurs de température elle récupère seulement via MQTT les valeurs envoyées par les capteurs.
A+
SMBA38.
- 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
Hello SMBA38
Je n'ai probablement capté qu'une petite partie de ce à quoi tu penses car je n'ai pas l'habitude d'une série de termes qui sont nouveaux pour moi: souscripteur, broker, MQTT ...
Tu me dis ceci: "je résonne plutôt avec des capteurs / actionneurs autonomes qui disposent de leur propre intelligence. Pour faire dialoguer entre eux les capteurs actionneurs je pense utiliser un broker MQTT qui ne sert que pour mettre en relation ces capteurs (publieurs) / actionneurs (souscripteurs) et des programmes de traitement des données(souscripteurs) le broker ne dispose pas d'intelligence."
Les capteurs / actionneurs doivent-ils dialoguer entre eux ? Je peux comprendre que dans un thermostat, un capteur de T° doit actionner le démarrage de la chaudière. Ceci peut (éventuellement) se passer d'une unité centrale intelligente, mais même dans ce cas, si tu n'as pas d'unité centrale intelligente, il faut absolument un affichage local et la possibilité d'entrer un programme et de le modifier de manière interactive. Donc, ce programme intelligent est nécessaire et il réside soit dans chaque capteur / actionneur, soit en-dehors, c'est à dire dans ce que j'appelle l'unité centrale qui fonctionne 24h/24 et 7jours/7 et qui est évidemment raccordée au réseau électrique.
Certains capteurs et surtout actionneurs peuvent aussi fonctionner sur le 220V s'ils sont près d'une prise de courant.
Ceci dit, j'imagine fort bien que mes arguments ne font que montrer que je n'ai pas très bien compris la manière dont tu envisages de faire fonctionner tes capteurs / actionneurs
Je n'ai probablement capté qu'une petite partie de ce à quoi tu penses car je n'ai pas l'habitude d'une série de termes qui sont nouveaux pour moi: souscripteur, broker, MQTT ...
Tu me dis ceci: "je résonne plutôt avec des capteurs / actionneurs autonomes qui disposent de leur propre intelligence. Pour faire dialoguer entre eux les capteurs actionneurs je pense utiliser un broker MQTT qui ne sert que pour mettre en relation ces capteurs (publieurs) / actionneurs (souscripteurs) et des programmes de traitement des données(souscripteurs) le broker ne dispose pas d'intelligence."
Les capteurs / actionneurs doivent-ils dialoguer entre eux ? Je peux comprendre que dans un thermostat, un capteur de T° doit actionner le démarrage de la chaudière. Ceci peut (éventuellement) se passer d'une unité centrale intelligente, mais même dans ce cas, si tu n'as pas d'unité centrale intelligente, il faut absolument un affichage local et la possibilité d'entrer un programme et de le modifier de manière interactive. Donc, ce programme intelligent est nécessaire et il réside soit dans chaque capteur / actionneur, soit en-dehors, c'est à dire dans ce que j'appelle l'unité centrale qui fonctionne 24h/24 et 7jours/7 et qui est évidemment raccordée au réseau électrique.
Certains capteurs et surtout actionneurs peuvent aussi fonctionner sur le 220V s'ils sont près d'une prise de courant.
Comme je le disais dans mon message précédent, si on préfère que le capteur envoie sa mesure à heures fixes, il vaut peut-être mieux que l'unité centrale envoie l'heure actuelle et l'heure de la prochaine alarme. Nul besoin que chaque capteur se connecte à un serveur NTP si l'unité centrale lui donne l'heure exacte à chaque connection.Si je veux que l'horloge des DS1337 soit le plus possible à jour c'est pour avoir les réveils des ESP-xx à des heures précises.
Ceci dit, j'imagine fort bien que mes arguments ne font que montrer que je n'ai pas très bien compris la manière dont tu envisages de faire fonctionner tes capteurs / actionneurs
Re: Tous les capteurs reliés au RPI par Wifi avec module ESP
RE bonsoir Jean-Marie.
Pour comprendre les termes de MQTT voici le lien du sujet que j'ai écrit sur Framboise314.
http://www.framboise314.fr/linternet-de ... avec-mqtt/
En fait en utilisant MQTT comme passerelle entre les différents capteurs / actionneurs / programmes , on se trouve en mode désynchronisé.
si on envoi un message à un actionneur (souscripteur), celui ci n'est pas forcément actif, il recevra le message (topic en langage MQTT) quand il demandera de lire ce topic.
De même un capteur (publieur) peut envoyer des données sur un topic , ces données peuvent être exploitées plus tard par les souscripteurs abonnés ce topic (un topic peut être persistant).
C'est le même principe que pour les mails , le serveur de mail joue le rôle de MQTT celui qui envoi un mail à une adresse mail ( qui correspond à un topic) est un publieur et celui qui récupère le mail est un souscripteur.
C'est une autre façon de développer, chaque objet peut être souscripteur , publieur ou les deux.
C'est l'IOT l'internet des objets, via un serveur MQTT ouvert sur Internet on peut utiliser les topics avec un raspberry, un smartphone, une tablette, un arduino + un esp8266 dans le monde entier.
Le serveur MQTT date les messages, il n'est donc pas nécessaire que les publieurs disposent de l'heure exacte sauf dans le cas d'un réveil à des heures bien précises ( à quelques secondes ).
A+
SMBA38
Pour comprendre les termes de MQTT voici le lien du sujet que j'ai écrit sur Framboise314.
http://www.framboise314.fr/linternet-de ... avec-mqtt/
En fait en utilisant MQTT comme passerelle entre les différents capteurs / actionneurs / programmes , on se trouve en mode désynchronisé.
si on envoi un message à un actionneur (souscripteur), celui ci n'est pas forcément actif, il recevra le message (topic en langage MQTT) quand il demandera de lire ce topic.
De même un capteur (publieur) peut envoyer des données sur un topic , ces données peuvent être exploitées plus tard par les souscripteurs abonnés ce topic (un topic peut être persistant).
C'est le même principe que pour les mails , le serveur de mail joue le rôle de MQTT celui qui envoi un mail à une adresse mail ( qui correspond à un topic) est un publieur et celui qui récupère le mail est un souscripteur.
C'est une autre façon de développer, chaque objet peut être souscripteur , publieur ou les deux.
C'est l'IOT l'internet des objets, via un serveur MQTT ouvert sur Internet on peut utiliser les topics avec un raspberry, un smartphone, une tablette, un arduino + un esp8266 dans le monde entier.
Le serveur MQTT date les messages, il n'est donc pas nécessaire que les publieurs disposent de l'heure exacte sauf dans le cas d'un réveil à des heures bien précises ( à quelques secondes ).
A+
SMBA38
- 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
Hello SMBA38
Merci pour ton lien.
Devine ce que je vais faire demain.
Si j'aurais su, je m'aurais plongé plus tôt dans cet article
Merci pour ton lien.
Devine ce que je vais faire demain.
Si j'aurais su, je m'aurais plongé plus tôt dans cet article
Re: Tous les capteurs reliés au RPI par Wifi avec module ESP
Bonjour,
désolé de m'incruster au milieu de votre conversation, mais j'ai quelques problèmes avec mon ESP8266
J'ai tout branché pour le flasher avec le firmware nodemcu, et avec j'arrive bien à allumer/éteindre des LED branchées au GPIO, mais quasiment impossible de le connecter à mon wifi !!
Je dis quasiment car je n'ai réussi que 2 fois, et impossible à reproduire. Peut-être allez vous pouvoir m'aider.
* Les pins sont correctement branchés :
VCC, EN en 3,3V
GND sur GND
RX/TX respectivement sur TX/RX du raspberry (j'utilise picocom pour la liaison série)
GPIO0 vers la LED
GPIO2 non connecté
Je fais donc la chose suivante :
si je force une adresse IP avec
J'ai bien l'adresse IP qui s'affiche, mais le module n'est pas pour autant connecté au wifi (non pingable par example)
J'ai aussi tenté avec wifi.sta.connect(), mais c'est pas mieux
A la base je voulais créer un simple serveur http comme ici http://randomnerdtutorials.com/esp8266-web-server/
Quand je regarde les logs de mon serveur DHCP (qui s'avère être mon raspberry avec dnsmasq), j'ai bien des DHCPDISCOVER et DHCPOFFER, mais l'ESP8266 n'a pas l'air de la prendre en compte
J'ai même essayé avec le DHCP de la livebox, pas mieux (enfin je ne peux pas voir les logs...)
Des idées ?
désolé de m'incruster au milieu de votre conversation, mais j'ai quelques problèmes avec mon ESP8266
J'ai tout branché pour le flasher avec le firmware nodemcu, et avec j'arrive bien à allumer/éteindre des LED branchées au GPIO, mais quasiment impossible de le connecter à mon wifi !!
Je dis quasiment car je n'ai réussi que 2 fois, et impossible à reproduire. Peut-être allez vous pouvoir m'aider.
* Les pins sont correctement branchés :
VCC, EN en 3,3V
GND sur GND
RX/TX respectivement sur TX/RX du raspberry (j'utilise picocom pour la liaison série)
GPIO0 vers la LED
GPIO2 non connecté
Je fais donc la chose suivante :
Code : Tout sélectionner
> wifi.setmode(wifi.STATION)
> wifi.sta.config("ssid","lemotdepasse")
> print(wifi.sta.getip())
nil
> print(wifi.sta.status())
1
Code : Tout sélectionner
> wifi.sta.setip({ip="192.168.1.230", netmask="255.255.255.0", gateway="192.168.1.1"})
J'ai aussi tenté avec wifi.sta.connect(), mais c'est pas mieux
A la base je voulais créer un simple serveur http comme ici http://randomnerdtutorials.com/esp8266-web-server/
Quand je regarde les logs de mon serveur DHCP (qui s'avère être mon raspberry avec dnsmasq), j'ai bien des DHCPDISCOVER et DHCPOFFER, mais l'ESP8266 n'a pas l'air de la prendre en compte
J'ai même essayé avec le DHCP de la livebox, pas mieux (enfin je ne peux pas voir les logs...)
Des idées ?
Re: Tous les capteurs reliés au RPI par Wifi avec module ESP
Bonsoir Korhm,
Quelle version de nodemcu utilises tu?.
https://github.com/nodemcu/nodemcu-firm ... v_20150406
Voici un exemple de code
et la trace de la console LUA
SMBA38
Quelle version de nodemcu utilises tu?.
https://github.com/nodemcu/nodemcu-firm ... v_20150406
Voici un exemple de code
Code : Tout sélectionner
-- retrieve the current time from Google
cfg = { ip="192.168.1.154", netmask="255.255.255.0", gatway="192.168.1.1"}
wifi.sta.setip(cfg) -- on force l'adresse IP
wifi.setmode(wifi.STATION)
wifi.sta.config("WRT54G_409B","xxxxxxxxxxxxxxxxxxxxxxxxxxxx")
while (wifi.sta.getip() == nil) do tmr.delay(500000) end print(wifi.sta.getip()) -- vérification adresse IP
function recup(payload)
print('\nRetrieved in '..((tmr.now()-t)/1000)..' milliseconds.')
print('Google says it is '..string.sub(payload,string.find(payload,"Date: ")
+6,string.find(payload,"Date: ")+35))
conn:close()
end
conn=net.createConnection(net.TCP, 0)
conn:on("connection",function(conn, payload)
conn:send("HEAD / HTTP/1.1\r\n"..
"Host: google.fr\r\n"..
"Accept: */*\r\n"..
"User-Agent: Mozilla/4.0 (compatible; esp8266 Lua;)"..
"\r\n\r\n")
end)
conn:on("receive", function(conn, payload) recup(payload) end)
t = tmr.now()
conn:connect(80,'google.com')
Code : Tout sélectionner
NodeMCU 0.9.6 build 20150406 powered by Lua 5.1.4
lua: cannot open init.lua
> dofile("ntp_google.lua")
192.168.1.154 255.255.255.0 192.168.1.1
>
Retrieved in 1700 milliseconds.
Google says it is Fri, 22 May 2015 21:19:07 GMT
Re: Tous les capteurs reliés au RPI par Wifi avec module ESP
Je suis en 0.9.5
Il me semblait que c'était la dernière version
Où as tu trouve la 0.9.6 ?
Il me semblait que c'était la dernière version
Où as tu trouve la 0.9.6 ?
Re: Tous les capteurs reliés au RPI par Wifi avec module ESP
Bonjour,
J'ai indiqué le lien de téléchargement sur message précédent.
sinon le forum de nodemcu est
http://bbs.nodemcu.com
Mais il est conseillé de maitriser le Chinois !
SMBA38.
J'ai indiqué le lien de téléchargement sur message précédent.
sinon le forum de nodemcu est
http://bbs.nodemcu.com
Mais il est conseillé de maitriser le Chinois !
SMBA38.