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.
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 !
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
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…
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 )
[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
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 ! => 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
Je ne connaissais pas ! ça a l’air vraiment pas mal oui, je vais regarder son blog il y a des articles intéressants
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 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 )
Mais sinon pour des modules plus « exotique » , on peut très bien faire une box sur le dashboard pour afficher des infos.
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)
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
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.
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
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.
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.
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 Tu n’auras pas à développer cette partie. Mais j’insiste, le mieux serait de faire comme pour le module hue :
Quand l’utilisateur appuie sur le bouton « config » du module, la fonction config du module est appelée.
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 )
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…
Ok pour l’accès à la table param, c’est très pratique !
Je vais donc regarder ca.
Pour la reconnaissance automatique des devices, va falloir que je creuse, je sais que je recois la liste des équipements mais je ne suis pas sur de recevoir son profil, est-ce nécessaire ou bien l’objectif c’est de récupérer l’id de l’équipement puis le module de gestion des équipements fait le reste justement ? auquel ca je devrais pouvoir m’en sortir.
En fait c’est à ton module de créer chaque device dans Gladys, sachant que tu dois créer pour chaque device:
Le device ( le périphériques physique )
les devicetype associés ( pour chaque device physique peut être associé plusieurs “fonctionnalités”, exemple : capteur multi capteurs ( température/humidité) , il faut donc créer un deviceType par feature pour pouvoir ensuite enregistrer des données pour chaque type.
Ah oui effectivement les data sont pas hyper propre… Tu es sur qu’il n’y a pas une API qui te liste tous les périphériques ? Il n’y a pas une doc propre qui te permettre de faire un truc factorisable ?
Sinon, dans les data que tu me donne la, il y a un ID unique du capteur ? que tu puisse identifier ton capteur dans le champs “identifier” ?
[quote]Par ailleurs, quels sont les différents types possible/connues de gladys ?
Si je regarde pour Hue, tu as mis Brightness, pour mon détecteur de luminosité, Brightness correspond-il ?[/quote]
Les types possibles sont infinies, il n’y a pas de liste. Globalement, pour l’instant je fais la différence entre deux types :
binary ( qui deviendra un bouton on/off dans l’interface pour les actionneurs )
le reste ( qui deviendra un slider entre la valeur min et max dans l’interface pour les actionneurs )
Après à l’avenir je compte rajouter de plus en plus de picker différents, par exemple un type “color” pourra être affiché avec un colorPicker, des choses de ce type.
Ici pour toi je mettrais “luminosity” tout simplement. Et “sensor: true” vu que c’est un capteur
Ok je vois la logique, je vais expérimenter tout ca.
Pour des capteurs type Ouverture de porte, c’est du binaire mais sans action derrière, je vais voir comment je peux gérer ca.
Coté source de données, je vais creuser… en fait j’utilise fhem.js qui cause à fhem via telnet et gladys cause à fhem.js via web socket.
Donc soit je creuse coté fhem mais je crois pas qu’il y ait d’API.
Soit je modifie fhem.js pour qu’il soit plus “propre”
A suivre;.
PS: un Update sur les Paramètres ca serait pas mal
Edit:
Après analyse du module fhem.js, ca me parait compliqué d’obtenir des infos plus propre puisqu’il se base sur la seule commande listant les équipements dans FHEM :
Je pense que je vais opter pour le choix de définir dans le nom de l’équipements, ce qui définit son “profile”.
Ca signifie que si je veux que mon module soit reconnu dans Gladys, il devra avoir une nomenclature spécifique.
Genre
EnO_binary_contact_XXX
EnO_sensor_temperature_XXX
En respectant une norme, je devrais m’en sortir… C’est pas ce qu’il y a de plus propre mais j’ai pas mieux.
Pour faire mieux, faudrait que je réintègre fhem.js dans le module Gladys … !
C’est tout simplement un type = binary avec min = 0 max = 1, et sensor = true, c’est géré tout seul par Gladys
C’est à dire ? pour mettre à jour un paramètre ?
gladys.param.setValue() définie la valeur qu’elle existe ou non, pas besoin d’update !
Ok ! Je comprends pas tout à ce que te ressors fhem, tiens moi au courant de l’avancée histoire que je te dise si ça s’intègre bien comme prévu dans Gladys.
Pardon je me suis mal exprimé pour l’update des paramètres, je voulais effectivement dire de pouvoir updater un paramètre, via l’IHM.
Je continue d’avancer sur mon module et je te tiens au courant, sur la V2, j’ai déjà pas mal d’usage de mes équipements, comme faire une action sur une ouverture de porte (donc pas un actionneur mais juste un sensor binary).
Par ailleurs, je viens de constater que lorsque j’exporte ma fonction config dans l’index, la fonction est exécuté au démarrage sans attendre l’event ready de gladys, config ne devrait-il pas être appelé que lorsqu’on clic sur le bouton configuration du module ?
Ou alors je me trompe quelque part … je continue de creuser
C’est possible aussi ! Tu as juste à modifier la variable dans la text box, ça auto save normalement…
Tu as un lien vers ton fichier index.js sur github ? tu as bien exporté comme je le fais dans le module hue par exemple ?
Normalement config est appelé uniquement lorsque l’on clique sur le bouton configuration !
[quote=« admin »]
Tu as un lien vers ton fichier index.js sur github ? tu as bien exporté comme je le fais dans le module hue par exemple ?
Normalement config est appelé uniquement lorsque l’on clique sur le bouton configuration ![/quote]
Non effectivement, j’ai mis un lien bidon, je l’ai pas poussé sur github.
=> 
)