Gladys 4 Beta est disponible ! 🚀

[link39]

Oui je pensais donc ajouter la compatibilité à ce niveau là. Je ne sais pas si j’étais bien clair.

[damalgos]

Il faudrait pour le coup prévoir dans chaque intégration et surtout niveau code, par exemple un JSON permettant de lister tous les équipements qui fonctionnent avec cette intégration

[pierre-gilles]

Petit update à tous sur les bugs fixés / nouvelles fonctionnalités :

• Merge de la compatibilité Sonoff grâce au travail de @AlexTrovato
• Nouvelle compatibilité Philips Hue grâce à @Helldog136
• Bug compatibilité Firefox Gladys Plus
• Filtrage périphérique Xiaomi
• Amélioration de l’UX Philips Hue générale
• L’image Docker utilise Node.js 12 LTS désormais
• Bug de la page intégration vide (ajout d’un fallback vers EN)
• Bug du lien Darksky
• Amélioration de l’UI de la page des Backups de Gladys Plus
• Et plein d’autres

@damalgos

Il faudrait pour le coup prévoir dans chaque intégration et surtout niveau code, par exemple un JSON permettant de lister tous les équipements qui fonctionnent avec cette intégration

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

[Reno]

@pierre-gilles

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

Au niveau de la guideline de chaque service, il pourrait être sympa d’ajouter une rubrique « matériel supporté », avec un tableau indiquant l’état du support (supporté, en dév, pas de support, …).
En plus, ça pourrait permettre à ceux qui ont du matériel moins courant de se manifester, d’apporter les informations matérielles nécessaires au dév puis tester les évolutions associées, non ?

[VonOx]

Ou alors faut que chaque service rajoute une page avec les compatibilités et un lien directe depuis la vignette si elle existe

Edit: @Reno à été plus rapide

[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