Gladys 4 Beta est disponible ! 🚀

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

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

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

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

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

4 « J'aime »

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 ?

1 « J'aime »

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 :sweat_smile:

Grilled @VonOx :wink:

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 :wink:

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.

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 :slight_smile:

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.

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.

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 :wink:

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.

1 « J'aime »

@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:

:arrow_right: Peut-ĂȘtre que ça n’a que sa place dans la documentation?

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

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.

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

On en parle ici

1 « J'aime »

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 !! :rocket:

Ce n’est pas encore fait oui :slight_smile:

1 « J'aime »

Le mieux serait de pouvoir choisir par intĂ©grations si l’utilisateur a accĂšs ou non.

En fait la partie multi-user n’est pas encore prĂȘte: rien n’a Ă©tĂ© fait :slight_smile: 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.

Salut !

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

merci d’avance :slight_smile: