Parlons de Gladys V4

[pierre-gilles]

Salut à tous!

J’espère que vous avez passé un bon week-end.

Hier et ce matin j’ai travaillé sur la définition des états / des transitions entre états. Cela peut paraître un sujet tout bête, mais c’est une vraie réflexion.

Chaque entité dans Gladys est un automate fini avec plusieurs états et des transitions entre chaque état. Ces états et ces transitions il faut les définir et les nommer.

Le sommeil d’un utilisateur

4 états:

• Réveillé
• Endormi
• Doit se réveiller
• Doit se coucher

Voilà le schéma des transitions. Chaque transition correspond à un événement dans Gladys, un “trigger” sur lequel n’importe quel scène peut se brancher.

L’alarme de la maison

Dans Gladys 4, j’amène la notion d’alarme pour la maison afin que Gladys puisse enfin est une centrale d’alarme propre et clair.

Comme le sommeil, 4 états:

• Armée
• Désarmée
• En cours de tentative d’armement
• En cours de tentative de désarmement

La présence à la maison des utilisateurs

L’exécution d’une scène

L’état du soleil

La présence au travail

Enfin exemple d’un périphérique de category "light"

Si ces exemples vous parle/vous font réagir, n’hésitez pas, rien n’est figé

[VonOx]

Oui tu parles de scenario, les graphes c’est le Flow entre les états.

Et il y’a bien l’état armed pour l’alarme.

[pierre-gilles]

@Jap93

Pour la partie alarme de la maison, comment gère tu l’état “alarme activée” suite à une détection ? Faut-il pas un état aussi alarme activée ?
Pour l’état entrée sortie de la maison est ce que cela activera/désactivera automatiquement l’alarme ou faut-il passer par un scénario ?
Pour l’instant je ne vois que sa car tu as pas mal pensé à tous les cas

En fait dans ce diagramme effectivement j’avais assumé que la partie « activation » de l’alarme était plus côté scénario, après je pense que tu as raison, ça vaudrait le coup de le mettre là, au moins pour définir les noms des différentes transitions

Merci du retour!

[pierre-gilles]

Salut à tous!

Aujourd’hui gros boulot sur le frontend, je suis dans le dur du sujet

Voilà un petit preview, vous avez des retours/idées pour l’organisation de la barre de navigation je suis preneur!

Pour le login j’hésite entre deux version…

Dites moi ce que vous en pensez!

[Hamtaro]

Avec logo pour le login pour moi.
D’ailleurs, tu renommes pas Gladys Assistant également dans le dashboard ?

[pierre-gilles]

@Hamtaro

Avec logo pour le login pour moi.

Je pense partir sur ça, sur Twitter tout le monde est unanime

@Hamtaro

D’ailleurs, tu renommes pas Gladys Assistant également dans le dashboard ?

Bien vu!

Nouvelle page, les integrations:

@piznel

Je travaille sur un module Homekit actuellement.

Hello @piznel! Top tout ça!

@piznel

Je ne vois pas ce que sont précisément les paramètres par feature du Zwave. Tu aurais un exemple ?

Chaque périphérique Z-Wave a des paramètres (ex: fréquence de rafraichissement, sensibilité du capteur luminosité, seuil de détection d’un intru, etc…) que tu peux régler. J’ai proposé un DeviceParam pour pouvoir stocker ces paramètres, qui pour moi ne sont pas vraiment des features, ce sont des paramètres.

Ce DeviceParam pourrait servir à stocker d’autres choses, exemple: les credentials d’une caméra IP, ou autre.

Tu vois l’idée?

@piznel

J’ai donc fait un excel reprenant tous les services et caractéristiques d’Homekit.

ça y est Philippe la machine est de retour

@piznel

Ça me semble une bonne base de départ. Tu en penses quoi ?

ça se rapproche de ce qu’on s’est dit je trouve non? une category + un type?

A la différence de quelques différences de nommage, mais l’idée est la même!

@piznel

Je pense que ça serait pas mal de définir chaque propriété des catégories ; ça permettrais aussi de standardiser l’affichage ; dans l’exemple ci-dessus, le colorpicker ne peut pas fonctionner avec le Module Milight.

Je suis 100% d’accord pour harmoniser!

Il faut qu’on fasse un choix qui ratisse assez large pour pas perdre d’information sur les périphériques qui permettent des valeurs fines, et il faudra convertir la couleur avant de l’enregistrer dans Gladys.

@piznel

0 à 65535 pour le module Hue,

Le module hue c’est compliqué, tu as 3 deviceType: hue et saturation et brightness, c’est du HSL si je me trompe pas.

Milight j’ai l’impression qu’ils font du RGV mais il y a des fonctions de conversions HSL dans ce module par exemple => https://www.npmjs.com/package/node-milight-promise (rapide recherche)

A nous de décider quel format on préfère dans Gladys, et à coder les différents getters/setters dans Gladys 4 pour que le module puisse juste envoyer ses data

[pierre-gilles]

Et hop le filtering qui fonctionne sur la page intégrations, ça en jette!

https://twitter.com/pierregillesl/status/1098166550345830406?s=20

@piznel

Ca veut dire qu’on proposerait nativement des API de conversions, que le développeur appelle selon ses besoins ?

Je pense oui, histoire que chacun n’ait pas à tout redévelopper Après pour les cas très particulier le développeur devra coder lui même sa fonction de transformation dans un sens/dans l’autre.

Du coup tu verrais quoi comme format de couleur toi? Je pense il faudrait un format entier comme ça on peut le stocker et le colorpicker fonctionne, t’en pense quoi?

[pierre-gilles]

@piznel

Mais j’aurais tendance à faire comme Philips Hue (comme je ne connais pas mieux sur le marché), à savoir :

Je suis d’accord!

@piznel

Là où ça va se compliquer, c’est pour les devices à 256 couleurs, car le colorPicker ne sait pas les gérer, et de ce que j’en ai vu, passer de 65K à 256 couleurs n’est pas si simple, sans parler du fait que l’user verra une couleur qui ne correspondra pas à ce qu’il a choisi.

J’ai trouvé ça => https://www.npmjs.com/package/color-convert

On va forcément s’en servir mais bon c’est déjà des super exemples

[VonOx]

Mes 2 centimes, un pourcentage est plus simple pour l’utilisateur final. Derrière comment ça se passe c’est une autre histoire

[VonOx]

C’est une expression “my 2 cents” vulgairement traduite , juste pour signifier ma toute petite contribution à la discussion

[luke]

Bonjour,

Cela serait peut être bien de prévoir nativement Gladys v4 avec un front-end et un back-end

• le front-end donne accès au box ( boutons, infos,…)
• le back-end accès aux paramétrages (ajout périphérique…)

avec aussi la possibilité de thème coté front-end
ainsi suivant l’endroit, le terminal on accède au front-end sur le thème désiré (avec un paramètre défini coté back-end [ user → terminal → template])

front-end
|------- theme1
|------- theme2
|------- …
back-end

[pierre-gilles]

@luke

Cela serait peut être bien de prévoir nativement Gladys v4 avec un front-end et un back-end

C’est effectivement le cas dans Gladys 4, le front est une PWA avec preact et le back un serveur Express

Pour le thème, Gladys 4 va offrir la possibilité de créer des dashboard personnalisé (et pas qu’un seul dashboard, plusieurs!), donc ça devrait répondre au besoin.

Pour avoir différentes UI, pour l’instant on va se concentrer sur créer une seule UI, c’est déjà assez complexe comme ça

[luke]

@pierre-gilles

C’est effectivement le cas dans Gladys 4, le front est une PWA avec preact et le back un serveur Express

Pour le thème, Gladys 4 va offrir la possibilité de créer des dashboard personnalisé (et pas qu’un seul dashboard, plusieurs!), donc ça devrait répondre au besoin.

Pour avoir différentes UI, pour l’instant on va se concentrer sur créer une seule UI, c’est déjà assez complexe comme ça

Top merci

[link39]

@piznel

il faudrait également la température de couleur, mais j’ai pas encore regardé.

Les milight gèrent de 2700k à 6500k et les hue de 2000k à 6500k.

[link39]

Salut,

Je partage avec vous une réflexion que j’ai eu en voyant le “Light device State”. Ne devrait-on pas représenter le changement de la température de la couleur ? Après c’est vrai que toutes les ampoules ne le gèrent pas, mais tout comme le HSB en fait. Du coup est-ce que le schéma ne devrait pas représenter que les états ON/OFF?

[pierre-gilles]

@link39

Après c’est vrai que toutes les ampoules ne le gèrent pas, mais tout comme le HSB en fait. Du coup est-ce que le schéma ne devrait pas représenter que les états ON/OFF?

Ce schéma était un exemple non-exhaustif Pour les ampoules, il faut qu’on choisisse effectivement le format qu’on va gérer, pour l’instant on est plus parti sur l’approche philips hue, après je pense qu’on va voir lors de l’implémentation avec les différents fabricants si ça se plug bien ou pas, et comment on résout les différentes incompatibilités.

[Leroy]

j’adore, c’est très épuré. super boulot @pierre-gilles

[pierre-gilles]

Salut à tous!

Aujourd’hui j’ai travaillé sur tout le moteur de scénario, avec deux objectifs:

• Concevoir un moteur riche avec toutes les fonctions dont on a besoin (Trigger + conditions multiples avec des ET/OU + actions)
• Concevoir un moteur très performant et économe en ressource

Ce soir je viens de finir une première version minimale du moteur, et… ça dépote!!

1/ J’ai défini les différents évènements, états, et conditions dans un fichier de constantes. Ce n’est pas une liste exhaustive, mais cette première liste m’a permis de commencer Je l’étofferais au fur et à mesure des développements (il faut pour cela écrire les schémas UML d’états, je fais ça proprement).

2/ Tous les états sont stocké dans un store en mémoire pour des performances en lectures maximales. Les états sont persistés sur disque mais cette persistence n’est utile que pour la visualisation (courbes), pas l’interrogation en temps réel dans un scénario.

J’ai donc fais une petite simulation de performance avec mon premier moteur.

J’ai créé un cas d’usage typique voir un peu extrême:

• Un utilisateur avec 300 scénarios (généré aléatoirement, avec des triggers au hasard)
• 5 conditions par trigger
• 1000 états à surveiller
• Pas de travail asynchrone. L’objectif du benchmark n’est pas de tester la performance d’une tierce-partie, mais juste du moteur en lui même, donc on évalue ici juste la performance de l’évaluation des conditions, en gros: combien le moteur peut manger par seconde!

La vidéo parle d’elle même =>

https://twitter.com/pierregillesl/status/1100344419742404608?s=20

On est sur du 1.35 millions d’évènements par secondes héhé

@Leroy

j’adore, c’est très épuré. super boulot @pierre-gilles

Merci!

[pierre-gilles]

@piznel

On pourra mettre une tempo dans les scénarii ?

Biensûr! C’était dans le manifeste je crois

[pierre-gilles]

@piznel:

J’ai ajouté le delay au actions, c’était une action facile

Tu peux faire dans des actions:

[{
  "type": "delay",
  "seconds": 10,
  "then": [{
    type: "light.turn-on",
    deviceFeature: "piznel-lamp"
  }]
}]

Cette séquence d’action va attendre 10 secondes, puis allumer la lampe qui a pour selector “piznel-lamp”!

Note: Tu peux utiliser “milliseconds”, “seconds”, “minutes”, ou “hours” !