Interrogation sur les possibilités et exposition d'un projet en cours avec MQTT


#1

Bonjour à tous et enchanté !

Alors je vais commencer par les présentations, je suis depuis plus d’un an, avec mes 2 comparses, Gladys et ses évolutions (merci à Pierre-Gilles pour ses retours régulier sur les avancées et pour les développeurs actifs qui l’accompagne dans sa démarche pour leurs éclaircissements). Nous avions fait quelques essais avec Jarvis et Yana à l’époque mais n’avions pas trouvé ce que nous cherchions et avons donc trouvé Gladys (pause d’1 ans pour raisons personnelles mais nous avions toujours notre projet en tête ). Nous sommes donc revenu sur Gladys en achetant le starter pack pour porter le projet et pour pouvoir avancer rapidement.
Nous avons fait un 1er essai avec installation manuelle via une machine virtuelle windows (Hyper-V) pour monter le serveur complet avec base de donnée accessible phpMyAdmin sur mon pc qui tourne H24. Là beaucoup de bug (beaucoup de module n’arrive pas à se connecter : spotify, googleCalendar… etc ; des modules installés qui disparaissent, etc… si vous le souhaitez, il est toujours installé on pourra reprendre quelques test par la suite). Peut-être avons nous mal fait quelque chose …

Du coup on s’est ensuite concentré sur la récupération des données et la partie actionneur. Bon cela fait longtemps qu’on sait quoi utiliser : l’Arduino s’est imposé de lui même - je m’explique : le but est de pouvoir realiser tout ce que l’on rêve et tout ce que l’on souhaite sans limitation (par la suite en tout cas), ce qui est si je ne m’abuse, la vision de la communauté Gladys. Bon jusque là tout va bien, on connait le sujet, ça fait un an qu’on potasse ce sujet : 433mHz, pilotage de sortie, recuperation d’info entrée, et de valeur analogique. (Je suis automaticien / electricien / gere une conduite centralisée au boulot et un de mes comparse connait bien le langage). Notre but étant de pouvoir utilisé tout mode de communication à distance que ce soit filaire ou ondes (donc ethernet/wifi/bluetooth/433mHz) dans un meme réseau. Et là ça a commencé à coincé puisqu’on restait coincé sur ma communication entre Gladys —》 Arduino. On a trouvé des choses en lien avec l’arduino mais connecté au Rasp-Pi en usb ou via une interface wifi en particulier : ESP8266 (on se concentre là-dessus également, solution très interessante point de vue prix et même technologie que l’arduino). Mais rien ou rien qu’on a réussi à faire fonctionner par Ethernet.
En cherchant un peu plus en profondeur, on a trouvé une chose très intéressante avec Mqtt. On a donc testé le module Owntrack après réinstallation complète de Gladys mais cette fois sur Rasp-Pi et là ça fonctionne parfaitement. On a donc regardé les .json pour comprendre la communication et on pense avoir compris pour la modification pour notre usage même si je pense qu’on aura besoin d’un peu d’aide si vous le voulez bien. Mais apres on seche un peu sur comment Gladys va pouvoir envoyer ses ordres en published pour le moment (on a pensé a de l’envoi en HTTP POST, mais beaucoup trop contraignant à mon goût alors que Gladys est fait pour faciliter tout ça notamment - peut-etre la surveillance de la table de donnée devicestate dans la base donnée ? Des pistes…). Du coup on a préparé notre communication Arduino / mqtt dont on a pu trouver beaucoup d’exemple. Et là on est prêt de se côté là ça fonctionne très bien, l’Arduino publie sur un topic, et via commande sur mosquitto dans un topic on pilote bien les sorties de l’arduino. Voilà donc, on se permet donc de venir à votre rencontre pour vous demander de l’aide côté communication base mqtt —》Gladys—》base mqtt car on a cru voir que Pierre-Gilles etait intéressé de faire entrer pleinement mqtt sur Gladys car celui-ci a largement fait ses preuves tant côté efficacité en communication, que côté sécurité des données. Mais aussi pour partager notre projet et nos avancées dans nos recherches / essais. Si cela vous interesse donc, je peux vous partager par la suite notre projet complet avec plans et réflexions. Notre but final etant de passer au minima par des modules tout fait car la conception de capteur/controlleur/etc ne nous fait pas peur et reduit largement les coup. Notre projet se constituant d’un appartement / une maison perso / un batiment pro / un camping de 4 remplacement avec des actions differentes selon les personnes.

Un grand merci par avance pour vos réponses.


#2

Bonjour @Terdious et bienvenu sur le forum !

Je vois qu’un gros projet est en préparation ^^
Par contre beaucoup de choses reste flou :thinking:

Pourquoi est-ce contraignant ?
Au contraire car Gladys peux envoyer une requête directement depuis un scénario donc pas besoin de module ni de script !

Concernant la communication Gladys MQTT en faite le module n’est fait que pour réceptionner le JSON de OwnTrack pour le moment mais il a été conçu de façon a pouvoir étendre ses possibilités selon les besoins donc il vous suffit de créer une fonction publish au sein du module et de l’appeler depuis un script en lui passant les data !

En revanche je doute que ça soit une bonne solution car ça obligerais l’Arduino à scanner sans cesse le serveur MQTT et comme tu l’as dit @pierre-gilles compte effectivement intégrer MQTT un peu
plus au sein de Gladys ce qui fait que beaucoup de données vont transiter par ce serveur ce qui risquerait de poser problème à l’Arduino étant donné que ce sont des carte assez limité en performance :confused:

Tu éveil ma curiosité donc oui si c’est possible ^^


#3

Hello @Terdious, pour ma part, j’ai fait quelques modifs sur le module MQTT original pour y inclure la gestion du feedback des modules Sonoff.
Si ça t’intéresse, les fichiers sont sur mon github :wink:


#4

Salutation,
Après 10 bons mois d’absence sur ce projet dû à divers raison (travaux/soucis/boulot/démotivation sur les essais…) nous revoilà en bonne voie. Ça fait 2 semaines qu’on a repris les travaux et avons finalement tout repensé. Alors voilà où nous en sommes :
1- Création d’un nouveau module mqtt pour communication avec Arduino évolutif et detournable pour autre chose au besoin, avec gestion de parametres Gladys pour les topic (un topic command/un topic state pour le retour). Simple et efficace.
2- Création d’un programme “type” Arduino qui gère les Sorties TOR et Entrées Analogique (version Uno/nano)
3- Création d’un autre module mqtt pour communication avec Arduino effectuant un scan des Arduino présent sur le reseau et récupérant tout le materiel associé à chaque Arduino, avec gestion de parametres Gladys pour les topic (un topic scan/un topic register pour le retour). (en cours de développement mais la forme est déjà posée et les tests des fonctions sont ok)
4- Création d’un programme “type” Arduino qui gère les Sorties TOR et Entrées Analogique avec tout le listing du materiel piloté par celui-ci (version pour Méga et Due).

Résultat actuel : pour les points 1- et 2-, tout est en place et fonctionnel, pour le moment on pilote les differents éclairage par des plaques relais (en sortie type bouton poussoirs pour les telerupteurs - ou en sortie va-et-vient pour les interrupteurs), et on contrôle l’allumage ou l’extinction par contrôle d’intensité qui renvoie l’etat réel a Gladys. En cas d’allumage par interrupteur poussoir physique on renvoi l’info egalement.
Pour le point 4- Testé et fonctionnel côté Arduino, lors de la création d’un topic ex.:Gladys/scan, l’arduino renvoi tous les périphériques associés, rempli au préalable sur celui-ci, dans un topic ex.: Gladys/register (1 message par deviceType) avec pour message toutes les infos pour créer les pièces, les devices et les deviceTypes (il faut que les maisons soient existantes). Actuellement on a testé avec 1 Arduino Méga et 1 Arduino Due connectés en même temps et comportant chacun 30 devieTypes et tout les messages sont bien réceptionnés sur le broker.
Pour le point 3- le développement est donc en cours mais on a pu tester la créations des room, device et deviceType via script de Gladys et ca marche bien, fin de semaine on devrait être bon.
Et c’est là qu’on a eu un soucis :
Nous avons sur notre projet test (car on voit grand car Gladys le permet ^^) plus de 50 pièces à mettre et lors de la création de nos 65 pièces et bien nous ne pouvons afficher que 50 pièces sur la vue “Logement”. Et du coup les 50 derniers créés, les autres disparaissent (on a eu peur d’une suppression car avec un “room.get” et un “take=100” nous n’avions que 50 room. Mais fort heureusement avec un groom.getall on a été rassuré, tout etais là). Le vrai problème pour le coup etant que la même chose se produit sur la vue “Périphériques” et que ça squizz les rooms des devices. Serait-il donc possible de revoir ce parametre ? Ou est-ce contraignant ?
Autre problème qui n’en ai pas vraiment un mais serait-il possible d’obtenir sur l’API.node une fonction d’appel par room.name en plus du room.id puisque du coup nous devons vérifier que la pièce n’est pas deja existante pour ne pas la recréer puisque il est possible de créer plusieurs pièces avec le même nom sur la même maison. Actuellement nous allons gerer le problème soit par la fonction room.getall et boucler en comparaison, ou en demandant en queries a la BD de trier directement. Sachant que de toute facon si il y a 2 pièces de noms identiques, nous ne créons ni la pièces ni les device associés et on gère l’erreur avec une alerte ( dans les logs et si on trouve une alerte sur le tableau de bord Gladys).

Le projet à repris avec force, pour information de pourquoi autant de pièces : il s’agit de notre maison composée de 16 pièces (pas de vie mais c est la séparation fonctionnelle qui est necessaire) ; un bâtiment composé de 2 parties : une partie pro avec 2 bureaux une salle d’attente un WC, 3 boxes, une sellerie, un stockage paille/copeaux, un pour le foin, un pour le matériel, une carrière, un stabule et une petite station d’épuration - une partie perso avec 2 garages, un stockage bois, un atelier, un poulailler, un escalier, une entrée, un toilette, une bureau informatique et une salle ciné ; 2 mares et un puit ; 4 emplacements de camping-car et une serre ; divers zones pour les extérieurs ; 2 barrières.

Merci d’avance pour vos réponses. Je posterais les plans et la description ce week-end !!


#5

Salut MathieuA,
Tout d’abord merci pour ta réponse et pour l’accueil, et pour le coup un grand désolé pour le temps de réponse.
Alors pour le http Post, c est seulement une question de matériel et de facilité pour ce qui se trouve derriere. Notre projet se situant sur l’association entre Gladys et Arduino, ce dernier à besoin de ses propre ressources pour effectuer le travail auquel il est destiné et le traitement du HTTP POST est beaucoup plus lourd à gérer pour lui que la communication via broker mqtt.

Pour MQTT, en effet nous étions parti sur cette base. Mais finalement, on a tout repris, je te laisse voir ci-dessous en post 4 où nous en sommes !!

Pour la limite des Arduino, on en convient, mais ne participant qu’à leur propres topic, aucun soucis pour tout ce que pourrait gerer Gladys sur le broker. Pour le coup à 12€ la version chinoise et 32€ la version italienne d’origine, un Arduino est largement capable de gérer le nécessaire - réf. Post 4 de nos essais.
Content de voir que ce projet éveil de la curiosité !!^^


#6

Salut Pti_Nico,
Et toute nos excuses également pour le temps de réponse…
Merci pour ce partage et pour ce premier aperçu qu’on a pu avoir et qui nous a permis d’avancer et de repartir sur de bonne base. Je te laisse également voir le post 4 ci-dessous pour connaître l’avancement si cela t’intéresse.


#7

Salut,

Gros projet :slight_smile:

Alors juste pour la partie blocage a 50, tu dois pouvoir jouer sur les paramètres take et offset pour faire de la pagination, genre take=50&offset=51 (ou dans le genre je ne sais plus précisément)


#8

Wow. Beau projet !
De quoi tester la résistance de Gladys à la montée en charge ^^
Fécicitations! … et bon courage pour ce qu’il reste à mettre en place.
Siouplé :pray: des photos et des sources pour les curieux comme moi :smiley:


#9

Salut Andro et merci de ta réponse.
Pour definir le take / offset, tu veux parler de l’appel de requête sur room.get ? Si c’est ça pour le coup on pensais que ce serait plus flexible en passant par getall ou une requête sur la BDD car on ne sait pas d’avance définir ou on devrait pointer.
Si tu parlais plutôt pour l’affichage, tu m’intéresse car on a pas trouvé où on pourrait redéfinir ces variable.on a juste trouvé l’accès à un objet “vm.rooms” dans les dossiers assets et www appeler dans “view” sans trouver comment le redéfinir via un module.
Si Pierre-Gilles pouvait nous donner un coup de pouce !!^^


#10

Salutation Boimb et merci pour l’encourgament, il va en falloir ^^ Quand on voit tout ce qu’il y a à mettre en place en matériel (heureusement tout les câbles ou presque sont tirés), en effet va en falloir pour ne pas abandonner !! Mais il est là et ça pourra bien nous faciliter en pro comme en perso.
Voici donc un 1er plan de ce qu’on prévoit :

  • En Rouge la partie perso avec le camping,
  • En Bleu la partie pro,
  • En Jaune le chemin non perso.

#11

Hello!

Bienvenue sur le projet, super gros et beau projet, ça fait plaisir de voir ça! :slight_smile:

Bien vu, je pense tu es un des rares (si ce n’est le seul) à avoir plus de 50 pièces, donc c’est des petits bugs qu’on a pas forcément eu chez nous :smiley: C’est intéressant de voir une utilisation de Gladys à plus grande échelle, ça va nous permettre de trouver pas mal de petits bugs comme ça.

J’ai créé une issue GitHub pour tracker ça =>

Intéressant! C’est vrai qu’actuellement il n’y a pas de contraintes d’unicité sur le nom d’une pièce dans une maison. C’est à réfléchir mais c’est vrai que ça peut faire sens de se dire que 2 pièces avec le même nom c’est inutile…

J’ai créé une issue Github =>


#12

Salut @Terdious, je viens de corriger le problème des pièces où tu ne vois que les 50 premières, c’est poussé sur master ça partira dans la prochaine version de Gladys :slight_smile:

Merci encore pour ton retour!


#13

Salut @pierre-gilles !!
Oh !! Super, merci beaucoup, hate de tester ça dans la prochaine version. Je te donnerai mon retour.
Je devrais poster une maj de l’installation et des scenarios fonctionnels ce week-end. Le projet avance pas mal.

Bon courage