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


#1

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 :slight_smile:

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 :wink:

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 :slight_smile: 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à !


Plusieurs instances de Gladys - Multi RPI
#2

De 1 c’est TOP, MQTT est depuis longtemps proposé sur le forum et personne n’a eu à redire sur ça potentielle utilisation.
Le split des modules est clairement adapté à l’avenir de Gladys et ils font déjà bien leurs preuves !
Pour le point “moins” oui, il faut que cela soit transparent pour les users. Tout passera par des devices et c’est justement une bonne chose. Tous les modules devront être dès le début multi room et autonome, donc compatible directement avec toutes les installations. À voir quelles adaptation de l’actuel pourront être faites pour faciliter ces nouvelles mécaniques.
exemple le module speak deviendrait alors multi room. C’est la classe non ?
Pour la notion d’un seul Gladys pour X maisons j’ai un peu peur de l’effet OVH #jeNePeuxPlusRentrerChezMoi et c’est en cela que la redondance d’un Gladys par maison me semblait intéressante. Il faudrait alors prévoir un mode offline ? ou dans le cadre d’un multi house abandonner cette sécurité ?


#3

Alors la je dit OUI ! ^^
Passer les modules en mode remote c’est une excellente idée !
J’imagine déjà toutes les possibilités ! :ok_hand:

Ça par contre je doute que ça soit aussi simple :thinking:, comme l’a soulevé @AdrienDesola l’effet OVH poserait d’énorme soucis en cas de panne électrique dans la maison principal alors que tu te trouve dans la maison de vacances… Donc @AdrienDesola a raison.

Il faut prévoir un mode offline mais déjà ça veux dire qu’il faut revoir TOUT les modules déjà existant mais surtout que ce n’est pas un seul bout de code qu’il faut faire vu qu’il faudra s’adapter à chaque module !
Et puis ça veux aussi dire que pendant la période offline on dit au revoir aux scénario… mais bon on va pas pousser mamie dans les orties non plus :joy:

Ensuite tu parle de transparence pour l’utilisateur mais pour installer les modules sur les PI esclaves il faudra obligatoirement passer par les lignes de commandes… ce qui n’est pas très transparent pour l’utilisateur lambda (surtout qu’il y en a de plus en plus).
A moins que tu ai un atout dans ta manche ça risque d’être compliqué de rester “transparent” sans réelle interface d’installation ^^


#4

Je travaille souvent sur des problématiques d’internationalisation, du type, “j’ai mon service en France comment je fais pour déployer à l’internationale” … à une autre échelle la problématique est similaire :slight_smile:

L’approche choisie me semble intelligente et pertinente. Et surtout merci, grâce à ce billet je comprends finalement ce qu’est Mosquitto et MQTT qui jusque là restait une abbréviation LOL.

Par contre je ne suis pas clair sur un point : est-il prévu que tous les modules échangent systématiquement au travers du broker ou bien sera-t-il possible de conserver un mode (de scripting) “local” ?

Le broker c’est la bonne approche pour du remote, après attention aux architectures micro-services et surtout à la sécurité. C’est un problème majeur en IOT, souvent passé à l’as au profit du fonctionnel. Typiquement je ne voudrais pas que mes échanges puissent être interceptés et qu’un cambioleur sache que je en suis pas dans ma résidence secondaire car le chauffage est en mode hors gel.

Par ailleurs, tout faire passer par le broker c’est un “single point of failure” (ou un goulot d’étrangement) même si j’imagine que des mécaniques sont prévues côté broker pour gérer la redondance (ok c’est un demi problème, le Rpi est aussi un single point of failure). Question corolaire bête mais pratique, ça peut amener à faire passer beaucoup de traffic chez le broker, ne faudra-t-il pas passer par une souscription chez le broker pour garantir la fiabilité et la SLA bout en bout ?

L’approche pure locale, peut présenter des avantages dans certains cas d’usage. Déjà tout le monde n’a pas une résidence secondaire, une cabane au fond du jardin (ni même de jardin) ou encore une maison de 500m2. Bref, disposer d’un mode local peut rester une approche simple et surtout cela facilite la sécurisation du système.

Pouvoir disposer d’un élément de configuration pour déterminer si un script est “à l’ancienne” i.e. local ou doit passer par le broker serait idéal. Encore mieux, il faudrait une couche d’abstraction de l’API qui permette le routage automatique des flux sans impact sur les scripts déjà existants. Ainsi tu peux recâbler la plomberie de façon transparente et surtout cela laisse le champs libre pour des évolutions ultérieures.

Bien sûr, ce ne sont que des réflexions “high level”, je n’ai pas une connaissance suffisante de l’architecture de Gladys pour être plus précis.

En tout cas c’est juste génial, ça c’est une vraie roadmap. Pour avoir perdu pied ces 2 derniers mois à cause du taf, je suis scié par la vitesse à laquelle Gladys évolue notamment grâce à la communauté. Bravo à tous !


#5

En effet il va falloir faire attention au mode offline. pour les scripts, il pourrai faire une BDD local avec tous les scriptes qui concernent uniquement des devices contenue dans cette maison.
et il faudrait que gladys essais d’envoyer un message(telegram ou HP) pour avertir du passage en dégradé.
Pour les modules “orphelins”, ne serait-il pas intéressant de faire un node d’interface qui ferait passerelle entre les modules et le master gladys? ainsi, d’un coté les modules sont plus simple à développer(et peuvent rester compatible) et de l’autre, on peux créer un module coté gladys qui vient détecter les nodes dans la maison et qui permette la gestion de ceux-ci(MaJ ou install de modules…). Les nodes pourrai donc être gérés depuis la même interface).
globalement je vois deux cas de figures:

  • une carte Pi dédiée à des modules gladys(comme la nano pour bluetooth par ex)
  • une carte Pi qui sert aussi à autre chose(perso une pi avec OSMC qui me sert aussi pour Spotify)

dans le premier cas, on peux proposer une image avec le node déja installé/configuré, ce qui rend l’usage facile pour un “noob”.
dans le second cas, l’utilisateur doit installer le node manuellement mais il y a fort à parier qu’il maîtrise déjà suffisamment pour le faire.


#6

Salut @tous

La comm via MQTT me semble une excellente approche, je ne suis pas assez avancé dans la connaissance de l’archi Gladys pour en discuter ou non le bien fondé.
Concernant les SLAs, le SPOF et la haute dispo : L’utilisation de la fonction bridge (avec plusieurs remote hosts) permettrait de faire tourner un broker sur le Galdys Primaire abonné aux secondaires ET bridgé vers cloudmqtt.com, mais également chaque secondaire posterait sur Gladys primaire et en cas d’inaccessibilité du primaire sur cloudmqtt.com. Cela permettrait de ne pas dépasser les 10 connexions max du broker cloudmqtt.com
Le schéma ce serait un peu ça :
image

Question : dans la config du broker est-il possible de dire qu’on ne poste qu’au primaire (Gladys) ET SI il est KO alors on poste au secondaire (cloudmqtt) ? Il y a des experts MQTT autour de la table ?
Ce post est pas mal : http://www.steves-internet-guide.com/mosquitto-bridge-configuration/
Je m’en suis inspiré pour monter mon broker. Avec la notion de “remapping” je pense qu’il est possible de ne pas se parasiter et savoir d’où viennent les messages.

Juste une piste à ce sujet :

-> Avec ansible ou docker on peut automatiser des déploiements multi instance… il me semble.


#7

Alors bonne remarque ! Je ne pense pas que créer cette redondance au niveau applicatif soit la meilleure des choses.
On a dans Gladys 3 points qui peuvent être redondés :

  • La base de donnée MySQL
  • Le broker MQTT
  • Le back-end ( Gladys en gros )

Toutes ces technos ont déjà des outils de redondance existant qui sont bullet-proof et résistent à des downtime random de tous les côtés : des équipes d’ingé ont déjà travaillé full time dessus depuis des années.

Du coup afin d’éviter les problème de downtime, la base de donnée MySQL peut être setup en 2 instances (une sur le rasp, une sur un autre rasp/ un serveur distant).
De la même façon, le broker MQTT peut être redondé voir être 100% online avec CloudMQTT/une installation à la main/un broker MQTT redondant sur AWS par exemple.
Pour le back-end, pareil, en prenant juste en compte qu’actuellement le back-end s’occupe aussi des tâches récurrentes (alarmes, scénario, etc… ) et du coup afin d’éviter les doublons d’exécutions il faudra effectivement avoir un flag disant “je suis vivant, je suis le master”.

Pas forcément, on peut faire en sorte que le master se connecte aux esclaves et les manage ( genre installe les modules à distance ), c’est largement possible.

Sur l’esclave on peut avoir juste un petit programme ( le “manager” ), qui s’occupe de gérer l’installation des modules en fonction de ce que lui dit le maitre :slight_smile:

Tout dépend de ce que tu veux faire, si ton module est distant alors oui tu le contacte via MQTT, sinon tu continue à pouvoir scripter en local. Attention, comme je disais dans un script ça sera 100% transparent. Tu continueras de dire “gladys.deviceType.exec(…)” et c’est Gladys qui fera le calcul “ok ou est situé le device ? est ce que je dois lui envoyer le message localement ou par MQTT ? etc…”
Donc pour moi ça sera les mêmes scripts qu’avant, aucunes modifications

Complètement, le broker MQTT c’est connexion SSL de base + authentification. C’est pas open bar.

Ma réponse plus haut dans ce post doit répondre à ta question :slight_smile: Oui tu peux géo-redonder ton broker, voir utiliser des solutions hostées toute prête, ou installer un broker redondant sur des VM à toi en ligne…

Comme je dis dans mon post, tout reste comme actuellement, je n’apporte qu’une nouvelle façon de faire pour certains cas. Rien ne change.
Et comme je dis tu peux toujours faire du MQTT + Gladys + modules sur un seul Raspberry Pi, comme actuellement, ça t’apporte la stabilité de ne pas avoir tout qui tourne sur le même process node.js, et donc ça enlève 100% des erreurs de type “j’ai installé un module pété et Gladys est en 502” ( avec ce système, un module crash => juste le module crash, plus Gladys complète )

Tout à fait, c’est ce que je disais un peu dans le post principal quand je parlais du “bout de code adapteur”, et que j’ai complété dans cette réponse avec un “manager” de module installé. Ce manager va gérer tout ce qui est healthcheck, installation de modules, mise à jour, etc…

Possible, il faut que je me renseigne ! Mais à mon avis oui :slight_smile:

Sinon si tu es stressé tu peux te baser 100% sur un broker online géo-redondé genre sur AWS ( bon du coup c’est plus une solution 100% local, mais bon c’est le prix à payer si tu veux que ton broker soit up même si il y a un incendie à la maison )

Merci pour tous vos retours en tout cas !


#8

Effectivement en y réfléchissant ce matin je suis arriver à la même conclusion !
Après je me demande si on pourrais y intégrer une petite interface histoire d’avoir un support en cas de Offline (vraiment en cas de dernier recours) :thinking:


#9

ben déjà ça dépend si le node est juste un node local(à l’étage d’une maison par exemple) ou si c’est vraiment externe(dans le cas d’une seconde maison). le local n’a pas spécialement besoin d’interface je pense car si le master est offline, ya fort à parier que lui aussi alors qu’en mode externe effectivement ils peuvent être indépendants


#10

D’accord mais on va pas développer un module en double à chaque fois (un avec l’interface et un autre sans) Et demander à l’utilisateur de choisir celui qu’il veux… si on doit inclure une petite interface autant le faire dès le début !


#11

oui oui je suis bien d’accord


#12

C’est cool, on retombe sur ce dont je parlais à keymetrics à propos d’une interface offline avec un côté “moins paramétrage de gladys” mais interface homme machine pour la visualisation.
Cependant je pense qu’il serait plus intéressant de voir ça dans un autre topic ?


#13

Ah non je parlais pas de ça ^^
Je parlais surtout d’intégrer une mini interface de contrôle pour les module externe en cas de problème avec l’instance maître.

il faut que tu me rafraîchisse la mémoire :sweat_smile:


#14

il faudrait en effet une interface pour paramétrer les devices connectés au node et la conf mais avec le stricte minimum(parametres, devices, devicestypes…)


#15

Même les paramètres ne devraient pas être nécessaire car tout est censé passer par l’instance principal et l’interface intégrée serait la uniquement pour contrôler les device correspondant au nœud en cas de down de l’instance principal !


#16

je pensais surtout aux paramètres pour le réglages MQTT et autres dans le même genre


#17

Mmm à voir :slight_smile: Je pense qu’il faut plus réfléchir en terme de redondance d’instance master Gladys

Bon en tout cas merci à tous pour vos retours!


#18

Il faudrait pouvoir les monitorer dans Gladys.
Chez HA, c’est pratique, tu les actives, tu les stoppes ou tu les redémarres.
Je pense que ça serait bien que Gladys garde la main dessus (mais comme tu dis avec un fonctionnement à part) parce que quand tu en as beaucoup, c’est chiant de devoir les regarder avec pm2 en ligne de commande pour savoir si tout va bien.


#19

C’est l’objectif! pm2 n’est qu’une solution temporaire


#20

T’as du taff mon garçon ! :wink: