Parlons de Gladys V4

[pierre-gilles]

D’ailleurs, petite remarque, je vois que tu t’ai inspiré de mon code de la vue intégration, code qui n’est pas forcément bon

Je suis encore en phase d’exploration pour certains mécanismes, par exemple je vois que tu as créé deux fonctions ici =>

const removeScene = (scene) => () => remove(scene);
const editScene = (scene) => () => edit(scene);

Je sais que c’est comme ça que j’ai fais dans intégration, mais c’est pas best practice! Ca créé des nouvelles fonctions à chaque render du composant et donc ça alourdit l’app

[MathieuA]

@pierre-gilles

J’aime bien l’idée qu’on voit directement tout le scénario et qu’on puisse l’éditer comme ça, sans forcément avoir à rentrer dans une série de modal.

Pour l’instant il y a 0 modals dans Gladys 4 tu as du remarquer! Je suis pas contre les modals mais j’aimerais qu’il y en ait bien moins que dans Gladys 3 ou quasi tout était modal ^^

Complètement d’accord ! Mais moi j’imaginais plus une petite popup qui s’ouvre a coté ^^
J’ai peur que la avec beaucoup d’info ça deviennent chiant à lire…

@pierre-gilles

Je sais que c’est comme ça que j’ai fais dans intégration, mais c’est pas best practice! Ca créé des nouvelles fonctions à chaque render du composant et donc ça alourdit l’app

Oui oui je sais, et j’ai tenté pleins d’autres choses pour éviter ça mais j’ai abandonné et je me suis dis qu’on pourraient changer ça plus tard

Bon par contre j’ai créé une branch et j’ai commit sur le repo en pensant que c’était mon fork
Désolé… mais au moins tu as les fichiers

[pierre-gilles]

Ok! J’ai regardé ça, c’est cool de voir comment intuitivement tu as développé ça, ça me fait penser qu’avant qu’on commence à bosser en groupe il faut absolument que j’écrive des guidelines pour qu’on ait les mêmes process pour développer des nouvelles routes

Je parle pas du style de code qui est déjà enforce par Eslint, juste des méthodes de dev.

Un exemple:

Je vois que pour changer de route vers la route d’édition, tu as fais une fonction “Edit”:

edit(state, scene) {
    const name = scene.name.replace(/[^A-Z0-9]/ig, '_').toLowerCase();
    store.setState({
      sceneEditing: scene
    });
    route(`/dashboard/scene/edit/${name}`);
  },

Il faut éviter ça, car si on accède directement à la route juste en entrant l’URL, le state ne sera pas présent! Ici un <Link> est suffisant.

D’ailleurs la routes GET /scene ne retournera probablement qu’une liste de scene avec juste le name, l’id et le selector. C’est la la vue d’édition qui lorsqu’elle chargera ira chercher la scene en entier!

[MathieuA]

@pierre-gilles

Il faut éviter ça, car si on accède directement à la route juste en entrant l’URL, le state ne sera pas présent! Ici un est suffisant.

Oui ça je m’en suis rendu compte
Mais comme je suis pas encore assez familier avec Preact (et ces framwork en général) je suis aller au plus simple pour le moment.

@pierre-gilles

D’ailleurs la routes GET /scene ne retournera probablement qu’une liste de scene avec juste le name, l’id et le selector. C’est la la vue d’édition qui lorsqu’elle chargera ira chercher la scene en entier!

C’est aussi ce que je voulais faire au début mais encore une fois je suis aller au plus simple

[pierre-gilles]

Tkt pas de soucis D’ailleurs comme je disais tout dans l’architecture du projet Preact actuel n’est pas encore clair dans ma tête non plus, j’expérimente encore sur certains sujets! On est encore très loin d’être en phase “développement industriel” sur Gladys 4, c’est beaucoup d’expérience encore de mon côté.

Je viens d’intégrer ton design, c’est cool il rend bien =>

D’ailleurs j’ai rajouté un onglet “Trigger” pour gérer la liste des trigger. Mon avis là dessus c’est que c’est clairement quelque chose de séparé des scènes, vu que c’est toute une complexité aussi.

Il va falloir réfléchir à comment on modélise le trigger + les conditions.

Pour la vue d’édition de scènes, pour l’instant je préfère celui que j’ai fais, après je suis d’accord on peut travailler pour réduire l’espace que chaque action prend.

[pierre-gilles]

Pour revenir sur le sujet du service Philips Hue, j’ai fini une première version très sommaire de ce service (côté serveur tout du moins, l’interface ne fonctionne pas encore à 100%)

Tout le code du service est ici.

Les tests sont ici.

Une fonction intéressante de ce service est la fonction light.turnOn.

J’ai essayé de faire quelque chose le plus simple possible, et en donnant le minimum de chose à faire au service.

Je n’ai volontairement pas fait tout le service gladys-hue, comme j’expérimente encore, si on trouve des choses à changer je préfère n’avoir à modifier que quelques fonctions plutôt que toute l’API

Je vais continuer à réfléchir à d’autres services “classiques”, afin de me faire la main et de voir si cette implémentation fait sens!

[Hamtaro]

Oulala que c’est beau les gars !!!
Je lis attentivement vos messages histoire de m’imprégner de savoir… Peut être que ça va me servir un jour quand j’aurais la motivation de plonger là-dedans…

[pierre-gilles]

Hello à tous!

Aujourd’hui j’ai travaillé sur 2 sujets, le premier c’est le MQTT.

J’ai défini la spécification de l’API MQTT de Gladys 4:

https://gladys-4-docs.gladysassistant.com/en/development#mqtt

N’hésitez pas à me donner vos retours avant que je me lance dans l’implémentation

L’autre sujet, c’est de gérer le polling de certains types de périphériques.

Je m’explique.

Certains périphériques comme les Philips Hue ont des méthodes pour rafraichir l’état des ampoules, au cas où l’état ait été changé hors-Gladys, comme par exemple via un interrupteur.

Jusque là, c’était le module qui gérait le polling.

Désormais, c’est intégré à Gladys.

Chaque device a 2 attributs: “should_poll” et “poll_frequency”, et Gladys va automatiquement aller requêter périodiquement le service via une méthode “poll” pour lui demander de mettre à jour l’état d’un device donné.

[pierre-gilles]

Petites statistiques intéressantes, les recherchent des derniers mois sur le forum par recherche les plus fréquentes!

Aucune surprise, ça confirme les intérêts des gens en domotique en 2019.

• Xiaomi, les périphériques bluetooth, Sonoff, Zwave et Yeelight sont les hardware qui sont les plus cherchés. Ca ne m’étonne pas vu l’excellent rapport qualité/prix de l’offre domotique Xiaomi.
• Côté problème rencontrés propre à Gladys, le HTTPS, Docker et MQTT arrivent en top. Aucune surprise, ça confirme mon amibition de simplifier ces trois points dans Gladys 4.
• Côté intégration logicielle, sans surprise avec Snips, Spotify, Alexa et Telegram.

Bref, on va dans la bonne direction!

[Hamtaro]

Xiaomi c’était obligé !
J’espère que ça fait parti du matos intégré de base dans Gladys 4

[pierre-gilles]

Je vais avoir besoin de l’aide de @piznel pour migrer son excellent module, mais oui c’est l’objectif !

Xiaomi est dans les services obligatoire pour la v4, pas de débat là-dessus.

[MathieuA]

@pierre-gilles

Je vais avoir besoin de l’aide de @piznel pour migrer son excellent module, mais oui c’est l’objectif !

Ça va être compliqué… @piznel est offline pendant un bon moment !

[VonOx]

Que passa avec piznel j’ai loupé un épisode ?

[pierre-gilles]

Bon, je viens de créer une liste assez exhaustive des tâches restantes à faire avant d’avoir une première version minimale fonctionnelle du backend de Gladys 4.

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

Ce milestone n’inclue pas:

• Le travail sur le front-end
• Le travail sur l’API pour les pods
• Le travail côté services

J’ai créé ce milestone afin de lister toutes les tâches restantes à faire (autant code que documentation) avant qu’on puisse bosser sur les services.

Le frontend va continuer à être développé en parallèle, même si pour l’instant mon focus personnel est sur l’API.

@MathieuA

Ça va être compliqué… @piznel est offline pendant un bon moment !

Aïe dommage, on parle de jours/mois/années? Bon on se débrouillera

[MathieuA]

@VonOx

Que passa avec piznel j’ai loupé un épisode ?

Des raisons perso mais il va bien hein, et non t’as pas raté un episode ^^

@pierre-gilles

Aïe dommage, on parle de jours/mois/années?

Aucune idée ! Mais je dirais quelques mois au vue des dernières nouvelles

J’ai vue ta liste @pierre-gilles, afin j’ai reçu les 40 et quelques mails ce matin

Mais par contre, pourquoi dans chaque route tu met v1 ? Tu compte versionner les API ?

@pierre-gilles

Le frontend va continuer à être développé en parallèle, même si pour l’instant mon focus personnel est sur l’API.

Si tu veux je peux faire quelques trucs pour te faite gagner du temps ! Dis moi juste ce que tu veux que je fasse. Par exemple j’ai vu que le drawer ne fonctionne pas sur mobile, je peux remédier à ça ?

Enfin je peux faire des petits trucs comme ça en attendant que tu définisse correctement les guidelines ?

Autre chose, j’ai buildé la branche V1 de tabler et je me suis aperçu que tout le template a été repris à zéro et pas mal de choses ont changées ! Alors je me demande si il vaudrait pas mieux partir de cette version même si elle est pas encore complètement aboutie plutôt que d’avoir à refaire les trois quarts du boulot dans deux ou trois mois quand ils sortiront enfin la V1 non ?

[pierre-gilles]

@MathieuA

J’ai vue ta liste @pierre-gilles, afin j’ai reçu les 40 et quelques mails ce matin

aha désolé pour le spam, j’ai bourriné

@MathieuA

Mais par contre, pourquoi dans chaque route tu met v1 ? Tu compte versionner les API ?

Yes! L’API est versionée. Si on commence à avoir des apps mobiles, des services externes qui en dépendent, on peut pas se permettre de casser l’API. Donc si jamais on change le format de réponse d’une API, on garde la route v1, et on créé une v2, tout simplement

@MathieuA

Si tu veux je peux faire quelques trucs pour te faite gagner du temps ! Dis moi juste ce que tu veux que je fasse. Par exemple j’ai vu que le drawer ne fonctionne pas sur mobile, je peux remédier à ça ?

Mm le drawer j’ai envie de dire t’embête pas il fonctionne sur le gateway, faut juste que je reprenne le code qui fait ça :slight_smile

Par contre je veux bien de l’aide sur des questions frontend, comme l’autre jour sur la vue des scènes ça m’a bien aidé Vu qu’effectivement niveau guideline frontend je pense pas qu’on soit prêt, t’embête pas trop avec le code, juste déjà des petits coups de pouces design ça m’aide énormément, c’est mon gros points faible le CSS ^^

Quelques idées:

1/ Au niveau de la vue chat, j’ai galéré à refaire un chat et je suis pas super satisfait du résultat car bulles de chat ne sont pas proportionnelles à la taille du texte. Je pense qu’il faudrait juste reprendre le CSS de Gladys 3 qui était top (en rajoutant peut être les avatar, vu que dans Gladys 4 a priori un utilisateur aura un avatar + Gladys a maintenant un logo!).

2/ Si tu vois un moyen de réduire la taille de la vue « édition de scène ». Je suis d’accord que ça rend trop gros pour l’instant. Après je veux garder une clarté et une simplicité d’utilisation, il faut que ça reste aéré quand même!

3/ Je n’ai pas encore du tout pensé à la vue « édition de trigger »

@MathieuA

Autre chose, j’ai buildé la branche V1 de tabler et je me suis aperçu que tout le template a été repris à zéro et pas mal de choses ont changées !

Ah mince, le CSS change complet ?

Il faut qu’on évalue un peu quand ils prévoient de release. Je suis pas forcément pour switcher sur la branche v1 si ils travaillent encore dessus activement, la version actuelle est largement bien pour ce qu’on fait! Après effectivement si ils sortent la v1 dans 2 semaines oui d’accord ^^

[pierre-gilles]

Pour ceux qui me suivent sur GitHub, je tabasse bien en ce moment sur le Backend de Gladys 4, j’avance bien dans le milestone 1

Les derniers jours j’ai travaillé sur:

• L’API de gestion des maisons (création/édition/suppression) + la présence de l’utilisateur
• L’API de gestion des pièces (création/édition/suppression)
• L’API de géoloc
• Gestion des refresh token (revocation, récupération d’un nouvel access token)
• Procédure de récupération de mot de passe

[pierre-gilles]

Salut à tous!

Petite nouvelle d’avancement de Gladys 4

Avancement du premier milestone backend

Le milestone backend v0.1 avance bien, on est à 54% des tâches réalisées. J’ai rajouté quelques todos en chemin, mais je pense qu’une fois toutes les tâches réalisées on aura déjà un backend minimal qui fait le boulot.

Documentation de l’API REST en ligne

Je viens d’héberger la documentation de l’API REST de Gladys 4 en ligne:

https://gladys-4-apidoc.gladysassistant.com/

N’hésitez pas à aller voir et à critiquer certains choix de nommage, ou de paramètre passés aux routes d’API, comme rien n’est encore sorti on peut encore tout changer. C’est toujours cool d’avoir des avis extérieurs

Les scripts dans Gladys 4

J’ai une petite question pour vous par rapport aux scripts dans Gladys 4.

En terme d’interface, je me demandais si ça valait le coup d’avoir un onglet script séparés des scènes.

Est-ce qu’un script dans Gladys 4 ça ne pourrait pas être juste une action d’une scène qui dit “exécute ce bout de code JS” ?

Les +

• Concevoir une scène complexe est plus simple, on peut dans une scène coder des bouts de code qui s’enchaine en séquentiel/parallèle depuis la même UI, sans avoir à sauter entre l’UI de scène/de script
• Donner moins d’importances dans l’UI aux scripts dans un produit qui s’adresse à un public pas toujours dev (tout en les gardant bien-sûr pour les power user!). Est-ce que réserver un onglet entier aux scripts est utile? Pas sûr…
• Une meilleur intégration avec les scènes. Exemple: Passer une valeur d’un trigger à une scène et retrouver la valeur dans le script.

Les -

• Apporte peut être une complexité à l’UI de scène qui doit incorporer un éditeur de code (ce qui est lourd)
• Les gros scripts peuvent perdre en lisibilité (d’ailleurs je n’ai pas forcément encore d’idée sur comment coder ces scripts dans la vue scène)

Dites moi votre avis sur la question, c’est un débat rien n’est encore fixé!

[Hamtaro]

@pierre-gilles

Est-ce qu’un script dans Gladys 4 ça ne pourrait pas être juste une action d’une scène qui dit “exécute ce bout de code JS” ?

D’accord avec toi sauf quand on veut juste le lancer tout seul à la mano pour tester un petit truc rapidement, ça reste pratique de l’avoir dans une liste à part.
A voir si la même chose est faisable dans la partie scène…

[pierre-gilles]

@Poisson48

Je pense que les gros sripts sont dans tous les cas écrits sur un éditeur de texte a part ( sur un pc ) avant d’être envoyé a Gladys non ?

Effectivement! Après le but de l’éditeur de script dans Gladys c’est que justement il est assez complet pour pouvoir coder dedans proprement…

@Poisson48

En tout cas j’ai hâte de la V4, la V3 est belle et bien plus orientée devs que débutant et je pense que sans un minimum de connaissances il est quasi impossible de la configurer comme on le souhaite.

C’est le but!

@Sernoz

on aura juste à update Gladys sans perte de donnée ou tout réinstallé ?

Gladys 4 est une re-écriture complète, il n’y a aucune lignes de code en commun entre les deux codebase. C’est un nouveau produit complet Vu les changements, ce sera forcément une réinstallation (on change complètement de techno et de process de déploiement). En revanche on fournira probablement un outil de migration pour récupérer certaines données

A voir justement quelles données on veut transférer de la v3 à la v4. Tout n’est pas bon à garder, et il ne faut pas que ça créé des bugs mystique à cause de données mal formatées de la v3.

@Hamtaro

A voir si la même chose est faisable dans la partie scène…

C’est la même chose pour les scènes! C’est le but des scène, tu peux cliquer sur « play » et ça joue la scène.