Parlons de Gladys V4

[AlexTrovato]

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.

[Tlse-vins]

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.

[VonOx]

@Tlse-vins

il retrouve tous les modules qu’il a installé.

Y’a plus de modules dans la V4

@Tlse-vins

On pourrais l’appeler “Store” un jour il y aura peut être des modules payant.

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

[Tlse-vins]

• Oui, c’est plutôt des instances c’est ça?
• Oui je comprend, il faut trouver le bon therme.

[pierre-gilles]

Salut à tous!

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

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?

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.

[pierre-gilles]

@AlexTrovato

La vision est désormais bien différente, car il est clairement nécessaire de développer 2 parties, le front et le back.

Exactement!

@AlexTrovato

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.

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

@AlexTrovato

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.

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

@AlexTrovato

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.

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.

@Tlse-vins

• Oui, c’est plutôt des instances c’est ça?
• Oui je comprend, il faut trouver le bon therme.

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

[AlexTrovato]

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.

[pierre-gilles]

@AlexTrovato

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.

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!

@AlexTrovato

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.

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

[peb]

@pierre-gilles

En fait le problème est le même non?

Oui, je reconnais
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

@pierre-gilles

Aujourd’hui j’ai travaillé sur le process d’onboarding!

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 ?

@pierre-gilles

Communication

• Speak
• Telegram
• Snips?

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

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

[pierre-gilles]

C’est bon je viens de créer les 18 issues, une par service, à développer pour cette première alpha.

Le milestone est disponible ici =>

https://github.com/GladysAssistant/gladys-4-playground/milestone/4

Si vous voulez donner un coup de main, et avez des disponibilités dans les jours/semaines qui arrivent, n’hésitez pas à mettre un commentaire dans l’issue qui vous intéresse pour indiquer que vous prenez le lead sur le développement de ce service ça évitera que vous soyez plusieurs à travailler sur un même sujet. Et dès que vous commencez, je vous invite à créer une PR (que vous marquez comme « en cours »).

Je m’occuperais des services restants, mais bon le plus de coup de main vous me filerez, le plus vite Gladys 4 sortira

@peb

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 ?

On va faire au cas par cas par service. A priori le service bluetooth ça sera comme le service Z-Wave, tout sera dans le code du dossier « bluetooth ». Il y aura une séparation dans l’UI par clarté, mais derrière ça sera un seul service.

@peb

(je ne dirais pas non à XMPP ou Matrix/Riot d’ailleurs )

Commençons déjà par l’essentiel. On parle avant tout d’une alpha, et le temps de développement de chacun est limité. Mais si tu veux développer ces intégrations ce sera avec plaisir qu’elles seront intégrées

[spenceur]

Salut @pierre-gilles,

Dans Gladys 4 tu stocks les actions des scenes en base directement au format JSON.
Cela me semble en effet bien pratique a parser et dev.
En revanche, si on supprime un device pour une raison x ou y raison.
Comment gères tu le cas dans ta scene ?

[pierre-gilles]

@spenceur

En revanche, si on supprime un device pour une raison x ou y raison.
Comment gères tu le cas dans ta scene ?

Bonne question!

On pourrait faire un passage à la suppression d’un device sur toutes les scènes pour chercher si le périphérique est utilisé, et si oui empêcher la suppression.

[spenceur]

Cela ne risque til pas d’être super lourd ?
Il me semble que dans la communauté un mec a un camping.
Comment cela se passe til s’il a une multitude de scène avec chacune une multitude d’action ?

[pierre-gilles]

Les scène sont en RAM. Parcourir même 1 million d’éléments en pure JS, je pense qu’on parle en millisecondes

Après ça se benchmark, il ne faut pas que ce soit lourd.

L’autre solution serait juste d’assumer que le cas peut arriver, et de gérer le cas intelligement si jamais une scène s’exécute et que le device n’existe pas.

A mon avis il faudrait faire les deux.

[AlexTrovato]

Ou peut-être insérer l’information dans le device ?
device = {
…,
scenes: [ 1, 5, 8 ]
}

En gros faire un lien dans les deux sens.

[pierre-gilles]

Je pense pas que dupliquer la donnée soit la meilleure des solutions. Là ça veut dire qu’il faut maintenir cette liste en plus de l’avoir dans les scène. On a encore plus de risques de corruptions de données

[lmilcent]

J’allais le proposer justement :

• Parcourir les scènes et avertir (ou bloquer) lorsqu’un utilisateur veut supprimer un équipement utilisé
• Prévoir le cas où un équipement n’existe pas dans une scène (comme s’il ne fonctionnait pas finalement), pour malgré tout permettre son exécution avec un avertissement.
  Car si la scène est complexe et accède à plusieurs équipements, même s’il en manque un il est souvent encore possible de l’exécuter.

[peb]

@pierre-gilles

Commençons déjà par l’essentiel.

Absolument

@lmilcent

Prévoir le cas où un équipement n’existe pas dans une scène

On peut imaginer des équipements « nécessaires » et « facultatifs » à l’exécution d’une scène : dans le premier cas, la scène s’arrête et se mets en erreur, dans le second cas, elle s’exécute malgré tout (et renvoie un warning ?)

[pierre-gilles]

@peb

On peut imaginer des équipements “nécessaires” et “facultatifs” à l’exécution d’une scène : dans le premier cas, la scène s’arrête et se mets en erreur, dans le second cas, elle s’exécute malgré tout (et renvoie un warning ?)

Je ne vois pas l’idée ^^

Gardons les choses simples Là on parle d’un edge case qui faut gérer, l’utilisateur n’a pas à se préoccuper de tout ça.

[pierre-gilles]

Salut à tous!

Aujourd’hui j’ai travaillé sur l’UI notamment sur la façon dont le/les dashboard seront organisé et la façon dont l’utilisateur pourra les éditer.

Et, j’ai un petit dilemme.

Remarque importante

Dans Gladys 4, je compte rendre possible la création de deux types de dashboard:

• Le dashboard qu’on connait tous, le dashboard d’accueil. Il est fait pour des box assez large et présente 3 colonnes. Il sera probablement possible de créer plusieurs dashboard d’accueil, mais pas des millions non plus pour que ça reste organisé. En gros, c’est ça:

• Un dashboard “full screen”, pratique pour les tablettes ou écrans muraux Gladys, avec des box plus petites et plus serré. Pratique pour condenser de l’information sur un mur, et avoir des contrôles rapides. En gros, un truc de ce style (image prise sur google image, ce sera pas ça):

Ici, je parlerais du dashboard d’accueil.

La question

Le débat se situe au niveau de la grille utilisée, pour cela deux façons de faire.

• System n°1: Soit on a 3 colonnes, et sur chaque colonne l’utilisateur répartie et fige lui même ou chaque box ira.

C’est à dire:

Chaque box a donc 2 coordonnées, X et Y. Rien de sorcier.

• Système n°2 : Soit on a 3 colonnes, et l’utilisateur choisi juste l’ordre des box, et ensuite c’est le navigateur qui place intelligemment les boxs en fonction de l’écran et de la taille dynamique de chaque box.

La box n’a plus qu’une cordonnée, X.

Le placement est fait grâce aux “column-card” de bootstrap. C’est super smart et ça tente de mettre le maximum de donnée à l’écran en condensant tout.

C’est ce que j’utilise pour le Gladys Gateway par exemple.

Question: Qu’en pensez vous?

Le mode édition

Pour éditer les box, contrairement à Gladys 3, il ne sera plus nécessaire d’aller dans les paramètres, ce sera directement dans l’interface.

Je pense à un bouton “Edit”:

Qui quand on clique dessus, mets toutes les boxs en mode édition:

(juste la box user presence ici, c’est un exemple)

Pour l’instant je n’ai pas encore réussi à faire du drag and drop propre malheureusement, si quelqu’un est expert je suis preneur ^^ En attendant j’ai mis un système de flèche “Up” et “Down” pour bouger la box.

J’aimerais votre avis sur tout ça