framboise314.fr

... 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. 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 :) 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 :) 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 .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é. MQTT ...

... ...) SMBA3MQTT ...

... avec Mosquitto sur Raspberry et lua sur ESP8266. http://www.framboise314.fr/linternet-des-objets-iot-sur-raspberry-pi-avec-mqtt/ http://forums.framboise314.fr/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. SMBA3MQTT ...

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

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

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

... voici le lien du sujet que j'ai écrit sur Framboise314. http://www.framboise314.fr/linternet-des-objets-iot-sur-raspberry-pi-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+ SMBAMQTT ...

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