Salut à tous !
Ca fait longtemps que j’en parle, je voulais vous exposer ma vision au niveau du multi-instance dans Gladys, et à quoi vont ressembler les prochains modules Gladys.
L’objectif est de vous présenter ça, à vous de challenger le concept et de me dire votre avis là dessus 
L’objectif
On a beaucoup parlé du multi-instances Gladys. L’objectif serait de pouvoir gérer différentes maisons ou différentes zones (si vous avez des grandes maisons).
Exemple: J’ai un Raspberry Pi dans le salon qui gère ma maison, un dans mon abri de jardin qui gère des périphériques du jardin, et un dans ma maison de vacances qui gère ma maison de vacances.
Problème: Je ne veux pas avoir 3 interfaces web différentes, 3 Gladys différentes. C’est normal, ça serait trop de boulot à configurer, et pas clair du tout.
La réflexion
En y réfléchissant, je me suis rendu compte que vouloir lancer 3 instances Gladys qui se gèrent entre elles n’était pas vraiment concevable ni intelligent. Avoir sur chaque Raspberry Pi un Gladys complet + une base de donnée MySQL, est-ce vraiment utile ? Maintenir un état consistent entre les 3 instances, en prenant en compte tous les aléas, est-ce vraiment ce qu’on veut faire ? je ne pense pas.
Ma vision là dessus, c’est que le mieux pour l’utilisateur, c’est d’avoir un dashboard unique Gladys qui centralise toutes ses maisons, tous ses capteurs, c’est à dire une instance Gladys principale, et d’avoir ensuite un ensemble de noeud esclave ne faisant tourner que le code nécessaire.
Ma vision, c’est qu’au lieu d’installer sur chaque Raspberry Pi un Gladys complet, on n’exécute sur les « esclaves » que le code nécessaire, c’est à dire les modules.
Vous l’avez sûrement remarqué, tous les modules codés récemment ( Bluetooth, Xiaomi ) sont a exécuter en dehors de Gladys en module séparé. L’objectif était pour ces modules d’être capable de faire tourner plusieurs instances de ces modules même sur des petits Raspberry Pi. Pour le module bluetooth l’objectif est de pouvoir scanner tout le logement à l’aide de multiple Raspberry Pi zero pour couvrir toute la zone.
A l’avenir, j’aimerais que 100% des modules de compatibilités soient capable de tourner en remote.
Oui, mais du coup comment communiquer avec l’instance principale dans les deux sens ?
Effectivement, la question est intéressante. Actuellement les deux modules Bluetooth et Xiaomi ne communiquent que dans le sens module => Gladys, ils fonctionnent donc via des requêtes HTTP partant du Raspberry Pi esclave vers l’instance principal. Mais comment communiquer dans l’autre sens ? Pour un module philips hue par exemple, comment dire depuis Gladys vers le module « allume cette lumière » ?
Pour cette nouvelle génération de modules, je pense que le mieux est d’avoir un message broker MQTT, comme mosquitto, afin de pouvoir envoyer des events dans les deux sens.
Reprenons l’exemple précédent. A mon sens, le multi-instance dans Gladys ça pourrait ressembler à ça :
- Dans le Raspberry Pi principal : Gladys + Mosquitto + module Z-wave + module RF + module Philips Hue par exemple
- Dans le Rpi Zero : le module Bluetooth + le module RF
- Dans le Raspberry Pi B+ : le module Z-wave uniquement
Mais du coup, ça veut dire qu’on ne pourra plus faire tourner ces nouveaux modules directement dans Gladys ? Plus d’installation automatique ? Est-ce que ça ne va pas prendre trop de RAM si on n’a qu’un Raspberry Pi ?
Bonne question ! La réponse est non. Je ne veux pas que la nouvelle façon de faire remplace l’ancienne, je pense qu’il est possible que les modules aient deux modes : un mode d’exécution « dans le Gladys mère » comme actuellement + un mode d’exécution « remote » via MQTT. A mon avis on pourrait devoir coder un bout de code adaptateur capable de faire le bridge entre un module classique et MQTT. Et du coup on pourrait rendre d’un coup compatible tous les modules actuels sans changer leur code, et continuer de coder de la même façon !
En gros ce que ferais ce bout de code, c’est juste écouter dans MQTT les events de type « deviceType.exec » par exemple, et appeler la fonction exec quand un event est reçu. Je simplifie le problème mais en gros ça serait ça.
Les plus de cette façon de faire
Un gros plus, c’est la stabilité. Si un module crash, le core de Gladys ne crash plus, si un module doit redémarrer, il peut redémarrer et laisser Gladys tranquille. D’ailleurs, plus besoin de redémarrer Gladys pour installer un module 
Deuxième gros plus, en cas de redémarrage de Gladys, le module peut continuer à collecter les données de capteurs, et les publier dans MQTT. Le broker stockera les events dans sa queue et redistribuera à Gladys les events quand Gladys sera à nouveau en ligne.
Troisième énorme plus: Vous voulez installer Gladys sur votre serveur web à vous, comme ça l’interface est disponible tout le temps, performante, c’est désormais possible! Vous n’avez qu’à installer sur un petit serveur Gladys + Mosquitto ( avec Docker par exemple ), puis de n’installez chez vous que les modules de contrôle des lampes, capteurs, etc…
Ainsi
=> Vos données sont stockés sur un serveur plus « safe » qu’un simple Rasp, avec potentiellement une DB redondante MySQL, des backups de la VM, etc…
=> Votre Raspberry Pi n’est plus qu’un relais local vers des devices chez vous.
( Bon, ce n’est qu’une façon de faire, ça peut être un plus pour certains )
Les moins de cette façon de faire
Il n’est plus possible dans un script d’appeler une fonction d’un module vu que le module n’est pas exécute par la même instance de Node ni forcément sur la même machine. Tout devra passer par MQTT. Mais ce n’est pas un problème à mon sens, il faudra juste coder dans Gladys les bonnes passerelles pour que ça reste facile de scripter certaines actions. Et à mon avis tout sera transparent pour le user vu qu’en appelant des fonctions natives Gladys ( gladys.deviceType.exec par exemple ), c’est Gladys qui fera la mécanique de communiquer avec la bonne instance.
Conclusion
Je voulais le faire depuis longtemps, je suis content de vous avoir présenté ma vision du multi-instance. J’espère que cette vision vous plait Je suis tout à fait preneur de remarques, conseils, feedback, rien n’est encore fait ce n’est que la conception !
Merci de m’avoir lu jusque là !
, comme l’a soulevé 
