Une bêta pour Gladys 3.0!

Salut à tous !

La v3 avance de plus en plus, et je suis heureux de vous annoncer aujourd’hui la sortie de la bêta de la version 3 !

Objectif

L’objectif de cette bêta est que vous puissiez commencer à bidouiller avec l’API Gladys pour commencer à créer des modules compatible v3, j’ai donc commencé à documenter cette v3 pas mal.

Installation

Pour l’installation pour développer, ça se passe ici => https://developer.gladysproject.com/fr/documentation/install-gladys

Attention, il s’agit bien d’une installation développeur, que vous pouvez réaliser sur votre machine ( Mac, PC, Linux ). Pour Raspberry Pi il y aura une image toute prête naturellement quand je sortirais la release finale !

Développement

Pour développer, j’ai écris un premier tutoriel. C’est une introduction, je l’étofferais au fur et à mesure, je suis conscient qu’il n’est pas complet !

Le tutoriel est disponible ici => https://developer.gladysproject.com/fr/documentation/how-to-develop-gladys-module

Conclusion

N’hésitez pas si vous avez des questions/remarques. J’ajoute qu’il s’agit d’une version de Gladys encore en bêta, tout n’est pas fini, et ça casse parfois à certains endroits, c’est normal :slight_smile:

Super ! Ca avance !

Salut,
J’ai tenté d’installer la version 3 sur l’image de la v2 (pour RP). Je pensais pouvoir choisir le nom de la base de donnée mais apparemment ça reste gladys par défaut.

Du coup, j’ai déjà l’utilisateur de renseigner (la table des utilisateur à du conserver son nom). Pense-tu que ça puisse fonctionner correctement ?

Sisi, tu peux donner le nom de la DB que tu veux ! Il vaut clairement commencer avec une DB vide, ça va poser problème sinon tu passeras pas par la phase d’initialisation de Gladys…

( Cf https://developer.gladysproject.com/fr/documentation/install-gladys ) Tu peux définir la variable d’environnement MYSQL_DATABASE qui va définir la DB utilisée par Gladys )

My bad, je croyais avoir modifier le fichier de config, mais j’ai du modifier celui de la v2… Merci, ej suis bien passé par la phase d’installation.

Je vais pouvoir tester tous ça et bidouiller (je vois que pour les devices, il faut passé par la base pour le moment).

Bonjour,
J’aimerai savoir si il était possible d’avoir une architecture de base d’un module pour la V3?
Et’il prévu de créer un générateur de module de base avec “Yeoman”?

Question subsidiaire: Et il prévu que Gladys puisse reboot lors de modifications dans les fichiers de “api/hook”? Ça serait super pratique lors de développement de module.

@Neope: Salut !

Oui, tu trouveras tout ton bonheur ici => developer.gladysproject.com/fr/ … dys-module :slight_smile:

Tu as toute l’architecture d’un module simple dedans ( rubrique “En pratique” )

Il y a aussi plusieurs exemples sur github de modules compatible v3 que j’ai fais :

Je te conseille de regarder gladys-mqtt ou pushbullet que j’ai créé il y a vraiment pas longtemps et qui sont “exemplaire” en terme de dev Gladys 3.0.

J’ai pensé à faire générateur yeoman, j’en ferais peut être un si je trouve le temps, ce n’est pas ma priorité principale, vu la simplicité d’un module ( en gros un simple fichier index.js pour un module simple, un dossier lib pour les plus complexe, c’est pas non plus la mort à créer :slight_smile: )

[quote]Et il prévu que Gladys puisse reboot lors de modifications dans les fichiers de “api/hook”? Ça serait super pratique lors de développement de module.
[/quote]

Effectivement on pourrait faire une petite tâche grunt ! Je crois même qu’il y en avait déjà une mais que j’avais désactivé car la tâche buggait et faisait monter le CPU anormalement chez moi… je re-regarderait

Pour vous tenir au courant, on peut désormais installer automatiquement les modules qui sont sur le store Gladys depuis Gladys en un clic ! => https://twitter.com/gladysproject/status/738423944538161156

Vous pouvez tester, c’est sur la branche v3 :slight_smile:

Merci pour tes réponses. Par contre je n’ai pas vue le moyen de créer une interface pour le module.
Et t’il prévue/possible d’accéder à une page spécifique au module style “localhost:1337/monModule”
pour afficher une version étendu de la vue du module.
Par exemple: Page de paramétrage de sa box internet, liste des températures de la maison, …

Alors, il est possible de créer des boxs pour modules, pour l’instant de visible et fonctionnelle il n’y a que la vue du dashboard principale ( l’accueil ), après dans le modèle de ces boxs il y a un champs “view” ( github.com/GladysProject/Gladys … ype.js#L46 ) qui va permettre d’afficher ces boxs à différents endroits, l’objectif étant d’avoir pour chaque module une page de paramétrage accessible depuis la page “module”.

Après, ma philosophie pour cette v3 au vue de ce que j’ai pu voir sur ces 3 ans à bosser sur Gladys, est de minimiser les vues des modules pour essayer de mutualiser au max ce qui peut être mutualisé entre les modules. Tu parle de lister les températures de la maison, ce n’est pas au module de le gérer, le module doit juste être le pont entre le périphériques qu’il contrôle et Gladys, il doit juste enregistrer dans les tables génériques des devices leurs valeurs, qui peuvent être visualisée au même endroit ensuite ( surtout qu’on a une super interface de visualisation des données des capteurs de la maison ! :wink: => twitter.com/gladysproject/statu … 5346856960 )

Le gros problème dans la v2, c’était que chaque module créait son interface pour au final faire la même chose que chaque module, et l’expérience était très hétérogène. Pour chaque périphérique de marque différentes, on devait le gérer dans un endroit différent de l’interface, ce qui n’est pas logique, le but de Gladys est justement de rassembler tous ces périphériques différents au même endroit.

Les modules de compatibilités ( qui ajoutent la gestion d’un type de périphériques ), ne doivent à mon sens pas gérer d’interface ni aucuns contrôleurs, ils doivent juste donner à Gladys la possibilité de contrôler ces périphériques.

N’hésite pas si tu as une idée de modules, que tu ne vois pas comment intégrer ça à Gladys à en parler, je te dirais comment je vois ça dans Gladys :slight_smile:

Je sais pas si tu connais le projet “constelation” de Sébastien Warin. Mais j’aime bien ce qu’il a fait. Et surtout la partir S-panel qui est un dashbord qui lui permet d’avoir une vue globale des différents point de contrôle de sa maison, tout en lui permettant de faire des modifications. Donc ma question serai: mieux vaut avoir un ensemble de module avec leur vue propre dans le dashbord de Gladys? Ou une application extérieur qui récupère les informations regroupé dans Gladys ?

Je ne connaissais pas ! ça a l’air vraiment pas mal oui, je vais regarder son blog il y a des articles intéressants :slight_smile:

ce serait pour faire quoi, je ne comprends pas exactement ? Faire un peu comme il s’est fait ?
Chaque module peut créer des widgets sur le dashboard que l’utilisateur peut disposer comme bon lui semble :slight_smile: C’est le but !

Après ce que je disais dans mon dernier message, c’est juste que pour les modules de compatibilités il vaut mieux ne pas faire de front, c’est Gladys qui gère l’affichage pour cette partie afin que ce soit unifié ( et dans ce cas si tu trouve que l’affichage des devices dans Gladys 3.0 n’est pas top, on peut améliorer cet affichage et bosser dessus :smiley: )

Mais sinon pour des modules plus “exotique” , on peut très bien faire une box sur le dashboard pour afficher des infos.

Désolé d’accaparer ton temps, mais j’ai une vision assez précise de ma box “Idéale”.
Dans l’idée ça serai un serveur “master”, qui regroupe différents module et des serveur “slave” indépendant qui push des données au “master” (ex: module garage, module jardin, module compteur, module interphone, module média center, module voiture, …) pouvant être appelé par des scénarios du master. Et des serveur “dashbord” qui “push/subscribe” les données. Le tout avec du socket.io pour synchroniser les données en “instantané”.

Pas de soucis, au contraire c’est toujours intéressant d’échanger !

En fait l’architecture que tu décris est déjà l’architecture de base de Gladys j’ai l’impression ^^ Ca dépend juste ce que tu entend par “module” techniquement parlant. Parce que tout ça tu peux très bien le faire en pratique dans Gladys, tes esclaves qui remontent des données peuvent appeler le master ( vu que Gladys a une API REST ) qui lui updatera les données et publiera via des websockets les données en live sur le dashboard ( ça c’est déjà le cas, le live est quelque chose qui a toujours été dans Gladys ). Exemple : Tu as créé une petite sonde de température avec un arduino esp8266 qui renvoie la météo toutes les 10 minutes, et bien ce petit module va appeler l’API REST de Gladys avec une petite requête HTTP toutes les 10 minutes, et Gladys va recevoir la requête, enregistrer la donnée, et mettre à jour en live le dashboard.

Et les esclaves de type “actionneur” peuvent être appelé via leur API par Gladys. Exemple: Tu as fais un petit module avec un Raspberry Pi/un Arduino qui contrôle je ne sais quoi, tu vas pouvoir depuis Gladys dans les scénarios contrôler ces modules avec une simple requête HTTP si ils sont connectés au réseau, ou via d’autres technos (433Mhz par exemple)

Merci beaucoup pour toutes tes réponses.

Salut Pierre gilles,

Cela fais un moment que je n’ai plus posté sur le forum et je m’en excuse.
En effet, j’ai été un peu refroidi par gladys, non pas du côté soft … pour lequel je trouve les évolutions spectaculaires mais
par le hard.
J’avais installé gladys sur mon raspberry 2 et à chaque coupure de courant/extinction, je perdait tout avec une SD corrompue.
Je suie néanmoins le forum et je recherche, en parallèle une base hard plus fiable avec une installation possible sur NAND (cubieboard ou autre)
Malheureusement, Docker n’est pas dispo pour mon NAS (prossesseur MARVELL ARMADA)

Comme j’avais besoin rapidement de me lancer en domotique, j’ai achetée une box vera edge qui me satisfait en partie. Cela me permet de grossir ma liste de matériel (surtout zwave) mais je garde de côté mon stick UZB1 :sunglasses:

Personnellement, comme tu maîtrises complètement ton sujet et que la création de module est d’une simplicité enfantine pour toi, je te suggère de créer rapidement des modules emblématiques qui te permettrait, rapidement, d’ajouter des fonctions vitales sur gladys et d’enrichir grandement ta carte de visite.

Je pense nottement à un module NEST thermostat et NETATMO pour la fonction thermostat
un module SONOS pour la fonction de gestion d’ambiance et le retour vocale
Philips HUE déjà fait

Voila, loin de moi l’idée de t’imposer quoi que ce soit bien sûr.

Et félicitation pour l’avancée de Gladys

Salut @TOF !

Pas de soucis, c’est quand même étrange que tu ai eu autant de problème de corruption de carte SD !

Effectivement, c’est l’objectif de créer ces modules “emblématiques” comme tu dis, c’était l’objectif de cette v3, simplifier au maximum le développement de modules, plus particulièrement les modules de compatibilités. Aujourd’hui je suis assez fier du rendu, et je gagne un temps fou ( un module type wemo/Philips Hue me met à tout casser 20/30 min à développer ). Je n’aurais jamais pu faire cela auparavant, le passage par cette v3 était obligé.

Après je fais aussi en fonction du matériel que j’utilise moi, je ne peux pas tout acheter non plus étant étudiant :wink:

Merci pour ton message en tout cas ! J’espère que tu auras l’occasion de revenir sur Gladys quand tu auras trouvé un hardware plus fiable.

C’est mon but, je regarde aussi du côté des box android TV qui , pour 30€, se montrent plutôt véloce et en cas de mauvais fonctionnement avec gladys, pourras toujours servir sous une TV.

Pour le thermostat Nest, j’ai le projet d’en acheter un vers septembre .
Si, d’ici là, j’ai réussi à me faire une conf Gladys robuste, je pourrais éventuellement beta tester.
Pour le zwave, je commence également à avoir quelques équipements (voir ma signature).

Voila, je me répète mais encore félicitaton

Je viens de commencer à essayer de re-développer mon module FHEM sur la V3 en suivant les précos.

Plein de questions me viennent, je vais commencer par celle qui me bloquent :slight_smile:

En fait, j’ai besoin de spécifier un serveur FHEM qui sera joint par telnet, j’ai donc prévu d’utiliser la table “param”.
Sauf que dans mon hook, je n’accède pas au modèle Param, quel est la subtilité ?

Deuxièmement, pour le module Hue, je vois qu’il y a une recherche automatique des ampoules Hue… c’est pratique.
Mais dans mon cas, je souhaite intégrer les périphériques reconnus par FHEM de manière manuelle, ou plutôt je ne sais pas de quelle manière ? En V2, j’avais ma box ou je pouvais sélectionner mes équipements et les associés aux profiles. La je ne sais pas comment m’y prendre.

Merci par avance pour l’aide :slight_smile:

Salut ! Ah bien :slight_smile:

Pour accéder au param, inspire toi du module Hue : github.com/GladysProject/gladys … red.js#L10

Pour accéder à une valeur tu fais :

gladys.param.getValue('NOM_DU_PARAM') .then(function(value){ // value contient la valeur }) .catch(function(e){ // le param n'existe pas });

Remarque : Ne jamais accéder aux modèles du core de Gladys directement, il faut toujours passer par les fonctions prévus pour, sinon tu risque de passer à côté du fonctionnement normal.

Attention, il faut que Gladys soit prête, tu as toujours l’event “ready” qui est émit, cf module gladys-mqtt ( github.com/GladysProject/gladys … ndex.js#L6 )

Il n’y a pas moyen d’ajouter automatiquement les devices avec FHEM? il n’y a pas une API dans FHEM qui te permettrait de récupérer la liste des devices pour les ajouter dans Gladys ? ça serait le mieux, et le plus propre pour l’utilisateur.

Si vraiment, ce n’est absolument pas possible ( je dis bien absolument pas possible !), c’est prévu que je fasse un système d’ajout manuel de device, ça sera ajouté à Gladys nativement :slight_smile: Tu n’auras pas à développer cette partie. Mais j’insiste, le mieux serait de faire comme pour le module hue :

  1. Quand l’utilisateur appuie sur le bouton “config” du module, la fonction config du module est appelée.
  2. le module se connecterait alors à l’API de FHEM, et ajouterait tous les devices à Gladys. ( si tu n’as pas envie de voir certains devices dans gladys, tu peux décocher certains devices pour qu’ils n’apparaissent pas partout, c’est déjà dans Gladys :slight_smile: )

N’hésite pas si tu as d’autres questions, c’est vrai que ça change clairement de la v2, l’objectif est de normaliser la partie “développement de modules de compatibilités”, pour que l’expérience utilisateur soit regroupée en un seul endroit et que chaque dev n’ai pas à réinventer la roue à chaque fois… :slight_smile: