Parlons de Gladys V4

C’est un des avantages du décalage horaire, quand vous dormez moi je bosse :wink:

Top! Après pour ça pas besoin de l’API REST, tu le fais en interne.

Complètement :slight_smile: Je pense que ce topic est très bien, si tu veux bosser sur un sujet, tu peux en parler ici! Ensuite dès que tu commences à bosser dessus, le plus tôt tu créé une PR le mieux c’est (tu peux indiquer sur GitHub que cette PR est en cours)

Effectivement ce service est crucial. C’est d’ailleurs un bon exemple pour moi de service qui sera en 2 versions:

  • Une version en interne (facile à configurer, pratique quand on a qu’un seul Raspberry Pi)
  • Une version externe pour ceux qui ont plusieurs Pi

La priorité va au service en interne, pour l’instant l’API MQTT pour les services distants n’est pas encore 100% prête.

Tout à fait ! C’est l’objectif de cette v4, apporter une expérience consistante et un produit complet qu’on maitrise de bout en bout.

Le service CalDAV est intéressant, pour l’instant je n’ai pas encore fait de service de calendrier dans Gladys 4 donc il y aura une petite partie réflexion avant le développement.

Je pense ça vaut le coup qu’on réfléchisse ensemble à tout ça :slight_smile: N’hésite pas si tu as des questions, ou même s’appeler, je suis dispo!

Salut, je reste un peu sceptique sur la partie disparition du store de modules.
Tous les anciens modules vont devenir des nouveaux services sur le repo de la v4 ??? Où seuls les services permettant d’avoir un nouveau protocole ?

Je ne souhaite pas être obligé de charger 1000 services pour un seul qui m’intéresse.

J’ai du louper un bout …

Yes :slight_smile: Je veux que Gladys soit un produit consistent, clé en main et qui fonctionne dès le début sans avoir à triffouiller comme c’est le cas aujourd’hui.

(Attention, il n’y aura pas de service redondant, on aura un seul service bluetooth, un seul service Philips hue, etc…)

Avec des modules séparé actuellement, ça créé des tonnes de problèmes. Quand tu installe un module Gladys 3, Gladys fait un git clone + NPM install + reboot de Gladys. Et on ne parle même pas d’intégrer le module dans UI, ça n’a jamais marché correctement dans Gladys 3 et on a du faire des hacks affreux pour que ça marche plus ou moins… Quand je vois le nombre de messages du forum où certains ont une UI qui a sauté à cause de l’installation d’un module, c’est pas normal que ce soit possible!

Tout ce qui est fait côté utilisateur actuellement à l’installation d’un module ne devrait être fait que côté développeur.

Après je pense que tu surestime la taille d’un service… Un service c’est quelques fichiers JS en général, on parle de quelques kilo octets de code… Je ne vois pas en quoi ça alourdit Gladys :slight_smile:

En fait je pense qu’il vaut voir Gladys 4 d’une façon différente de Gladys 3, ce n’est pas le même produit.

Dans Gladys 3, j’ai naïvement pensé que mon rôle en crééant Gladys c’était de créer la plateforme, mais de laisser « l’expérience module » séparée du core.

Mais ce que j’avais sous-estimé, c’est que ce que va retenir un utilisateur sur Gladys, c’est l’expérience globale qu’il a eu. Si il installe Gladys, qu’il installe le module speak, et que Gladys crash. (et on y peut rien, « npm install » ça rate souvent pour des raisons externes type manque de ram, downtime NPM), son feedback ça sera: Gladys ça ne marche pas et c’est instable.

Mon paradigme pour Gladys 4, c’est que les services font partie intégrante du produit, ce n’est pas des détails: c’est le coeur de l’expérience de Gladys.

Je veux pour que l’utilisateur, utiliser le bluetooth ça soit juste cocher la case « bluetooth » dans l’interface, rien de plus.

Et pour ça, ça demande d’avoir les services au coeur du produit, avec la même rigueur de développement que le core de Gladys:

  • Test unitaire avec un code coverage > 90% minimum.
  • Linting
  • Intégré au process de build, autant backend que frontend.

C’est la seule façon d’avoir une expérience globale qu’on est capable de maitriser de bout en bout :slight_smile:

N’hésite pas si tu as des questions/remise en question sur tout ça, c’est une partie que j’ai longuement réfléchi et je ne t’ai mis que les grands axes ici. On pourra aussi en parler de vive voix à l’appel communauté de dimanche!

2 « J'aime »

Dans le pire des cas, on créera un service pour charger des “plugins” :stuck_out_tongue:
Mais je comprends l’idée, soit on a une solution ouverte, voire trop ouverte (v3) soit une solution stable et maîtrisée, soumise à la validation constante de l’équipe principale (toi), la v4.
Le seul truc dont j’ai peur, c’est qui si une demande de nouveauté est faite, elle prenne trop de temps à être intégrée.

Aha ça serait revenir aux problèmes de la v3 :stuck_out_tongue:

Exactement! Après je pense que tu es inquiet par rapport à mon rythme de merge GitHub, j’y ai réfléchi et je pense que ça va être assez différent de la v3.

Sur la v3:

  • Sur la v3, il y a facilement une quarantaine/cinquantaine de repo à surveiller pour moi, c’est juste impossible de tester la conséquence d’une PR sur l’ensemble de l’écosystème, surtout quand certains repos sont inter-dépendant. Et GitHub est assez mal fait quand on a autant de repos à surveiller, même à temps plein c’est pas possible d’aller un par un sur chaque repo, et de tester des combinaisons (Gladys v3.13.0 + module 433Mhz + module serialport?)
  • Sur la v3, les modules n’étaient pas testés ni passé aux linter. Honnêtement, je pense que 90% des PRs avaient des erreurs qu’un eslint + testing voit instantanément. On a perdu beaucoup de temps sur des bêtises. Le fait que ce soit des tonnes de repo séparé rendait très compliqué la tâche de configurer chaque repo pour du linting, des tests et de l’intégration continu.

Sur la v4:

  • Un seul repo. Toutes les PR en attente à un seul endroit.
  • Dès que tu submit une PR, tu n’as rien à configurer, l’intégration continu passe, et te dit instantanément si ton service à un souci, si il ne tourne pas, s’il n’est pas conforme, si le code n’est pas de bonne qualité, si le front ne build plus, si le backend plante. Je pense que 90% des retours que je faisais sur les anciennes PR de la v3 seront donnés automatiquement par l’intégration continue :slight_smile: Il y aura beaucoup de temps gagné là dessus.
  • Le frontend de chaque PR est buildé automatiquement par Netlify qui deploy live une instance du front en mode démonstration. En un clic, même depuis mobile, je peux voir à quoi ressemble une PR en terme d’UI et donner mes retours sur le visuel. (pas possible avec Gladys 3 car Gladys 3 n’était pas une PWA statique)

En fait le fait d’avoir tout dans un mono-repo ça change beaucoup de chose.

2 « J'aime »

Salut @pierre-gilles,
super travail ça avance bien de ce que je vois :smiley: !

j’ai quelques question :

  • As tu déjà commencé a réfléchir aux gladys POD avec ce nouveau produit ?
  • As tu du monde pour faire le transfère module (V3) vers service (V4) ?

Il y a quelques modules maintenant et je pense que ça va faire pas mal de taff…

Ensuite j’avoue partager l’inquiétude de @AlexTrovato concernant les services interne.

Si par exemple quelqu’un veut un service TV phillips (par hasard [https://community.gladysassistant.com/t/recherche-module-philips-tv/4667/5]), il devra attendre que cela soit fait et déployé ?

C’est un dire que je ne pourrais pas dev un service dont j’ai pas le materiel et le faire tester a un membre comme j’avais fait avec @Jean34 et la TV Viera avant de le déployer en prod ?

il me semblait avoir compris précédemment que certain module deviendrait des services mais pas tous, a moins que je me trompe :thinking:

4 « J'aime »

Petite suggestion:

  • serait il possible de mettre un bouton on - off aux alarmes et aux scénarios.
    Je m’explique il y a des jours où je ne veux pas me réveiller à 7h00 et faire la grasse matinée. Mais pour l’instant il n’est pas possible de stopper l’alarme, uniquement de la supprimer comme les scénarios.
  • Chez Eedomus, il y a une liste des périphériques supportés classés par marque, protocole,… avec des remarques,…
    Et pour Gladys, pourrait on faire la même choses ou c’est déjà fait? Avec le module à activer pour tel ou tel périphériques, qu’est ce qu’il faut faire ( ex: flasher les sonoff, utiliser un Arduino, …)

Faudrait pas plutôt un gros service TV qui viendrait intégrer au fur et à mesure des modèles ?

Mais je suis d’accord avec toi, ça va être un peu plus chaud pour diffuser un truc à des testeurs…
J’imagine pas la galère que ça aurait été avec @piznel et son module Xiaomi s’il avait fallut toucher au « core » sans arrêt…

1 « J'aime »

Pas encore! Pour l’instant mon focus c’est vraiment d’avoir Gladys core + services le plus avancé possible, pour pouvoir sortir une alpha au plus vite :slight_smile:

Je dirais que je compte sur chaque développeur de module v3 pour aider à migrer leur module sur Gladys 4, avec mon aide bien entendu. Après le plus important dans un premier temps c’est déjà d’avoir les services « essentielles » (Z-wave, Philips hue, Milight, Bluetooth, Xiaomi, etc…), les autres services arriveront au fur et à mesure en fonction des disponibilités de chacun!

Après, je viens de regarder et sur le store de module v3 on a 54 modules publiés. Rien de méchant à migrer!

Rien ne t’empêche d’envoyer une version bêta de Gladys à un autre utilisateur. Pour rappel, l’installation de Gladys 4 est radicalement différente, c’est juste un pull d’une image Docker, donc rien n’empêche d’avoir dans l’UI de mise à jour une option avancée pour mettre à jour Gladys via image « preview ».

En fait dans Gladys 4 il faut voir Gladys comme un produit complet. Quand tu envoyais juste un module à tester à utilisateur, il n’avait pas forcément la même version de Gladys que toi, si toi tu attendais une PR qui était en attente sur le core, tu étais bloqué. Là Gladys c’est un tout, donc à priori si tu lui envoie une image toute prête, tout marchera comme chez toi.

Oui!

C’est déjà le cas!

Chaque page de configuration d’une marque de périphérique à un tutoriel riche qui explique comment configurer le périphérique. J’incite chaque contributeur Gladys a construire des UI riches et complète pour les intégrations :slight_smile:

Exemple:

Je pense qu’on va trouver des solutions pour le développement :slight_smile: Moi au contraire le souvenir que j’ai des process de développements de modules Gladys 3 c’est plutôt que c’était horrible ^^

Si tu te promène sur le sujet « Zwave », « Snips » ou « Rpi infos », tu as à la pelle des problèmes d’UIs qui sautent, ou des bugs tout bête qui devrait jamais arriver à l’utilisateur final, et qui sont uniquement dû à des problèmes de process de développement.

Je suis d’accord qu’on va perdre un peu en agilité, mais on va gagner énormément en fiabilité du produit et en sécurité. C’est qui manque actuellement à Gladys pour convertir des utilisateurs qui cherchent une solution domotique sérieuse.

2 « J'aime »

Et par rapport à ça, ne pourrait-on pas laisser un espace comme la v3, pour charger un module depuis un repo externe ? Ce qui permettrait de faciliter le test d’un module avant qu’il soit intégré au core ?

2 « J'aime »

Pas vraiment, l’image Gladys de production sera une image buildée très différente de ton installation de développement. Pour être la plus minimal possible, elle sera livrée sans aucuns build tools.

Et même, ça ne ferait pas de sens, je le répète: il n’y a plus de notion de modules, les services sont dans le core! C’est un seul et même logiciel.

Developper un service, mon premier avis :

Bonjour, j’ai passé mon week-end à développer (je ne dis pas migrer) un service de prise en charge du Bluetooth.
La vision est désormais bien différente, car il est clairement nécessaire de développer 2 parties, le front et le back.

Le front : preact c’est magique, les outils de développeur fournis avec aussi. Tu changes une page, tu sauvegarde, ton navigateur se rafraîchit et tu vois directement le résultat… c’est un réel plaisir. Et preact est tellement plaisant à coder. Mais c’est assez complexe de s’intégrer à l’existant, et les risques de conflits git entre les différents modules vont êtres considérables.

Le back : on reste assez proche de l’ancien système modulaire, service qui reste assez indépendant niveau code.

Gros avantages sur le fait d’avoir séparé le front du back, tu peux vraiment développer l’un sans l’autre avec les URL mockées, mais la phase d’intégration n’est pas neutre non plus.

Par contre on est clairement sur une version actuellement en cours de dev, non finalisée, donc je pense qu’il est important que chacun puisse noter les points encore non couverts afin de ne rien oublier.

Et j’avoue que le rendu final une fois l’intégration terminée est vraiment sympa.

Je pense déjà à un système de sous modules de services, modules de devices. Mais il sera très difficile de ne pas développer dans le repo v4.

Petite remarque, je trouve ça quand même assez fâcheux de charger les librairies zwave, philips-hue et autres, alors que je n’utiliserai pas ces services.

A + pour la suite.

Bonjour @pierre-gilles, je viens de regarder l’appel que tu as faits sur YouTube pour ce mois.
J’ai pensé à un truc pour l’onglet “intégrations”
Lorsque l’utilisateur clique sur “intégrations”, il retrouve tous les modules qu’il a installé.
Cela fait rajouter une page mais ça sera plus claire pour l’utilisateur.
Ensuite dessous les listes des devices, communication, calendrier et autres que je vois comme une liste de possibilités.
On pourrais l’appeler “Store” un jour il y aura peut être des modules payant.

Y’a plus de modules dans la V4 :wink:

Si Gladys se transforme en jeedom ça va pas le faire. Je crois pas que c’est la philosophie du projet.

1 « J'aime »
  • Oui, c’est plutôt des instances c’est ça?
  • Oui je comprend, il faut trouver le bon therme.

Salut à tous!

J’ai eu une question pertinente hier lors de l’appel communauté: A quelle date va sortir Gladys 4 ? :smiley:

Jusque-là, j’évitais de fixer une date car il était difficile de quantifier les développements étant encore en phase de “recherche” et d’exploration, et je ne voulais pas gâcher le produit en fixant une date beaucoup trop ambitieuse (ou au contraire prendre mon temps en fixant une date trop éloignée). Et surtout je sais d’expérience que si j’annonce une date, je risquais de décevoir si la date n’est pas atteinte. Mais aujourd’hui, maintenant que le premier milestone backend a été atteint, les étapes restantes sont assez claires et il est possible de se fixer un objectif de sortie! Ca permet de se donner un objectif commun et d’éviter que les développement ne traînent.

Voilà la roadmap que je vous propose:

J’ai tablé sur 1 mois pour migrer les services de Gladys 3 vers Gladys 4.

Je ne parle pas de tous les services, à minima les services essentielles:

Devices

  • Philips Hue
  • Camera IP
  • Z-Wave
  • Milight
  • Xiaomi
  • Bluetooth (à découper dans l’UI en:)
    • Bluetooth detection (Nut)
    • Autres …
  • Sonos
  • Sonoff
  • HTTP Request
  • MQTT
  • USB
  • 433 Mhz (via USB)

Total: 12

Communication

  • Speak
  • Telegram
  • Snips?

Total: 3

Calendar

  • CalDav
  • Google Calendar
    Total: 2

Weather

  • DarkSky

Total: 1

Navigation

  • Direction API

Total: 1

Cette roadmap nous emmène à un feature freeze le dimanche 23 Juin, pour une première alpha release le mercredi 26 Juin.

Qu’en pensez-vous? :slight_smile:

Je vais créer toutes les tâches et tous les milestones dans GitHub pour qu’on puisse avoir une vision de l’avancement et qu’on puisse repartir les tâches et voir où chacun en est.

Les issues/PR GitHub seront la principale plateforme de communication pour ce développement.

1 « J'aime »

Exactement!

Content que tu ai aimé toi aussi le confort de dev qu’offre preact! Pour les conflits git, pour moi Gladys ce n’est qu’un seul et même produit donc après c’est du développement git de manière général, si on fait ça proprement il n’y a pas de problèmes :slight_smile:

100% ! Ce n’est pas terminé, comme je disais on n’est seulement au milestone backend v0.1 :slight_smile:

Ce ne sera plus le cas dans la version finale, il faut que je ne charge ces libs qu’au start du service et que si l’utilisateur les a configuré. Bonne remarque.

Ni l’un, ni l’autre. Gladys 4 est un produit unique, il n’y a plus de séparation.

1 « J'aime »

Salut,
tout dépend de la disponibilité et du nombre de développeurs.
Moi, à partir de fin mai, jusque début juillet, j’aurai beaucoup moins de temps disponible.

PS (hors sujet) : pour le module Bluetooth, je compte mettre en place un système de “distance des nodes” comme tu proposes pour ZWave, il sera intéressant de modulariser cette partie, histoire de rester iso affichage.

Pour ça je vais créer toutes les issues GitHub (une par module à migrer, une par feature restantes du core) et chacun pourra indiquer si il veut aider sur certaines issues. Les issues/migrations de modules où personne ne se manifeste je le ferais.

Perso je passes mes journées là dessus, donc je pense qu’en 2 mois j’ai largement le temps de m’occuper de beaucoup de sujets restants!

Mm ok je vais créer l’issue du module Bluetooth, on en parlera dessus!

1 « J'aime »

Oui, je reconnais :smiley:
Ton idée de grouper les actions faites en même temps permettrait de palier à ces problèmes oui !
Reste à voir ce que ça peut donner :slight_smile:

Côté UX c’est chouette, c’est simple et se concentre sur l’essentiel. Je verrai bien des champs « intelligents » qui vérifient en temps réel leur contenu (comme l’adresse mail de l’user ou la correspondance des mots de passe, et passe du rouge au vert quand c’est bon)

Concernant les services, si j’ai bien compris, ils seront tous installés de base, mais activable en fonction des besoins de l’utilisateur. Top !

Du coup, coté UI, je verrai bien également un élément visuel dans la tuile du service (page des intégrations) comme par exemple une barre d’une certaine couleur en bas de la tuile avec marqué le statut :

  • Activé : Barre verte
  • Activé, configuration requise : Barre jaune
  • Activé, Warning : Barre orange (s’il y a un intérêt pour cette fonctionnalité)
  • Activé, Erreur : Barre rouge (s’il y a un intérêt pour cette fonctionnalité)
  • Désactivé : Barre grise

Ensuite, je verrai bien une séparation visuelle entre les services actifs, et les services disponibles, ce qui ferait 2 catégories la première au dessus de la seconde.

Concernant les technologies employées, comment s’organiseront l’intégration des différents objets des différentes marques / créations personnelles ?

Je prends l’exemple du Bluetooth : Y aura t il un service Bluetooth maître qui se charge de faire des connexions, et des services dépendants qui gèreront chaque produit ou fonctionnalité
/marque comme la vérification de présence de l’utilisateur via les Nuts ou autre, les ampoules Awox, et des objets Bluetooth « maison »? Ou ce sera juste une séparation au niveau UI ?

Oh oui oui oui ! Snips :smiley: (je ne dirais pas non à XMPP ou Matrix/Riot d’ailleurs :stuck_out_tongue: )

Et je serai dispo pour tester l’alpha à sa sortie :wink:

1 « J'aime »