Gladys 4 Beta est disponible ! 🚀

[Reno]

Grilled @VonOx

[Tlse-vins]

J’en avait déjà parlé précédemment car la concurrence est vraiment au point sur ce sujet, et je trouve que ça manque à Gladys.
Voir Eedomus
Voir Jeedom

2 façons de faire. Je sais qu’avec Gladys on peux faire encore mieux

[damalgos]

@pierre-gilles

C’est pas aussi simple que ça, chaque UI de service est unique, donc où serait affiché cette liste?

Pour moi, on peut très bien sur Gladys rajouter un dossier comprenant plusieurs json correspondant aux services, et le front pourra avoir une page dédié permettant de lister tous les équipements disponibles. C’est donc au développeur de rajouter au fur et à mesure les device compatible.
Ce dossier sera statique tout simplement.

[pierre-gilles]

@Tlse-vins

J’en avait déjà parlé précédemment car la concurrence est vraiment au point sur ce sujet, et je trouve que ça manque à Gladys.
Voir Eedomus
Voir Jeedom

Du coup pour récapituler, il y a 3 demandes différentes dans ce thread:

1. Une liste des périphériques compatibles par service, directement dans un service dans Gladys
2. Une liste des périphériques compatibles Gladys, dans Gladys mais au niveau « global » Gladys.
3. Une liste des périphériques compatibles Gladys dans la documentation Gladys

Les trois ne sont pas opposés, on peut tout à fait en faire plusieurs, mais il faut que la source des informations soit la même. Sinon on sait très bien comment ça va finir, au bout de 1 mise à jour il y aura une liste qui ne sera pas à jour par rapport aux autres.

Je pense qu’effectivement ça fait sens d’avoir ces informations rentrés dans le repo Gladys en fichier de conf vu que c’est directement couplé au code de Gladys. Ca permet au développeur de faire la modification du fichier de conf dans la même PR qui va ajouter une compatibilité, et ainsi de rester en tout point consistant.

Ces informations doivent être internationalisées, donc il faudra un fichier par langue.

Il faut qu’on mette des tests pour s’assurer que si un périphérique est ajouté dans une langue, il est aussi ajouté dans une autre langue, sinon là encore on va se retrouver très vite avec des devs qui remplissent une langue et pas l’autre et la liste sera désynchronisé!

Qu’en pensez-vous?

Personnellement je suis plutôt pour la proposition 2) et 3), je pense que la 1) demande un travail trop complexe et va rendre l’UI lourde partout dans les services.

Si vous avez des idées et souhaitez proposer une PR pour ça, ça sera avec plaisir

[Reno]

Il faut aussi penser que certains périphériques peuvent être gérés par des services différents, comme par exemple les objets Xiaomi qui peuvent être utilisés avec les services xiaomi ou zigbee2mqtt. L’état du développement n’étant pas forcément le même, certains objets seront compatibles d’un des services mais peut-être pas de l’autre, …
C’est pour cela que c’est peut-être compliqué de le faire apparaître au niveau global.
A moins que l’on fasse un tableau avec le matériel sur les lignes et les services sur les colonnes. Mais ce tableau risque grossir rapidement avec le développement.

[Tlse-vins]

On va avoir le même cas de figure avec les Sonoff flashé et non flashé.
Ils fonctionneront pour un service et pas avec l’autre.
A moins d’avoir un seul et unique service pour les Sonoff

Option 2 et 3 me semble bien, je suis de l’avis de @pierre-gilles
une doc sous forme de tableau à plusieurs colonnes:

• marque
• nom du produit
• une image (option)
• le protocole du produit
• type: boutons, lampe, capteur, caméra, actionneur
• le service qui le fait fonctionné dans Gladys
• développement (jeux de couleurs: vert ok, orange en cours, rouge pas encore)
• un lien pour l’achat (pas convaincu car le lien peut être mort ce qui se passe chez jeedom)

Je le savait déjà mais on voit de suite pourquoi à côté du pseudo de @pierre-gilles, il y a écrit Leader.
Avec un petit commentaire, tu arrives à visualiser comment le mettre en place graphiquement, architecturalement, pour que ça soit viable et fonctionnel pour tous.

[AlexTrovato]

Je me permet de joindre la remarque de @Reno et celle de @Tlse-vins.
Je pense qu’il ne faut pas faire ce catalogue au niveau service, mais pouvoir lier le périphérique à plusieurs services.

Elle va etre énorme cette page

[damalgos]

Oui et non je comprend ton points de vue, cependant tu as actuellement des site qui permettent de très bien traduire comme par exemple deepl. Je vous le conseille c’est un site excellent de traduction bien plus puissant que google traduction.

Ensuite oui tu fais toutes les langues et oui certaines traductions seront peu être mauvaise ! Du coup une personne peut très bien venir et proposer une PR pour corriger la traduction.

Je pense que c’est pas trop un handicap à mon sens. Surtout que ça peut être fait tout à la fin du dev.

[pierre-gilles]

@Tlse-vins Je te rejoins pour la liste d’attribut, ça me parait bien.

Maintenant il faut voir où dans Gladys pourrait accueillir ça. J’ai du mal à voir où on pourrait caser ça pour l’instant… En fait je me demande même si ça fait sens d’avoir ça dans le produit, je vois pas où on pourrait mettre ça sans surcharger l’interface de quelque chose qui n’est forcément utile au quotidien:

Peut-être que ça n’a que sa place dans la documentation?

@Reno

Il faut aussi penser que certains périphériques peuvent être gérés par des services différents, comme par exemple les objets Xiaomi qui peuvent être utilisés avec les services xiaomi ou zigbee2mqtt.

Tout à fait, on peut indiquer la liste des services compatible dans le tableau.

@Helldog136

Je suis pas sûr que faire un fichier par langue en obligeant le Dev à remplir toutes les langues soit pratique pour avancer facilement et rapidement.
Je dirais obliger au moins à remplir le fichier “EN” si quelqu’un veut traduire il pourra le faire de manière ultérieure.

Ca par contre c’est une question de philosophie plus globale sur les traductions dans Gladys. C’est le même problème avec l’UI: quand tu développe une fonctionnalité, tu fournis les traductions dans quelles langues?

Mon avis est assez tranché là dessus: toutes les langues sur lesquels on communique doivent être supportées, partout. Je n’accepterais pas une PR qui ne supporte pas les langues sur lequel on communique, sinon l’UI sera pétée de partout et ça n’a aucun sens de dire qu’on gère cette langue.

Tu parles de l’allemand, honnêtement à part si un jour on a quelqu’un de très impliqué dans le projet qui parle allemand et qui est impliqué au quotidien pendant plusieurs mois, alors là oui on envisagera l’allemand, mais sinon non. Ajouter une langue c’est très simple, mais maintenir une langue c’est un travail du quotidien, car les traductions changent plusieurs fois par jour.

C’est la philosophie de Gladys 4: on fait peu de chose, mais ce qu’on fait on le fait bien.

Donc ne t’inquiète pas, il n’y aura que EN et FR à gérer.

[Hamtaro]

Oui, il est encore en train de travailler dessus, trouver le bon color picker.

[Tlse-vins]

On en parle ici

[pierre-gilles]

Et je continue tout mon travail d’UX sur Gladys 4!

Suite aux retours que j’ai eu, hier j’ai travaillé sur la vue « chat » de Gladys.

J’ai amélioré le design de l’état vide :

Et travaillé sur le process d’envoi de message, afin que lorsque la connexion n’est pas terrible, le message soit dans un état « en cours d’envoi » avant d’être publié:

En plus de ça, j’ai résolu le problème des messages qui n’étaient pas dans l’ordre lors de l’envoi.

Edit: Ah, et surtout grâce au travail de @bertrandda, on est passé à Preact X sur Gladys 4 !!

@Helldog136

ça serait cool d’avoir un slider de température/Couleur en fonction du type de lampes je pense.
C’est un TODO que tu as @pierre-gilles ?

Ce n’est pas encore fait oui

[Hamtaro]

Le mieux serait de pouvoir choisir par intégrations si l’utilisateur a accès ou non.

[pierre-gilles]

@Helldog136

Je n’ai vu aucune interface “user friendly” pour qu’un compte admin puisse faire celà je me suis donc tourné vers l’API REST de Gladys.

En fait la partie multi-user n’est pas encore prête: rien n’a été fait Pour ça qu’il n’y a pas d’interface ! Tous les soucis que tu as rencontrés sont juste dû au fait que c’est en cours de développements. C’est une de mes priorités actuelles avec le Z-Wave.

[spenceur]

Salut !

Quelqu’un a t’il la roadmap du lancement de Gladys 4 ?

merci d’avance

[pierre-gilles]

@spenceur : Gladys 4 est plutôt déjà lancée Les “releases nommées” type alpha, beta, ça reste des effets d’annonce pour motiver la communauté, mais derrière ça charbonne chaque jour et on a déjà un produit qui tourne sur 200 instances !

Je ne sais pas si tu as testé la v4, mais dans la v4 le process de mise à jour est transparent et automatique, même pour moi côté développeur. En gros dès qu’un commit part sur Github sur master, automatiquement l’image Docker est buildée, pushée sur Docker Hub et automatiquement les instances Gladys 4 se mettent à jour.

C’est tellement transparent que ça permet d’améliorer en continu Gladys 4, et ça fait que depuis le lancement de la beta, il y a déjà eu 33 mises à jour avec de nouvelles features (en 2 semaines seulement!). Chaque mise à jour étant déployée sur les instances directement.

Je crois que c’est plus de mises à jour en 2 semaines qu’en plusieurs années sur Gladys 3, ça en dit long sur l’intérêt d’avoir des process simple et automatisé, et surtout des technos qui permettent de le faire ! Je ne regrette pas une seconde d’avoir passé ces quasi 11 mois de travail en solo à fond sur Gladys 4 pour pouvoir arriver à une telle vélocité désormais.

Bref tous les petits manquements en termes de fonctionnalités actuels (multi-user, scénarios), tous les petits bugs qu’on découvre sont fixé au fil de l’eau. Il n’y a plus de “grosses releases”, c’est de l’amélioration continue.

On utilise les Issues + PR GitHub pour tracker l’avancement des différents développements si ça t’intéresse C’est là que les chantiers en cours sont visibles.

Après effectivement à un moment on retirera le nom “beta” du nom de Gladys 4, mais bon ça sera plus un effet d’annonce marketing qu’autre chose: si tu utilise Gladys 4, alors tu utilise systématiquement la dernière version, et tu bénéficie de mon travail continu !

Je crois que Gmail a retiré le mot “beta” de son nom après 5 ans ça sera pas forcément ça dans Gladys 4, mais pour l’instant on continu ce rythme de croisière de développement, et tant que j’aurais des supers retours de la communauté comme j’ai eu, et qu’il y a du pain sur la planche niveau features “essentielles”, alors on gardera le terme beta ^^ Pas de date pour l’instant !

Il faut savoir que la vitesse d’avancée de Gladys 4 est facteur de 2 choses :

• Le temps que je passes personnellement sur Gladys 4
• Les contributions de la communauté

Le premier critère dépend principalement du revenu que procure Gladys Plus, rien n’est magique dans ce monde et si je ne peux pas couvrir mes frais (que ce soit les frais liés à Gladys, ou juste mes coûts de vie), alors je fais du freelance à côté, et donc je passe moins de temps sur Gladys

[spenceur]

Yes je comprend bien ton raisonnement, ma question était plus pour compensé le fossé entre Gladys 3 et 4.

Je n’ai effectivement pas sauté le pas sur la V4 (sauf sur mac pour test rapide) parce que je ne trouve pas le « produit » encore très intéréssant.

La partie intégration est très peu developpé ou peut « stable » :

• le Z-wave ne semble pas stable => quelque retour
  https://community.gladysassistant.com/t/zwave-stick-non-detecte-dans-gladys-4/5031
  https://community.gladysassistant.com/t/gladys-v4-rpi-3b-zwave-probleme/4990

@MathieuA

Dans le service Zwave quand on configure le port USB du stick on a aucun retour d’info, on ne sait pas si la connexion a échoué, si elle a réussis, si elle est en cour etc. Ce n’est pas très user friendly ça.

• le xiaomi ne trouve pas mon gateway et n’est pas explicite pour la config (je partage l’avie de @MathieuA

• le module milight n’est pas encore dev :

[V4] Dev service Milight

• aucun service pour la télévision comme on avait pu mettre en place avec @piznel et @MathieuA (LG web OS, hdmi cec, panasonic viera, tv orange, tv sfr)

• pas de service sonos encore

• beaucoup de service de la V3 en somme…

La partie Gladys pur il ne me manque que les scenes a mon sens.

J’attend de voir comment évolue les choses

[pierre-gilles]

@spenceur

La partie intégration est très peu developpé ou peut “stable” :

Effectivement, comme la beta vient de sortir les développements des services viennent à peine de commencer vraiment et l’engouement de la communauté viendra petit à petit, c’est normal On a 4 ans de retard sur Gladys 3 disons aha, il faut rattraper!

[pierre-gilles]

@NoDz

As tu pu regarder pour le probleme de detection de la passerelle Xiaomi ?

En fait dans le cas du Xiaomi ce n’est pas Gladys qui va chercher les informations sur la passerelle, c’est la passerelle qui broadcast sur le réseau les informations de capteurs, et Gladys qui « écoute » ce qui se passe.

Donc si tu ne vois rien dans Gladys, c’est que ta passerelle ne broadcast pas. Je crois qu’il y a un problème avec certaines passerelles (celles compatible HomeKit), donc il faut que tu investigue toi sur ta passerelle pourquoi elle ne broadcast pas. Peut-être que le mode développeur n’est pas activé, peut-être que ta passerelle n’est juste pas compatible, etc. Il n’y a rien de spécial côté Gladys ^^

On peut en parler sur un topic spécifique Xiaomi?

[pierre-gilles]

Hello à tous!

Comme je disais, une de mes priorités en ce moment c’est le multi-utilisateur dans Gladys 4.

J’ai créé un topic pour parler du sujet sensible des permissions, n’hésitez pas à participer à la conversation ici:

Le multi-utilisateurs et les permissions dans Gladys 4

Salut à tous! Je suis entrain de travailler sur le multi-utilisateur dans Gladys 4. Comme d’habitude dans Gladys 4, je veux faire simple et faire bien. Dans certains systèmes, les permissions c’est un enfer, autant pour les utilisateurs que pour les développeurs: je ne veux pas ça. On fait simple, et efficace. On a la particularité d’avoir un système qui est hébergé chez l’utilisateur, donc au sein d’un même système on peut prendre en considération que ces utilisateurs se font confiance. Je …