Tous les capteurs reliés au RPI par Wifi avec module ESP8266
Modérateur : Francois
-
- Raspinaute
- Messages : 629
- Enregistré le : mar. 6 janv. 2015 19:44
- Localisation : finistere
Re: Tous les capteurs reliés au RPI par Wifi avec module ESP
Oui je pense que le canal 0 est mort, mais vous avez vue que vous pouviez utiliser les autres.
les signaux sur 2 et 4 sont bien du à de "l'induction" surtout si les câbles 2 et 4 sont en nappes avec le 3 et son en l 'aire , ca fait "antenne , pour éviter ca , utiliser que le nombres de câbles nécessaires ou connecter les câbles non utilisés à un potentiel fixe.
bon courage pour la suite.@+
les signaux sur 2 et 4 sont bien du à de "l'induction" surtout si les câbles 2 et 4 sont en nappes avec le 3 et son en l 'aire , ca fait "antenne , pour éviter ca , utiliser que le nombres de câbles nécessaires ou connecter les câbles non utilisés à un potentiel fixe.
bon courage pour la suite.@+
rpi b+ ,osmc, motioneyes
rpi 2 raspbian , server minecraft 24h/24 , utilisation gpio
orange pi pc debian ,utilisation gpio, motion cam
rpi 2 raspbian , server minecraft 24h/24 , utilisation gpio
orange pi pc debian ,utilisation gpio, motion cam
Re: Tous les capteurs reliés au RPI par Wifi avec module ESP
Bonsoir à tous,
http://www.castorama.fr/store/Module-re ... navCount=0
Je ne sais pas si ces modules sont encore vendus, mais c'est pratique pour gérer du 220V.
On peut trouver des informations sur Google -> « interrupteur blyss arduino » sur le reverse engineering du protocole utilisé par Blyss.
C’est vrai que l’on oublie les différents modules de tests qui trainent au fond des tiroirs.
http://dangerousprototypes.com/docs/Bus_Pirate
Pour ma part, j’ai oublié mon BUS Pirate qui permet de tester les protocoles :
– 1-Wire
– I2C
– SPI
– Asynchronous serial
– MIDI
– HD44780 LCD
– 2 et 3-wire + « bitwise pin control »
– mode « raw binary » sur les modes bitbang, 1-Wire, I2C, SPI, et UART
Voir le lien pour des exemples.
https://skyduino.wordpress.com/2011/10/ ... situation/
Voici par exemple l’utilisation du BUS Pirate sur le DS1337.
On peut trouver l’adresse des puces I2C
On peut lire et écrire des données sur l’IDC.
On peut sniffer le bus I2C.
Une fois le BUS Pirate configuré, pour lire des données sur l’I2C on utilise la syntaxe :
[0xd0 0 [0xd1 r:16]
En plus on peut flasher l’AVR pour mettre à jour le BUS Pirate.
c’est INTB qui va passer au niveau bas si INTCN est à 1 et A2IE à 1.
Le signal ne semble pas tout à fait carré sur l'analyseur ?
La suite au prochain numéro.
SMBA38.
Pour réaliser des commandes sans fil, j’ai utilisé pour ma part les modules RF 433MHZ de GROVE avec un Arduino pour piloter des Interrupteurs domotique Blyss de castoramaguillaume9344 a écrit :
Bon courage , je continu à suivre votre post , meme si je n'ai pas encore craqué pour l 'achat des module ESp (je me bas encore avec mes nrf24l01)
@+
http://www.castorama.fr/store/Module-re ... navCount=0
Je ne sais pas si ces modules sont encore vendus, mais c'est pratique pour gérer du 220V.
On peut trouver des informations sur Google -> « interrupteur blyss arduino » sur le reverse engineering du protocole utilisé par Blyss.
C’est vrai que l’on oublie les différents modules de tests qui trainent au fond des tiroirs.
http://dangerousprototypes.com/docs/Bus_Pirate
Pour ma part, j’ai oublié mon BUS Pirate qui permet de tester les protocoles :
– 1-Wire
– I2C
– SPI
– Asynchronous serial
– MIDI
– HD44780 LCD
– 2 et 3-wire + « bitwise pin control »
– mode « raw binary » sur les modes bitbang, 1-Wire, I2C, SPI, et UART
Voir le lien pour des exemples.
https://skyduino.wordpress.com/2011/10/ ... situation/
Voici par exemple l’utilisation du BUS Pirate sur le DS1337.
On peut trouver l’adresse des puces I2C
On peut lire et écrire des données sur l’IDC.
On peut sniffer le bus I2C.
Code : Tout sélectionner
HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO
x. exit(without change)
(1)>4
Set speed:
1. ~5KHz
2. ~50KHz
3. ~100KHz
4. ~400KHz
(1)>4
Ready
I2C>W
Power supplies ON
I2C>P
Pull-up resistors ON
I2C>(1)
Searching I2C address space. Found devices at:
0xD0(0x68 W) 0xD1(0x68 R)
I2C>(2)
Sniffer
Any key to exit
I2C>[0xd0 0 [0xd1 r:16]
I2C START BIT
WRITE: 0xD0 ACK
WRITE: 0x00 ACK
I2C START BIT
WRITE: 0xD1 ACK
READ: 0x19 ACK 0x04 ACK 0x02 ACK 0x03 ACK 0x04 ACK 0x05 ACK 0x06 ACK 0x00 ACK 0x81 ACK 0x82 ACK 0x83 ACK 0x80 ACK 0x81 ACK 0x82 ACK 0x07 ACK 0x83
NACK
I2C STOP BIT
I2C>
[0xd0 0 [0xd1 r:16]
En plus on peut flasher l’AVR pour mettre à jour le BUS Pirate.
Jean-Marie, je pense que tu as voulu dire :Jean-Marie a écrit :- A2F à un signifie qu'il y a eu une égalité entre le temps d'horloge et le registre d'alarme N°2. Ce flag va générer sur INTA un niveau bas si INTCN est au niveau zéro et que A2IE est au niveau un. Si INTCN et A2IE valent 1, c'est INTB qui passe à 0. Aucun de ces cas n'est réalisé ici.
c’est INTB qui va passer au niveau bas si INTCN est à 1 et A2IE à 1.
Oui on peut ne pas indiquer de variable de retour, mais dans ce cas la fonction peut renseigner une ou plusieurs variables globales (Variables accessibles dans la totalité du programme).Jean-Marie a écrit : J'ai plusieurs fonctions du genre char i2c_write(address). Cette fonction retourne théoriquement une valeur de type char. Or les exemples que je vois (et que j'utilise) appellent souvent cette fonction sans valeur de retour, du genre i2c_write(Ad) au lieu de ch = i2c_write(Ad). Est-ce autorisé en C ? Si je me souviens bien, ça ne l'est pas en Pascal.
Donc la question de l’alimentation du circuit à l’initialisation du DS1337 reste d’actualité.Jean-Marie a écrit : @ SMBA38 : la pin 7 pulse bien à 32kHz. Pourquoi je n'ai rien détecté à la carte-son ? PARCE QU' ELLE NE VA QUE JUSQU' A 20kHz !!!
Le signal ne semble pas tout à fait carré sur l'analyseur ?
La suite au prochain numéro.
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 SMBA
J'ai écrit : Si INTCN et A2IE valent 1, c'est INTB qui passe à 0.
En parlant de la SQW après une interruption de l'alimentation ...
J'ai écrit : Si INTCN et A2IE valent 1, c'est INTB qui passe à 0.
J'ai beau relire trois fois ta remarque, je pense que nous disons la même chose.SMBA a écrit :Jean-Marie, je pense que tu as voulu dire :
c’est INTB qui va passer au niveau bas si INTCN est à 1 et A2IE à 1.
En parlant de la SQW après une interruption de l'alimentation ...
Quelle était précisément ton idée ? Se servir du SQW pour déclencher l'alim du module et provoquer un boot de l'ESP et du µC ? Comment faire pour consommer le moins d'énergie possible ?Donc la question de l’alimentation du circuit à l’initialisation du DS1337 reste d’actualité.
Je suppose que tu veux parler du rapport cyclique qui n'est pas 50%. Je ne me souviens pas que la Datasheet précise le duty cycle. D'après l'analyseur logique, l'état haut dure 21 µS et l'état bas dure 9,5 µS. La période est la somme des deux, c à d 30,5 µS.Le signal ne semble pas tout à fait carré sur l'analyseur ?
- 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 SMBA
Voila, j'ai écrit le petit programme que tu proposais.
Et voici la trace dans le moniteur :
.
Sur la breadboard, ma led témoin de la pin SQW/ INTB est d'abord allumée pendant 10 secondes, puis elle s'éteint.
Tout semble donc normal.
Bon, la-dessus je me paye un Senseo !
Voila, j'ai écrit le petit programme que tu proposais.
Code : Tout sélectionner
int main(void)
{
byte Reg;
byte Data[0x10] ={0x50, 0x01 ,0x02, 0x03, 0x04, 0x05,0x06, 0x00, 0x00 ,0x00, 0x00,0x80, 0x81 ,0x82,0x06,0x00};
AVR_init();
UART_init();
stdout = &UART_output;
stdin = &UART_input;
i2c_init();
printf("Ecriture des registres de DS1337\n");
i2c_start_wait(DS1337_W); // set device address and write mode
i2c_write(0x00); // Set Address of Register
for (Reg = 0x00; Reg < 0x10 ; Reg++)
{
printf("Write Reg %X : %X Result %X \n", Reg, Data[Reg], i2c_write(Data[Reg]));
}
i2c_stop();
_delay_ms(5000);
printf("\nLecture des registres de DS1337 après 5 secondes\n");
i2c_start_wait(DS1337_W); // set device address and write mode
i2c_write(0x00); // Set Address of Register
i2c_rep_start(DS1337_R); // set device address and read mode
for (Reg = 0x00; Reg < 0x0F ; Reg++)
{
printf("Reg %X : %X \n", Reg, i2c_readAck());
}
printf("Reg %X : %X \n", Reg, i2c_readNak());
i2c_stop();
while(1)
{
FlashLED();
}
}
.
Sur la breadboard, ma led témoin de la pin SQW/ INTB est d'abord allumée pendant 10 secondes, puis elle s'éteint.
Tout semble donc normal.
Bon, la-dessus je me paye un Senseo !
Re: Tous les capteurs reliés au RPI par Wifi avec module ESP
Hello Jean-Marie.
Mais ta solution d’un contact peut marcher.
A la place du contact on pourrait mettre un interrupteur que l’on ferme au changement de piles et que l’on ouvre après que l'initialisation soit terminée (ça doit être l'affaire de quelques secondes).
A l'initialisation , on pourrait rechercher via le WiFi la date sur un serveur NTP pour mettre à jour l'horloge du DS1337.
Le programme peut s’apercevoir qu’il s’agit d’une initialisation si RS1=RS2=1.
http://www.idreammicro.com/post/Utilisa ... -du-DS1307
Je viens de recevoir les Quartz 32.768KHZ, c’était mon quartz qui ne fonctionnait pas.
Donc voici la sortie à l’initialisation du DS1337. le signal n'est pas trop carré, ça vient peut-être du câble nom blindé que j'utilise, quand j'ai récupéré l'Oscillo il n'y avait pas de câbles.
J'ai commandé des sondes sur Internet.
Nous en sommes au même point sur nos montages, mais je vais attendre que tu résolves la partie électronique pour me lancer à mon tour.
A+
SMBA38
Oui tu as raison, en fait tu indiques en plus qu’avec INTCN=0 A2IE=1 permet de gérer INTA.Jean-Marie a écrit :
J'ai beau relire trois fois ta remarque, je pense que nous disons la même chose.
Oui C’était mon idée pour alimenter les circuits à l’initialisation du DS1337.Jean-Marie a écrit :
Quelle était précisément ton idée ? Se servir du SQW pour déclencher l'alim du module et provoquer un boot de l'ESP et du µC ? Comment faire pour consommer le moins d'énergie possible ?
Mais ta solution d’un contact peut marcher.
A la place du contact on pourrait mettre un interrupteur que l’on ferme au changement de piles et que l’on ouvre après que l'initialisation soit terminée (ça doit être l'affaire de quelques secondes).
A l'initialisation , on pourrait rechercher via le WiFi la date sur un serveur NTP pour mettre à jour l'horloge du DS1337.
Le programme peut s’apercevoir qu’il s’agit d’une initialisation si RS1=RS2=1.
Oui je pensais que le rapport cyclique était de 50%, c’est ce que j’avais vu sur le lien pour un DS1307.Jean-Marie a écrit :
Je suppose que tu veux parler du rapport cyclique qui n'est pas 50%. Je ne me souviens pas que la Datasheet précise le duty cycle. D'après l'analyseur logique, l'état haut dure 21 µS et l'état bas dure 9,5 µS. La période est la somme des deux, c à d 30,5 µS.
http://www.idreammicro.com/post/Utilisa ... -du-DS1307
Je viens de recevoir les Quartz 32.768KHZ, c’était mon quartz qui ne fonctionnait pas.
Donc voici la sortie à l’initialisation du DS1337. le signal n'est pas trop carré, ça vient peut-être du câble nom blindé que j'utilise, quand j'ai récupéré l'Oscillo il n'y avait pas de câbles.
J'ai commandé des sondes sur Internet.
Nous en sommes au même point sur nos montages, mais je vais attendre que tu résolves la partie électronique pour me lancer à mon tour.
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
Je suis bien content que ton nouveau quartz fonctionne bien.
Sur ton oscillo, on voit aussi que le signal bas est plus étroit que le signal haut. Le front montant est un peu arrondi, rappelant la charge d'une capacité à travers la résistance de 10k, mais ce n'est probablement pas la raison car le front descendant est bien carré.
Réfléchissons à la réinitialisation de l'horloge lorsque l'alimentation est rétablie après une coupure.
RS1 et RS2 sont tous les deux à 1 et la pin SQW/INTB pulse à 32kHz.
Les bits RS1 et RS2 nécessitent un µC pour les détecter. Or le µC et l'ESP ne reçoivent leur alimentation que quand l'alarme de l'horloge est déclenchée, c'est à dire quant INTA passe à 0.
On ne peut pas se servir de SQW/INTB de manière directe sur la gate du transistor switch de l'alimentation du module car cela reviendrait à pulser l'alimentation à une fréquence de 32kHz. Il faudrait donc au moins une bascule entre SQW/INTB et la gate. Mais ce serait dommage de devoir alimenter une bascule pendant plusieurs années pour que la DS1337 puisse se réinitialiser automatiquement le jour où on remplace sa pile.
Je continue à penser que la meilleure solution est de prévoir sur le module un bouton de "Reset" forçant l'alimentation du module, la communication de l'ESP avec l'unité centrale, la récupération de l'heure et de la date, provenant soit de l'unité centrale, soit d'Internet (avec une préférence pour l'unité centrale car la connexion est plus rapide et Internet peut être en panne). Il faut également obtenir la prochaine heure d'alarme ou la fréquence de celle-ci et réinitialiser la DS1337 avec toutes ces données. De plus, le bouton "Reset" sera bien utile pour la mise au point du module et pour tout ce qui pourrait se produire et qui n'a pas été prévu dans les programmes informatiques ou à la conception du module.
J'ai reçu (d'AliExpress comme d'habitude) des petites platines photovolaïques de 6 x 6 cm, produisant théoriquement 2V et 150mA.
Dans une piece, non exposée aux rayons aux rayons du soleil, la platine me donne 1,2V.
C'est très largement suffisant comme Vin à un circuit intégré comme le LTC3105 pour charger une batterie Li-ion de 3.6V. Le système est renseigné dans un article récent de Digikey. Je vais tester le système. J'ai déjà reçu les LTC3105 (minuscules !!!) et j'attend avec impatience des batteries 18650 de 3000mA commandées chez AliExpress il y a exactement un mois. J'ai aussi commandé récemment des batteries rechargeables LIR2032 qui pourraient servir uniquement à la DS1332. J'ai hâte de tester les différentes configurations avec la cellule solaire et voir si les batteries tiennent leur charge.
Sur ton oscillo, on voit aussi que le signal bas est plus étroit que le signal haut. Le front montant est un peu arrondi, rappelant la charge d'une capacité à travers la résistance de 10k, mais ce n'est probablement pas la raison car le front descendant est bien carré.
Réfléchissons à la réinitialisation de l'horloge lorsque l'alimentation est rétablie après une coupure.
RS1 et RS2 sont tous les deux à 1 et la pin SQW/INTB pulse à 32kHz.
Les bits RS1 et RS2 nécessitent un µC pour les détecter. Or le µC et l'ESP ne reçoivent leur alimentation que quand l'alarme de l'horloge est déclenchée, c'est à dire quant INTA passe à 0.
On ne peut pas se servir de SQW/INTB de manière directe sur la gate du transistor switch de l'alimentation du module car cela reviendrait à pulser l'alimentation à une fréquence de 32kHz. Il faudrait donc au moins une bascule entre SQW/INTB et la gate. Mais ce serait dommage de devoir alimenter une bascule pendant plusieurs années pour que la DS1337 puisse se réinitialiser automatiquement le jour où on remplace sa pile.
Je continue à penser que la meilleure solution est de prévoir sur le module un bouton de "Reset" forçant l'alimentation du module, la communication de l'ESP avec l'unité centrale, la récupération de l'heure et de la date, provenant soit de l'unité centrale, soit d'Internet (avec une préférence pour l'unité centrale car la connexion est plus rapide et Internet peut être en panne). Il faut également obtenir la prochaine heure d'alarme ou la fréquence de celle-ci et réinitialiser la DS1337 avec toutes ces données. De plus, le bouton "Reset" sera bien utile pour la mise au point du module et pour tout ce qui pourrait se produire et qui n'a pas été prévu dans les programmes informatiques ou à la conception du module.
J'ai reçu (d'AliExpress comme d'habitude) des petites platines photovolaïques de 6 x 6 cm, produisant théoriquement 2V et 150mA.
Dans une piece, non exposée aux rayons aux rayons du soleil, la platine me donne 1,2V.
C'est très largement suffisant comme Vin à un circuit intégré comme le LTC3105 pour charger une batterie Li-ion de 3.6V. Le système est renseigné dans un article récent de Digikey. Je vais tester le système. J'ai déjà reçu les LTC3105 (minuscules !!!) et j'attend avec impatience des batteries 18650 de 3000mA commandées chez AliExpress il y a exactement un mois. J'ai aussi commandé récemment des batteries rechargeables LIR2032 qui pourraient servir uniquement à la DS1332. J'ai hâte de tester les différentes configurations avec la cellule solaire et voir si les batteries tiennent leur charge.
Re: Tous les capteurs reliés au RPI par Wifi avec module ESP
Bonsoir Jean-Marie.
Au bouton, je préfère l'interrupteur qui permet d'alimenter le microcontrôleur sans laisser le doigt sur le bouton.
Comme dans mon cas je pense utiliser des ESP8266 autonomes programmés en LUA, j'ai la possibilité de modifier le programme interprété en WiFi via un client Telnet, et c'est plus pratique de programmer avec les deux mains.
De plus le microcontrôleur peut s'apercevoir qu'il est alimenté depuis plus de n secondes et dans ce cas avoir un comportement différent, par exemple envoyer la valeur lue sur un capteur toutes les minutes.
Tes cellules photovoltaïques vont faire double emploi avec les DS1337, car si ces cellules fournissent assez de jus, il est peut-être suffisant de mettre le microcontrôleur en mode économie d'énergie.
Je regarde de temps en temps les nouveautés annoncées, en voici une:
https://www.kickstarter.com/projects/15 ... 9-computer
Je me pose souvent la question de savoir ce qui peut nous faire choisir un microcontrôleur (ou nano ordinateur) plutôt qu'un autre ?.
La consommation,
la puissance,
Les connexions réseau,
Les entrées sorties (GPIO)
La facilité de programmation.
La taille.
En tout cas ce n'est pas le prix car si on regarde bien un système tout prêt coûte souvent moins cher qu'un système assemblé avec plusieurs composants.
Et comme dans le cas des retraités le temps ne compte pas, ça doit être le plaisir de surmonter les difficultés que l'on s'impose.
En ce qui me concerne, à part les cas ou la consommation et / ou la taille sont primordiales, la solution Raspberry PI me convient parfaitement.
A+
SMBA38
Au bouton, je préfère l'interrupteur qui permet d'alimenter le microcontrôleur sans laisser le doigt sur le bouton.
Comme dans mon cas je pense utiliser des ESP8266 autonomes programmés en LUA, j'ai la possibilité de modifier le programme interprété en WiFi via un client Telnet, et c'est plus pratique de programmer avec les deux mains.
De plus le microcontrôleur peut s'apercevoir qu'il est alimenté depuis plus de n secondes et dans ce cas avoir un comportement différent, par exemple envoyer la valeur lue sur un capteur toutes les minutes.
Tes cellules photovoltaïques vont faire double emploi avec les DS1337, car si ces cellules fournissent assez de jus, il est peut-être suffisant de mettre le microcontrôleur en mode économie d'énergie.
Je regarde de temps en temps les nouveautés annoncées, en voici une:
https://www.kickstarter.com/projects/15 ... 9-computer
Je me pose souvent la question de savoir ce qui peut nous faire choisir un microcontrôleur (ou nano ordinateur) plutôt qu'un autre ?.
La consommation,
la puissance,
Les connexions réseau,
Les entrées sorties (GPIO)
La facilité de programmation.
La taille.
En tout cas ce n'est pas le prix car si on regarde bien un système tout prêt coûte souvent moins cher qu'un système assemblé avec plusieurs composants.
Et comme dans le cas des retraités le temps ne compte pas, ça doit être le plaisir de surmonter les difficultés que l'on s'impose.
En ce qui me concerne, à part les cas ou la consommation et / ou la taille sont primordiales, la solution Raspberry PI me convient parfaitement.
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 SMBA
D'après ce que je comprends, tu préfères un interrupteur parce que la durée de pression sur un bouton est imprécise.
En réalité, dès que l'alimentation est lancée, l'idée est que le module maintienne lui-même son alimentation et ne la coupe que quand toutes les tâches sont terminées.
Je n'ai pas trouvé la durée du boot pour l'ESP. Par contre, je la connais pour un Atmega. On a le choix entre plusieurs durées mais tout le monde choisit toujours la durée la plus longue pour être sûr de la stabilité de l'alimentation et de l'oscillateur interne. Cette durée est de 65 mSec. C'est évidemment très court et je ne pense pas qu'on puisse physiquement relâcher le bouton poussoir avant ça. La première instruction du programme sera de prendre le relais du bouton poussoir en commandant le niveau d'une pin.
Puisque tu envisages d'utiliser l'ESP sans µC externe, tu avais un jour manifesté une réticence à l'idée de consacrer une pin de l'ESP à la gestion de l'alimentation. Cela vaut peut-être pour l'ESP-1 mais l'ESP-12 possède 9 GPIO en plus de l'alimentation, de Rx/Tx, de l'ADC et du Reset. Même si l'ESP doit gérer 3 capteurs, ça laisse encore de la marge.
Je préfère un bouton poussoir parce que c'est moins volumineux qu'un interrupteur et que cela élimine le risque de l'oublier en position ON. Et comme c'est le module qui coupe le courant, il n'y a pas de risque de couper l'alimentation avant que les échanges wifi ne soient terminés. En effet, il peut y avoir du retard parce que l'unité centrale ou Internet peuvent être busy.
Il serait probablement utile de séparer le module capteur-transmetteur (ESP + éventuellement un µC externe) du module d'alimentation. Ce dernier pourrait être de divers types : modèle simple comportant des piles sèches, modèle à batteries rechargeables mais sans système de recharge, modèle à recharge photovoltaïque, modèle à alimentation par le 220V.
D'après ce que je comprends, tu préfères un interrupteur parce que la durée de pression sur un bouton est imprécise.
En réalité, dès que l'alimentation est lancée, l'idée est que le module maintienne lui-même son alimentation et ne la coupe que quand toutes les tâches sont terminées.
Je n'ai pas trouvé la durée du boot pour l'ESP. Par contre, je la connais pour un Atmega. On a le choix entre plusieurs durées mais tout le monde choisit toujours la durée la plus longue pour être sûr de la stabilité de l'alimentation et de l'oscillateur interne. Cette durée est de 65 mSec. C'est évidemment très court et je ne pense pas qu'on puisse physiquement relâcher le bouton poussoir avant ça. La première instruction du programme sera de prendre le relais du bouton poussoir en commandant le niveau d'une pin.
Puisque tu envisages d'utiliser l'ESP sans µC externe, tu avais un jour manifesté une réticence à l'idée de consacrer une pin de l'ESP à la gestion de l'alimentation. Cela vaut peut-être pour l'ESP-1 mais l'ESP-12 possède 9 GPIO en plus de l'alimentation, de Rx/Tx, de l'ADC et du Reset. Même si l'ESP doit gérer 3 capteurs, ça laisse encore de la marge.
Je préfère un bouton poussoir parce que c'est moins volumineux qu'un interrupteur et que cela élimine le risque de l'oublier en position ON. Et comme c'est le module qui coupe le courant, il n'y a pas de risque de couper l'alimentation avant que les échanges wifi ne soient terminés. En effet, il peut y avoir du retard parce que l'unité centrale ou Internet peuvent être busy.
Oui, il est possible que l'énergie fournie par la cellule solaire soit suffisante pour que le µC reste en sleep et se réveille lui-même quand il doit envoyer sa mesure. Mais c'est difficile à prévoir car cela dépend d'une part des conditions d'éclairage (qui diffèrent selon la période de l'année et la localisation géographique) et d'autre part de la fréquence d'envoi des données que tu imposes au module.Tes cellules photovoltaïques vont faire double emploi avec les DS1337, car si ces cellules fournissent assez de jus, il est peut-être suffisant de mettre le microcontrôleur en mode économie d'énergie.
Il serait probablement utile de séparer le module capteur-transmetteur (ESP + éventuellement un µC externe) du module d'alimentation. Ce dernier pourrait être de divers types : modèle simple comportant des piles sèches, modèle à batteries rechargeables mais sans système de recharge, modèle à recharge photovoltaïque, modèle à alimentation par le 220V.
- 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
J'ai reçu aujourd'hui les batteries rechargeables 18650 commandées. Elles ont l'air chargées et donnent actuellement 3,8V.
Mais sacrebleu ! J'ai oublié de commander des boîtiers (holder).
Mais sacrebleu ! J'ai oublié de commander des boîtiers (holder).

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP
Coucou,
Le dash button d'Amazon semble utiliser un ESP8266.
http://www.amazon.com/s/ref=nb_sb_noss_ ... ash+button
http://rue89.nouvelobs.com/2015/04/01/d ... yer-258472
D'autres exemples de "Dash Button"
http://forum.allaboutcircuits.com/threa ... ca.110965/
Plus une simulation sympa http://everycircuit.com/circuit/5147923 ... ash-button
http://www.esp8266.com/viewtopic.php?f=6&t=2240
https://github.com/DeqingSun/ESP8266-Dash-Button
Amazon doit de temps en temps parcourir le forum de Framboise 314 ?
A+
SMBA38
Le dash button d'Amazon semble utiliser un ESP8266.
http://www.amazon.com/s/ref=nb_sb_noss_ ... ash+button
http://rue89.nouvelobs.com/2015/04/01/d ... yer-258472
D'autres exemples de "Dash Button"
http://forum.allaboutcircuits.com/threa ... ca.110965/
Plus une simulation sympa http://everycircuit.com/circuit/5147923 ... ash-button
http://www.esp8266.com/viewtopic.php?f=6&t=2240
https://github.com/DeqingSun/ESP8266-Dash-Button
Amazon doit de temps en temps parcourir le forum de Framboise 314 ?
A+
SMBA38
Modifié en dernier par smba38 le jeu. 14 mai 2015 18:50, modifié 1 fois.