framboise314.fr

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+

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 ...

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+

Hello Fidoboulettes,

Le script est prévu pour gérer 2 capteurs, comme tu en as un seul une seule température à chaque passe.
Donc ça fonctionne.

Quel GPIO as tu utilisé?.

le script n'est pas tout à fait le même les trm.delays ne sont pas identiques.
Peut être que l'ESP-201 à une horloge différente que celle de l'ESP-12 que j'utilise (Kit NodeMCU).

Le mieux c'est d'avoir un programme compilé et pour ça l'IDE ESP8266 / Arduino est pas mal.
Lua c'est bien pour réaliser rapidement des programmes qui doivent gérer un réseau (Sockets, Telnet, MQTT ...)


SMBA38.

Bonsoir Cosmic Mac,

Il existe un forum pour se présenter sur Framboise314
viewforum.php?f=59

Pour ma part, j'ai fait pas mal de tests avec lua (Mails, ntp,i2c,Telenet, sockets)
tu peux les retrouver sur viewtopic.php?f=36&t=628

Je me suis également intéressé à l'IOT , le protocole MQTT avec Mosquitto sur Raspberry et lua sur ESP8266.
http://www.framboise314.fr/linternet-de ... avec-mqtt/
posting.php?mode=reply&f=36&t=628

Lua peut être compilé, mais je pense que c'est du pseudo code.
On peut même passer à Lua du code source sous forme d'une chaine de caractères que Lua interprète.
C'est dommage que NodeMcu ne soit pas réactif aux mises à jour du SDK d'Expressif.

SMBA38.

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.

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.

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

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

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.

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.

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.

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