Parlons de Gladys V4


#162

Mmm ok :stuck_out_tongue:

Dommage j’aimais bien l’idée de mettre la category sur le device, mais bon ça nous restreint trop…

Donc on est d’accord, on garde la category + le type sur le DeviceFeature?

Je t’avoue qu’en terme de nommage je préfère “type” à “sub-category”.

Je suis d’accord que c’est cool d’avoir des types plus fin par contre!

Donc au lieu d’avoir:

  • binary
  • multilevel
  • color

On aurait des types plus riches:

  • binary
  • brightness
  • temperature
  • color

comme mon schéma plus haut! Petit rappel:


#163

Oui, mais je préférais la catégory au niveau des devices, du coup, il a fallu échanger un peu plus :wink:
Et il est super beau ton dessin !


#164

Un autre point dont on a pas parlé, c’est les fameux paramètres des device/deviceFeature!

Z-wave a des paramètres par périphérique, et actuellement c’est mélangé avec les deviceFeature (pas terrible)

On pourrait rajouter un attribut dans deviceFeature pour indiquer que la feature est un paramètre.

Problème: si le paramètre est un string on fait comment?

Exemple: si on veut stocker l’URL d’une caméra dans Device/DeviceFeature par ex.

ça pourrait être une autre table…

Autre idée qui n’a rien à voir: Mettre un booléen dans DeviceFeature pour activer l’historisation des valeurs ou pas (très pratique pour certain détecteur qui envoie de la valeur et dont on veut pas forcément historiser les valeurs)

(je dump mes idées comme ça)


#165

Petite modélisation de ce que ça pourrait donner:


#166

un JSON dans un champ param ? ca pourrait aussi servir à d’autre du coup.
Je me rappelle que lorsque je regardais pour organiser les features à l’affichage comme je le souhaitais, ça m’aurait bien aidé, plutôt que de te proposer de créer un champ order supplémentaire.


#167

J’y ai pensé mais ça marche pas dans le cas du z-wave! il envoie les paramètres un par un comme si c’était des features, et du coup il faudrait faire une opération lourde de:

  • SELECT Device
  • Ajouter dans le JSON la valeur
  • UPDATE device

Alors que là c’est en une opération!

Et surtout, j’aime mieux l’aspect relationnel pour tout ce qui est exposé aux développeurs, ça doit être strict en DB sinon c’est le zouk en 30 secondes ^^

Les rares endroits ou on va faire du JSON dans la DB gladys c’est pour des raisons très précises!


#168

J’ai pas trop d’avis car pas beaucoup d’expérience dans tout ça mais votre réflexion est très intéressante les gars.


#169

Ce matin j’ai pas mal travaillé sur le sujet des “modules” qui deviennent des “services” dans Gladys 4.

J’ai écris une documentation + codé un service example de bout en bout (tests inclus), afin de montrer à quoi ressemble un service dans Gladys 4.

Ce n’est qu’un premier jet, je ferais sûrement des révisions en fonction de vos retours :slight_smile:

Le README et le code est disponible ici =>

Merci @VonOx! :slight_smile:


#170

Bon je suis passé en mode wireframe, j’ai bossé sur le process d’onboarding.

Pour l’instant j’ai identifié 6 étapes:

1/ Bienvenue: Gladys accueille l’utilisateur. Petit rappel de la philosophie du projet, des valeurs et l’historique.

2/ Création du compte local: nom, email, mot de passe & répétition du mot de passe

3/ Configuration du logement: Enregistrement du nom de la maison, et ajout des pièces

**4/ Ajout des périphériques: ** L’utilisateur ajoute ses périphérique. Il a une search box et il peut sélectionner les intégrations qu’il veut configurer. (Optionnel)

5/ Configuration des notifications: Pour rester en contact avec Gladys, Gladys propose de configurer les services de communications: Telegram, SMS free, etc… (Optionnel)

6/ Connexion au compte Gladys Gateway: Présentation du Gateway, et connexion. (Optionnel)

Si vous pensez à d’autres étapes, ,n’hésitez pas!


#171

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


#172

Salut @pierre-gilles,
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 :+1:


#173

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.


#174

Je pense que je me suis mal exprimé lol,

et pour le statut “alarme détectée” cela sera géré comment ? comme un état ? ou autrement ?


#175

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

Merci du retour!


#176

Salut à tous!

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

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!


#177

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


#178

Salut @pierre-gilles,

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

Je travaille sur un module Homekit actuellement. Du coup, je me trouve confronté au problème de correspondance entre Gladys et la classification de HomeKit.

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

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

Autre difficulté rencontrée :
la caractéristique Hue est comprise entre 0 et 360 dans HomeKit (c’est la définition officielle, correspondant à l’angle sur le cercle).
Dans Gladys, ça correspond à COLOR, qui est variable selon les modules :

  • 0 à 65535 pour le module Hue,
  • 0 à 255 pour le module Milight

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.


#179

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

Bien vu! :slight_smile:

Nouvelle page, les integrations:

Hello @piznel! :slight_smile: Top tout ça!

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?

ça y est Philippe la machine est de retour :smiley:

ç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!

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.

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


#180

C’est mon côté “psycho-rigide” ! :wink:

Oui, et du coup, la présentation sera plus clair que celle d’aujourd’hui. Effectivement, à part une table supplémentaire, je ne vois pas.

C’est du HSB en fait (B = Brightness). Dans la définition officielle, S (Saturation) va de 0 à 100%, idem pour Brightness.
Du coup, on trouve bcp de lib de conversion HSB <-> RGB ou HEX, mais rien trouvé pour HSB <-> DEC. La lib Hue en intègre déjà.

Il y a un paragraphe sur la couleur dans cette lib. Je pense même que c’est encore plus compliqué que Hue !

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


#181

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

Je pense oui, histoire que chacun n’ait pas à tout redévelopper :slight_smile: 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?