[NEWS] Multi-instances & prochaine génération de modules Gladys!


#21

Tu pars toujours sur du MQTT intégré dans Gladys ?


#22

Complétement!

C’est dans la do list :slight_smile: Il y a déjà une partie du travail de fait sur une branche, mais c’est en standby en attendant que je finisse d’autres chantiers en cours plus important


#23

En plus l’avantage de mqtt c’est que ça permet de faire les modules avec n’importe quel outils. Genre un NodeMCU/ESP qui lit une valeur d’un capteur, envoie le message à Gladys, qui l’interpretre et envoie à son tour un message sur MQTT qui pourra être “gérer” par un daemon/script en Java/Rust/Python/brainfuck !


#24

Le plus “dur” c’est de réfléchir à la manière optimale de gérer les topics/payload MQTT.


#25

On perd pas en rapidité tout ce dialogue ?


#26

MQTT est conçu justement pour être rapide:
https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_mqtt_the_protocol_for_internet_of_things?lang=en

http://rexpie.github.io/2015/08/23/stress-testing-mosquitto.html

It can handle at least 20k simultanious connections at a speed of 7000+ messages per second for a single 2.1g core virtual server with just 12MB of mem.

Je pense qu’à moins d’avoir une installation de taille industrielle ça ne devrait pas poser de problème.

Il y a même des meilleurs performances avec un système de Queue qu’avec une API REST.


#27

J’ai déjà fais la conception donc le plus dur est déjà fait !

Complètement, comme dit @jibaku, c’est beaucoup plus light qu’en HTTP, ça va très très vite

Et surtout c’est bi-directionnel


#28

Ca me semble important comme truc pour assurer une stabilité de Gladys et faire en sorte d’avoir des modules tous développés de la même manière. J’espère que c’est tout en haut de ta to do list… :wink:


#29

@Hamtaro : si j’ai déjà fais la conception + une partie de l’implementation, c’est que ça l’est ! :wink:


#30

@MathieuA : En plein boulot sur le MQTT je me posais justement la question du module Z-wave. Si jamais on décide de déporter le module Z-wave hors de Gladys à l’avenir, comment on ferait si on veut avoir des vues customs pour ce module ? Pour ça que je voulais bosser sur le MQTT avant, pour avoir une vision là dessus aussi ^^

J’ai du mal à voir comment ça pourrait se goupiller tout ça… soit on standardise pour que tout passe par MQTT ( comme je fais actuellement pour tous les modules ), mais ça ça veut dire pas de vue custom

Soit pour la vue custom on a pas trop le choix de mettre un frontend custom dans Gladys à un moment ou un autre (je me vois mal envoyer le HTML via MQTT au démarrage du module… quoique :stuck_out_tongue: )

Bref, si quelqu’un a une idée là dessus ^^


#31

Pourquoi forcément passer par Gladys ?
Si le module est déporté il peux aussi très bien fonctionner comme un mini serveur qui affiche sa propre page web non ?
A ce moment là Gladys envoi l’ordre de démarrer le mini serveur de config et redirige l’utilisateur vers cette page la (ça peux même ce faire avec un iframe )

Une fois la config terminé Gladys envoi l’ordre de tuer le serveur. :slight_smile:


#32

Oulà le problème c’est que là on apporte énormément de complexité à un module qui devait être simplifié justement :smiley:

Qui dit page web dit :

  • Internationalisation
  • SSL et compagnie (proxy nginx)

C’est justement ce qu’on veut éviter, l’objectif c’est que Gladys centralise la vue, et que les modules ne soient que des petits drivers distants !

Et surtout ça serait top que la communication Gladys <-> module distant soit 100% en MQTT

Car l’objectif de ces modules c’est d’avoir justement des petits modules distants qui ne sont pas exposés à internet ni accessible en HTTP


#33

La seule solution que je vois c’est la standardisation…

Exemple: Le module Z-wave déclare qu’il a 12 fonctions via MQTT, et Gladys créé une page de configuration custom avec ces 12 boutons, mais bon c’est pas hyper sexy on pourra pas s’amuser avec la vue


#34

Ah bah la tu rajoute énormément de contraintes techniques :stuck_out_tongue:

Dans ce cas là je vois que deux possibilités !

  1. Soit tu envoi l’HTML complet avec le controller et les commandes qui vont avec
  2. Soit il faut créer une vue générique auquel chaque développeur devra s’adapter et selon les données envoyée par le module, Gladys construis la vue, mais bon ça risque d’être compliqué pour gèrer tout les cas et même pour le côté développement du module…

Il y aurait bien une troisième méthode mais je doute que ça soit la meilleur :thinking:

Je te la donne quand même au cas où elle t’inspire ->

Les modules se compose en deux partie

  1. La première est la partie générale, la partie driver qui s’installe sur n’importe quel périphérique
  2. Et le seconde est la partie config qui elle s’installe du côté Gladys avec juste les assets et la vue custom qui utilise l’API MQTT de Gladys pour communiquer avec son maître

Évidement c’est à Gladys de faire la différence lors de l’installation du module. Grâce à une certaine hiérarchisation par exemple…


#35

Mm j’avais les mêmes 3 idées en tête ^^

Je pense que pour l’instant on va choisir la solution 4 : Garder le module Z-Wave en interne pour l’instant :smiley:

Sinon des trois, la solution la plus crédible pour moi c’est la dernière! C’est la plus cohérente, parce que du coup ça veut dire que le développeur du module contrôle la vue + le driver distant, et c’est pas forcément beaucoup plus de dev. A investiguer :slight_smile:


#36

Si on garde le module Zwave en interne ma vue custom ne fonciotnnera pas :joy:


#37

Hein ? ^^ Ta vue custom on va l’intégrer dans le module hein !


#38

Bah oui mais pour ça il faut que le module puisse charger ses assets donc a moins que t’ai un truc dans les cartons en attendant la partie MQTT ses assets ne seront pas chargés ^^


#39

Ah oui oui mais ça c’est prévu !


#40

Yo guys ! Je sors un premier draft du module gladys-mqtt-adapter (pas encore de code dispo, juste de la spec), c’est une dépendance NPM qui permettra de créer très facilement des modules Gladys remote, juste à ajouter la dépendance et à suivre les instructions :slight_smile:

J’ai publié ça sur GitHub, pour ceux que ça intéresse =>