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

parrain27
Raspinaute
Messages : 905
Enregistré le : lun. 1 déc. 2014 13:46

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

Message par parrain27 » mer. 1 juin 2016 21:56

Oui j'avais vu mes étant pas assez doué de se coté là je pense que vu le prix je vais devoir en recommander un...

Envoyé de mon RAINBOW en utilisant Tapatalk

Avatar du membre
Clemzo
Messages : 55
Enregistré le : ven. 17 oct. 2014 16:36

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

Message par Clemzo » jeu. 2 juin 2016 00:31

Bonjour,

Pour ma part, j'ai déjà eu un problème de reboots intempestifs du une alimentation trop faible.
Raspberry Pi B, B+, Orange Pi et Arduino Pro Mini

parrain27
Raspinaute
Messages : 905
Enregistré le : lun. 1 déc. 2014 13:46

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

Message par parrain27 » jeu. 2 juin 2016 14:56

Mes alimentation sont toutes les même

Envoyé de mon RAINBOW en utilisant Tapatalk

adelantejm
Messages : 31
Enregistré le : ven. 5 oct. 2018 09:11

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

Message par adelantejm » ven. 5 oct. 2018 10:09

J'aimerais bien réactiver ce sujet dont j'ai lu l'ensemble des interventions et qui m'intéresse au plus haut point.
Je voudrais réaliser un ensemble régulateur de chauffage avec un RPI et des ESP8266 ou ESP32 qui a plus de possibilités pour quasiment le même prix.
J'ai déjà réalisé quelque chose avec un ARDUINO MEGA en central branché sur internet et 4 micro arduino en périphérie avec des NRF24l01. un des micro servait à ouvrir ma porte d'entrée à partir d'internet. Tout ceci fonctionnait for bien durant quelques heures seulement (j'arrivais à dépasser les 70 minutes du timer Arduino). J'ai mis au point des fonctionnements en dégradé, mais ce n'est vraiment pas satisfaisant!
Je fonde de grands espoir sur le RPI que j'utilise déjà pour une centrale d'impression accessible de toute la maison en WIFI.
Je pense aussi que l'ESP32 avec son OS, son double coeur et ses timers à 64 bits (100000 ans environ) devrait (?) être fiable.
Avez vous de l'expérience en ce qui concerne la fiabilité des micro processeurs ?

destroyedlolo
Raspinaute
Messages : 1234
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

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

Message par destroyedlolo » ven. 5 oct. 2018 11:10

Salut,

Si tu rentres plus dans les détails de ce que tu veux faire, peut-etre ca serait plus clair dans un sujet dédié. M'enfin ce que j'en dis, ce n'est pas mon forum.
adelantejm a écrit :
ven. 5 oct. 2018 10:09
Tout ceci fonctionnait for bien durant quelques heures seulement (j'arrivais à dépasser les 70 minutes du timer Arduino).
Heu ... Je ne vois pas ou est le pb avec les limites du timer : il suffit simplement que ton code en tienne compte et lance plusieurs fois le timer jusqu'a la durée voulue, non ?
adelantejm a écrit :
ven. 5 oct. 2018 10:09
Avez vous de l'expérience en ce qui concerne la fiabilité des micro processeurs ?
Ben j'utilise pas mal d'ESP8266 et je n'ai pas eu le moindre problème. Pourtant j'en ai 2 qui sont plutot exposés (dans une boite au sol vers la piscine donc soumis aux intempéries et un autre dans le poulailler avec tout ce que cela implique).
Par contre, je ne compte pas sur leurs timers internes pour avoir un timing précis, ce qui est d'ailleurs indiqué dans leur datasheet il me semble.
Plutot, le chef d'orchestre de tout ce beau monde est mon BananaPI qui lui a une horloge précise et fiable car synchronisé au monde par NTP : les commandes et retours se font par echange de messages MQTT et les ESP se réveillent régulièrement (5m ou 30m suivant le besoin) pour envoyer leur info et voir s'il y a des commandes en attente.

Je n'ai pas encore essayé un ESP32 car pas eu besoin de plus de ressources qu'avec un simple ESP. Faudra que j'essaie mais j'ai d'autres priorités avant ... entre etre corrigé des dégas du aux orages de cet été.

A+
  • BananaPI : Gentoo, disque SATA de 2 To
  • Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
  • Multimedia par DNLA
  • Et pleins d'idées ... et bien sûr, pas assez de temps.
Un descriptif de ma domotique 100% fait maison.

adelantejm
Messages : 31
Enregistré le : ven. 5 oct. 2018 09:11

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

Message par adelantejm » ven. 5 oct. 2018 13:43

Merci pour ta réponse,
Oui, je n'avais pas terminé mais j'avais un truc urgent à faire.
Pour le timer j'utilisais la fonction millis() qui repart à zéro toutes les 70 mn sans crier gare. Et je ne sais pas comment on le remet à zéro volontairement, ce qui aurais été une solution car mes temps d'attente ne dépassent pas 30 à 40 mn. J'ai trouvé des solutions alambiquées pas satisfaisantes à 100%.
Mon record de fonctionnement correct doit être de l'ordre d'une semaine, donc je pense qu'il ne s'agit pas d'une erreur grossière de programmation.
Il se peut que le manque de fiabilité vienne des périphériques : DS18b20, nrf24l01, rc522 (lecteur sans contact). J'ai pu constater que lorsqu'un de ces périphériques tombait en panne, l'arduino se bloquait.
En ce qui concerne mes besoins tout est parti de la mise en place d'une chaudière à condensation. J'ai lu sur la notice que le bon rendement n'était obtenu que lorsque la température de l'eau de retour des radiateurs était inférieure à 50°C. J'ai constaté que, souvent la température de retour était supérieure à 50°C. J'ai utilisé un microprocesseur TEXAS à très faible consommation pour arrêter la chaudière 30 mn lorsque la température de retour était supérieure à 40°C. J'ai utilisé 2 batteries CN à faible décharge pour l'alimenter et cela fonctionnait bien durant tout l'hiver.
Puis j'ai voulu améliorer les choses pour arriver à :
- un poste central qui est connecté à internet et permet de modifier tous les paramètres à distance et enregistre chaque seconde toutes les données sur une carte SD,
- un micro "chaudière" qui pilote la température de retour (voir plus haut), mesure la température extérieure, arrête ou met en route la chaudière en fonction d'ordres reçus du central, transmet toutes les infos au central,
- un micro situé près du tableau électrique et qui pilote le chauffage électrique de 3 chambres situées au second en fonction d'ordres reçus du central,
- un micro qui prend la température de ma chambre et la transmet au central (qui régule la marche de la chaudière),
- un micro situé sur la porte d'entrée qui ouvre la porte en fonction d'ordres reçus du central et pilote aussi un RC522 pour ouverture de la porte avec une carte sans contact, il se charge aussi de tenir à jour la liste des cartes autorisées en fonction d'ordres reçu du central,
Tous ces postes communiquent entre eux par l'intermédiaire du central, toutes les secondes, ce qui est trop, 10 secondes devraient être suffisantes.
Quand tout cela fonctionne, j'ai un écran sur mon portable qui me permet de consulter et de modifier la plupart des paramètres.
Nouveau souhait mettre le central, la mesure de température de ma chambre et le central d'impression sur un RPI unique qui sert seulement de central d'impression actuellement. C'est un PI B mais j'ai un PI 3 en réserve si nécessaire.
Je continuerai les détails en tant que de besoin ...

destroyedlolo
Raspinaute
Messages : 1234
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

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

Message par destroyedlolo » ven. 5 oct. 2018 15:04

adelantejm a écrit :
ven. 5 oct. 2018 13:43
Pour le timer j'utilisais la fonction millis() qui repart à zéro toutes les 70 mn sans crier gare. Et je ne sais pas comment on le remet à zéro volontairement, ce qui aurais été une solution car mes temps d'attente ne dépassent pas 30 à 40 mn.
Tu ne peux pas : il démarre en meme temps que l'arduino et c'est tout.
Mais pourquoi ne pas utilisé la fonction delay() qui est faite pour ca ?

Sinon, a nouveau, il suffit juste d'avoir un compteur extérieur et de tenir compte des débordement si tu souhaites rester avec les millis().

adelantejm a écrit :
ven. 5 oct. 2018 13:43
J'ai pu constater que lorsqu'un de ces périphériques tombait en panne, l'arduino se bloquait.
C'est parce que ton code et/ou les librairies sont mal foutus et ne tiennent pas compte d'éventuelles défaillance.
Dans mon cas, c'est simple car je ne fais pas d'attente active mais que des Deepsleep() donc l'ESP est toujours dans la situation d'un redémarrage lors des acquisitions : donc à chaque fois, je teste la présence des périphériques avant de demander leur valeurs.
Mais si tu utilises comme je le pense une boucle sans fin, au moins pour la DS18B20, il ne devrait pas y avoir de pb car la librairie 1-wire ne se bloque pas lorsque tu essaie de contacter une sonde qui n'est plus la.

Pour le reste, ca ressemble dans le fonctionnement plus ou moins a ce que j'ai fait pour ma domotique. Mais, hormis la porte, vu qu'il s'agit principalement de mesurer des températures et de commander des trucs ... y a-t-il une raison particulière pour laquelle tu part sur du herztien ?
Je veux dire, tout ceci se fait très bien en filaire avec du 1-wire ce qui rend les choses beaucoup plus simples ;) Hormis bien sur qu'il faut tirer un bus partout, mais ca reste plus fiable et évite des disperser des alimentations/piles partout, façons pulze.

Sinon, en vrac :
adelantejm a écrit :
ven. 5 oct. 2018 13:43
- un poste central qui est connecté à internet et permet de modifier tous les paramètres à distance et enregistre chaque seconde toutes les données sur une carte SD,
Heu ... j'imagine que tu sais que les SD n'aiment pas les écritures. As-tu vraiment besoin de stoquer les données aussi souvent ?
Ce que JE (qui n'est donc pas parole d'évangile, juste mon idée de la chose :lol: ) ferais, ca serait de garder les données en mémoire pendant 1h ou plus, et de ne stoker que les extrêmes. En tout cas, certainement pas d'écrire sur la SD toutes les secondes. J'espère surtout que c'est dans des fichiers a plat et non en BDD tel que mySQL sinon, c'est la double peine pour ta SD :mrgreen:
adelantejm a écrit :
ven. 5 oct. 2018 13:43
Nouveau souhait mettre le central, la mesure de température de ma chambre et le central d'impression sur un RPI unique qui sert seulement de central d'impression actuellement. C'est un PI B mais j'ai un PI 3 en réserve si nécessaire.
Ben mon BananaPI gère une vingtaines de sondes y compris l'archivage et les automatisations de controle, de serveur de fichier, de serveurs DNLA, mon site et encore pleins d'autres trucs et il est LOIN d'etre changé. Donc un PI B est très largement suffisant.

En tout cas, c'est un jolis projet que tu as fait la.

A+
  • BananaPI : Gentoo, disque SATA de 2 To
  • Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
  • Multimedia par DNLA
  • Et pleins d'idées ... et bien sûr, pas assez de temps.
Un descriptif de ma domotique 100% fait maison.

adelantejm
Messages : 31
Enregistré le : ven. 5 oct. 2018 09:11

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

Message par adelantejm » ven. 5 oct. 2018 18:11

Merci pour ces idées.
Je ne sais pas à partir de quoi travail la fonction delay() mais il n'y a qu'un timer sur le micro de base de l'arduino en plus du watchdog. Je voulais utiliser les interruptions à une époque et cela entrait en conflit avec la fonction micros() (ou millis(), j'inverse peut-être). Enfin c'est du passé : je ne veux plus utiliser d'arduino pour ce genre de projet.
Oui je comprends qu'en redémarrant fréquemment le micro on ait une meilleure fiabilité, c'est ce que je voulais faire : démarrage une fois par jour minimum et si possible une fois par heure, mais c'était un peu compliqué avec le système de réseau que j'utilisais ...
Une chose que je ne savais pas, c'est que le DeepSleep était en fait un redémarrage complet. Sur le TEXAS faible conso (MSP430...) il y avait une astuce qui consistait à déclencher une interruption ce qui entraînait la sauvegarde du contexte et notamment l'adresse de retour qui devenait l'adresse de reprise. Le programme reprenait donc exactement là ou il s'était arrêté.
Pour le filaire je ne pense pas que cela puisse convenir : cela me ferait beaucoup trop de câbles avec en même temps un manque de souplesse.
J'utilise des alimentations qui existent déjà, le tout est de ne pas trop consommer. Par exemple pour la porte, j'utilise l'alim de la sonnette. La serrure électrique consomme un fort courant mais durant 1/10 de seconde. J'utilise donc un gros condensateur qui se recharge en 3 ou 4 secondes. Pour le micro de la chaudière j'utilise l'alime de la chaudière, là aussi il ne faut pas que je consomme trop ...
Oui les cartes SD ont un nombre limité de nouvelles écritures (100000?), mais je n'écris chaque fichier qu'une fois, je veux dire que je ne le modifie pas, j'ajoute des enregistrements. Il y a assez de place pour des dizaines d'années d'enregistrement. Chaque jour à minuit je crée un nouveau fichier ayant dans son nom la date du jour et je ferme le précédent. Il n'y a guère que l'index qui risque d'être réécrit à chaque écriture d'un buffer. Mais normalement les cartes SD gèrent ce Pb en modifiant périodiquement l'emplacement de l'index. Il se peut aussi que l'index soit géré en mémoire vive et écrit seulement à la fermeture du fichier.

J'en viens à mes questions :
Je me suis intéressé à MQTT mais cela m'a semblé lourd pour ce que j'avais à faire. D'autre part je n'avais pas compris que les participants pouvaient se mettre en sommeil et retrouvaient toutes les infos envoyées, à leur réveil.
En fait mon besoin est très simple : le central reçoit une trentaine d'octets de chaque micros (même structure pour tous : des températures en flottant, des nombres sur un octet, les flags sur un octet). Le central met à jour les données des uns pour les autres, ajoute ses ordres et renvoie le tout à chaque micro. Chaque micro utilise les infos qui l'intéresse et met à jour les données qui sont de son ressort. Il renvoie le tout 10 secondes après, toujours même structure. (*)
Autrement dit le serveur c'est le central, toujours en fonctionnement, et les clients ce sont les micros qui s'accordent des périodes de sommeil de 10 secondes (baisse de la consommation).
Un ordre comme : server.send(200, "text/plain", message); devrait permettre au serveur (RPI) d'envoyer les données "message" qui est une structure de 30 octets
et client.print(message); devrait permettre aux micros (ESP, clients) d'envoyer la même structure au central,
puis avec String message = client.readStringUntil('\r'); de recevoir la réponse du central. (**)
Le problème c'est que tout ça c'est du C++ d'arduino mais pas du RPI. Je sais que le RPI peut utiliser le C++ mais je ne connais pas du tout la bibliothèque correspondante avec les fonctions WIFI. Je recherche donc les instructions équivalentes pour le RPI.
Merci d'avance.
(*) mon timing n'est pas bon, mais on devine ce que je veux faire.
(**) l'ordre n'est pas le bon, mais ... idem ...

destroyedlolo
Raspinaute
Messages : 1234
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

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

Message par destroyedlolo » ven. 5 oct. 2018 23:01

Je pense vraiment que tout ceci serait mieux dans un sujet dédié mais bon :)
adelantejm a écrit :
ven. 5 oct. 2018 18:11
Oui je comprends qu'en redémarrant fréquemment le micro on ait une meilleure fiabilité, c'est ce que je voulais faire : démarrage une fois par jour minimum et si possible une fois par heure, mais c'était un peu compliqué avec le système de réseau que j'utilisais ...
Ce n'est absolument pas ce que j'ai dis :)
Ce que j'ai dit, c'est qu'utilisant le DeepSleep, l'ESP redémarrait et donc qu'en repartant de zéro, il était plus ou moins normal de tester si les périphs sont la.
adelantejm a écrit :
ven. 5 oct. 2018 18:11
Une chose que je ne savais pas, c'est que le DeepSleep était en fait un redémarrage complet. Sur le TEXAS faible conso (MSP430...) il y avait une astuce qui consistait à déclencher une interruption ce qui entraînait la sauvegarde du contexte et notamment l'adresse de retour qui devenait l'adresse de reprise. Le programme reprenait donc exactement là ou il s'était arrêté.
Dans le cas de l'ESP, c'est un reboot. Seule une petite partie de la mémoire est conservée : ca permet a l'ESP de sauvegarder les infos techniques sur le WiFi et éviter qu'il refasse les qualibrages et il te reste de la place pour passer un context d'une session a l'autre (j'ai fait une librairie pour facilité la chose si ca t'interesse).

Cool pour les alims :)
adelantejm a écrit :
ven. 5 oct. 2018 18:11
Je me suis intéressé à MQTT mais cela m'a semblé lourd pour ce que j'avais à faire.
J'imagine que tu dis ca par rapport a mon site :)
Je m"y suis interessé car ca me permet d'avoir une archi totalement décentralisée et surtout scalable : en fait, c'est une partie de mon taf de concevoir ce genre d'appli alors ca a été un choix évident ... choix que je ne regrete pas, bien au contraire.
adelantejm a écrit :
ven. 5 oct. 2018 18:11
D'autre part je n'avais pas compris que les participants pouvaient se mettre en sommeil et retrouvaient toutes les infos envoyées, à leur réveil.
Il suffit d'avoir un QoS >= 1 des 2 cotés :)
adelantejm a écrit :
ven. 5 oct. 2018 18:11
Le problème c'est que tout ça c'est du C++ d'arduino mais pas du RPI. Je sais que le RPI peut utiliser le C++ mais je ne connais pas du tout la bibliothèque correspondante avec les fonctions WIFI.
Ha oui, je n'avais pas vu que c'était aussi tes sujet :)
Je comprend du coup mieux la question.

Dans ton appli, c'est du point a point ou du broadcast ?
Si c'est du point a point, il faut te tourner vers les sockets comme je l'indiquais ... mais il n'existe pas (a ma connaissance) d'équivalent strict à ce que tu fais. Donc va falloir tout redévelopper (et le MQTT serait sans doute une solution plus simple :) ).

Si c'est du broadcast, je ne sais plus, ca fait trop longtemps :)

A+
  • BananaPI : Gentoo, disque SATA de 2 To
  • Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
  • Multimedia par DNLA
  • Et pleins d'idées ... et bien sûr, pas assez de temps.
Un descriptif de ma domotique 100% fait maison.

Répondre

Retourner vers « Et tout le reste »