Pouvoir déporter un ou plusieurs services sur un autre RPI

Il serait intéressant de pouvoir déporter un ou plusieurs services sur un autre RPI.

Exemple :
Mon Gladys 4 est installé sur un NAS Synology.
Je souhaite utiliser la détection de présence via Bluetooth et donc je veux déporter le service Bluetooth sur un RPI Zero dédié.

Salut, je vois que tu te proposes pour participer au développement, mais tu as une idée de comment procéder ? Je suis assez intéressé par le concept en général, bien que je ne pense pas en avoir le besoin.

@AlexTrovato Je pense qu’il s’agit du concept de « Gladys Pod » dont on a longuement parlé :slight_smile:

L’objectif ce serait de pouvoir avoir des « pods » qui communiquent avec un Gladys principal (en MQTT probablement)

Il faudrait voir comment ça pourrait rendre en terme d’UX. Est-ce que l’utilisateur installe un Gladys complet sur une autre machine puis active un mod « pod » sur l’instance ?

Est-ce que l’utilisateur installe juste une image « pod » qui contient juste le code de certains services compatibles « pods » et qui renvoie toute la data en MQTT au master ? (et comment configurer ce service, sans CLI?)

Je pense qu’il y a plein de chose à débattre mais en tout cas c’est un sujet intéressant et qu’on allait aborder de toute façon à un moment ou un autre :wink:

Ça pourrait aussi m’intéresser ! Comme je peux pas récupérer depuis enedis mes informations de consommation, je vais être obligé de passer par du TIC. Et une des solutions est de brancher ça à une RPi Zero. Et j’avais dans l’idée d’envoyer ces informations à Gladys via MQTT.

L’idée serait de faire une instance Gladys Lite avec juste certaines intégrations?

Plus ou moins, c’est encore à définir !

L’idée c’est d’avoir un Gladys “main” principal, et des petits pods qui renvoie des informations.

Pour l’instant j’avais juste théorisé l’idée au début de la v4, mais rien n’est encore défini, tout reste à faire :slight_smile:

@pierre-gilles Si j’ai bien compris ton concept de Pod, c’est lancer un Gladys, en désactivant tout ce qui n’est pas les services et d’avoir un event handler qui transmet tous les events dans un(des) topic(s) MQTT vers le Gladys « Principal » ?

@cbe317 Dans l’idée, c’est ça :slight_smile:

J’avais même fais un schéma dans le manifeste technique:

Maintenant il faudrait définir ce qu’on voudrait en terme de fonctionnement:

  • Comment l’utilisateur installe un pod ?
  • Est-ce que l’installation d’un pod est la même que l’installation de Gladys v4, juste qu’au début de la configuration, l’utilisateur sélectionne « cette instance est un pod » ? (ça pourrait être le plus simple)
  • Comment on gère la configuration à distance du pod: dans l’interface du pod, ou dans l’interface du master qui relaie vers le pod ?
  • Comment l’utilisateur s’authentifie sur un pod ? Est-ce que l’utilisateur s’y connecte (ou pas?)

Je pense que ça serait l’idée la plus simple et la plus pratique pour l’utilisateur. Avec si possible le choix dans le ou les services à déployer. (Une version vierge de Gladys pèse combien ?)

Ca pèse rien :slight_smile: Gladys complet doit peser 120 mo je crois environ.

Comme tu le disais, une option à l’installation pour dire que l’instance est un pod semble être une bonne option. Pas besoin de partir sur une instance « Lite » vu son poids.

En soit la plateforme de l’utilisateur c’est le gladys principal et surtout le dashboard. Si l’on veut garder la philosophie de simplicité et que l’utilisateur n’ait pas à mettre les mains de le cambouis, je verrais bien une connexion par défaut.

On pourrait imaginer pendant l’installation, après avoir choisi que l’on installe un pod, une page de renseignement où l’on remplirait l’IP du principal ou un serveur MQTT sur lequel on va se plugger.

1 Like