Parlons de Gladys V4


#222

Pour ma part, je viens de tester Preact sur un petit projet et ça à l’air top. Je veux bien aider mais je préfère que l’on me dise concrètement ce qui peut être intéressant à faire. Du genre me donner une tâche (faire le module bidule, etc). J’aime bien le front et le back :slight_smile: Je suis pas chiant ahah

Donc je sais pas si y a un trello où on peut assigner le travail à des personnes ?

Merci :slight_smile:


#223

Pas de Trello pour l’instant. Pour le moment je ne pense pas que le projet soit en l’état de bosser dessus en mode à la chaine mais ça va venir. Je préfère bien définir les bases proprement, j’expérimente encore sur tout ce qui est architecture des dossiers, structure des classes, flow des events et modèle de donnée.

Dès que j’ai le projet qui fonctionne de bout en bout pour chaque type de module, là oui j’aurais besoin d’aide pour migrer les modules Gladys 3 vers Gladys 4 :slight_smile: Je mettrais toutes les tâches en issues GitHub je pense, et on les fermera une par une :wink:

Mais avant de passer en mode “industriel”, je ferais la doc pour que ce soit facile de contribuer, et d’être cohérent sur l’ensemble du projet.

Ici je demandais surtout une petite aide CSS pour la vue scène du frontend, rien de méchant :stuck_out_tongue:


#224

Tiens @MathieuA, je me connecte sur Twitter et là bam je vois une super inspiration!

ça ressemble pas mal à ce que tu as fais, ça confirme qu’on serait pas les seules :stuck_out_tongue:

(les liens entre chaque tâches sont fixés, c’est juste pour rendre ça clair, rien à voir avec les sacs de noeuds des interfaces de scénarios de certains éditeurs)


#225

Okkkk j’avais pas compris. Honnêtement je laisse le CSS aux autres :smiley:

Moi je suis plus à utiliser quelque chose d’existant et à le transformer un tout petit peu. J’attend avec impatience alors.


#226

Moi j’aime bien le CSS :stuck_out_tongue:

Aaaahhhh oui plutôt propre ce screen ! J’ai hésité avec les liaisons parce que justement j’ai peur que ça devienne le bordel mais après tout si on conçois bien le truc il y a pas de raison !

J’suis chaud pour faire un essai si tu veux!


#227

Les liaisons sont juste visuelle hein! Rien de selectable par l’utilisateur, on veut pas un sac de noeud :stuck_out_tongue:

Carrément si t’es chaud :smiley:


#228

Hello à tous!

Aujourd’hui j’ai bossé sur 2 choses.

1/ Le process de démarrage de Gladys en production

J’ai fais un petit poc de build Docker (juste en local, pas de multi-arch, juste un build tout simple)

L’objectif était de soulever des points tout bête:

  • Comment et quand les migrations de DB sont effectuées?
  • Comments les assets et le frontend sont servis par express
  • Quand le frontend est-il buildée?
  • Petit travail sur l’optimisation de la taille du build

Bref, j’ai passé du temps mais ça marche bien maintenant. Je suis content du résultat!

L’objectif premier étant:

  • Rien n’est effectué chez l’utilisateur, TOUT est fait au build
  • L’utilisateur n’a rien à faire, Gladys redémarre et gère d’elle même les migrations
  • L’utilisateur n’a pas à définir des variables d’environnements. C’est optionnel pour certains cas

2/ Le design du dashboard

Cet après midi j’ai fais (un peu) de CSS

Autant vous dire que j’ai passé un mauvaise après midi aha :joy:

Pour l’instant je suis parti sur une grille de 3 colonnes comme sur le Gateway.

J’ai défini un set de box, pour l’instant ce n’est qu’un premier jet.

Je trouve que certaines box ont trop de “blanc” mais je sais pas trop comment combler ça.

Bien entendu tout ça est disponible sur le site de demo =>

https://demo.gladysassistant.com/dashboard


#229

Salut,
Mon avis perso, il n’y a jamais trop de blanc. Je trouve ça super. Maintenant le multi theming pourrait pallier à ce problème de goût.
Bon boulot :wink:


#230

Franchement bravo car je trouve ça super ! Ce n’est pas nécessairement trop “blanc”, c’est juste bien et propre.

Petite précision sur par exemple l’a température de la pièce, il serait intéressant de pouvoir lui associer un variateur permettant d’avoir la température de la pièce exacte et la température de consigne.

Ce que je vois c’est la possibilité de cliquer dessus et avoir un variateur (comme sur l’iphone pour la luminosité par exemple).

Sinon j’aime bien :slight_smile:


#231

Bonne idée!

A voir comment on pourrait caser ça dans cette petite box, ça pourrait être juste un bouton + et - pour augmenter/diminuer la luminosité.

Tu me fais penser, on a pas dans Gladys pour l’instant cette notion d’état actuel et d’état désiré.

Je sais pas quelle forme ça pourrait prendre, est-ce que c’est juste un changement d’état qui prend beaucoup de temps ou une propriété à stocker quelques part… Si quelqu’un a un retour sur comment d’autres plateformes font, ça m’intéresse! :slight_smile:

Merci! :slight_smile:

Merci aussi alors, ça fait plaisir! :stuck_out_tongue:


#232

A voir comment on pourrait caser ça dans cette petite box, ça pourrait être juste un bouton + et - pour augmenter/diminuer la luminosité.

Faire attention tout de même à ne pas en mettre de trop. Tu peux par exemple avoir juste un petit icon où tu cliques dessus et un modal s’ouvre par exemple.

Tu me fais penser, on a pas dans Gladys pour l’instant cette notion d’état actuel et d’état désiré.

Effectivement, j’ai vu avec mon netatmo que par exemple je peux mettre une consigne et que l’objectif de l’appareil est de suivre cette consigne. De même pour par exemple ouverture de volet / fermeture, toutes ces choses qui mettent quelques secondes.

c’est juste un changement d’état qui prend beaucoup de temps ou une propriété à stocker quelques part

Tout dépend de ce que tu veux faire, si l’objectif c’est de donner à l’utilisateur une metric ou alors juste un état du genre “en cours”, “fermeture en cours”…


#233

Hello,

Globalement tout pareil. à quelques détails près : les séquences effectivement et également une gestion intégrée de réveil en lumière, et autres fonctionnalité On/off relatives à l’heure. Mais ça ce serait du paramétrage spécifique dans le module.

En fait, il y a beaucoup de contrôles pour une ampoule, dans le cas des RGBW tu en as au moins 5 : couleur et luminosité RGB, température et luminosité Blanc, et On/Off. Ce qui fait donc 5 lignes dans l’IHM ce qui prend vite de la place quand tu multiplies les ampoules.
On peut soit masquer des contrôles ou alors utiliser un groupe de module (template) comme par exemple :

(o)  ------o-------   o
 |                    |
 o   ---o----------  (o)

L’interrupteur vertical à gauche permettrait de passer de couleur à blanc, celui à droit serait un bouton on/off. la seekbar du haut pour la teinte ou la température en fonction du premier bouton, et celle du dessous, pour la luminosité en couleur et blanc.

Le bouton de passage de couleur à blanc ne ferait que remplacer les contrôles visibles, de ceux d’un mode par l’autre sans influer sur l’ampoule elle même. (ainsi passer du contrôle de la couleur au blanc, ne mettrait pas tout de suite l’ampoule en blanc tant que l’utilisateur n’est pas intervenu)

Le système de template pourrait être adapté à d’autres cas d’objet connecté “complexe”. On gagnerait ainsi en clarté dans l’IHM.

Si vous avez d’autres idées d’objets complexes, je suis preneur ! (j’essayerai de faire des schémas rapides pour vous donner un aperçu un peu plus visuel) :slight_smile:

Dans le cas d’une température on peut imaginer une seekbar avec un marqueur semi transparent pour la valeur actuelle, un marqueur plein pour la valeur désirée. Entre les deux la seekbar aurait un mouvement de la première vers la seconde pour symboliser qu’il y a une opération pour passer d’un état à un autre. On pourrait même teinter en rouge la section de la seekbar pour dire qu’on réchauffe et à l’inverse en bleu pour refroidir :slight_smile:

Tu peux l’être c’est top ! :+1:

Est-ce que tu compte garder le picto d’un interrupteur (à gauche des lignes) pour tout ce qui est on/off, ou compte tu mettre le picto du type d’objet controlé (un sapin/une guirlande, une ampoule etc.) ?

Bon par contre le blanc c’est mal, j’aurai Dark Reader d’activer tout le temps :stuck_out_tongue: du coup un mode nuit (gris et/ou noir) serait cool ! :smiley:


#234

Salut à tous!

Aujourd’hui petit débat pour parler du HTTPS dans Gladys 4.

J’ai réfléchi au sujet, et voilà les différents cas que j’ai relevé:

Cas n°1: Première installation de Gladys

L’utilisateur accède à son Raspberry Pi via l’IP du Raspberry Pi sur son réseau local, il s’y connecte en HTTP pour sa première connexion. Cette approche n’a pas de risque significatif, il est en local et il s’agit d’une première connexion.

Cas n°2: Utilisateur "grand public"

J’entend par “utilisateur grand public” quelqu’un qui n’a pas forcément de connaissances et qui ne souhaite pas forcément mettre les mains dans le camboui. Il est juste passionné de tech, cherche une solution domotique respectueuse de sa vie privée, et veut une installation de Gladys stable et sécurisée.

Solution recommandée: Accès à Gladys via le Gateway pour les accès distants, et en local en http pour les accès locaux. Après rien ne l’empêche d’utiliser le Gateway même chez lui, étant donné que dans Gladys 4 l’interface du Gateway et l’interface locale seront la même.

Cas n°3: Utilisateur avancé

Cet utilisateur peut utiliser le Gateway comme l’utilisateur grand public, mais veut sûrement avoir un accès direct de l’extérieur afin de pouvoir bricoler son installation même à distance.

Solution recommandée: Connexion extérieur via un domaine + Let’s Encrypt.

Je propose d’arrêter de faire de l’auto-signé, avec un accès via l’IP comme actuellement, ce n’est pas propre et aujourd’hui avec Let’s Encrypt c’est super simple d’avoir un certificat gratuit. Je pense que c’est au projet de faire des choix d’architecture qui pousse à des comportements propres et sécurisé.

L’idée, c’est donc d’intégrer à Gladys le processus de récupération + renouvellement des certificats.

Il y a un super package NPM qui s’appelle Greenlock et qui semble faire l’affaire pour ce qu’on souhaite faire ici. Il s’intègre même avec Express :slight_smile:

La question des services distants, et le MQTT

De ce que l’on a défini, le MQTT va jouer un rôle central dans la communication entre Gladys core et les services distants.

Ce que je propose: Lorsque l’utilisateur configure le MQTT (dans l’interface de Gladys, pas de CLI), il a 3 possibilités:

  • MQTT tourne sans TLS
  • MQTT tourne avec TLS et des certificats auto-signés généré automatiquement par Gladys.
  • MQTT tourne avec TLS + un domain/subdomain + des certificats Let’s Encrypt généré par Gladys

Qu’en pensez-vous ?


[TUTORIEL] - Passage de Gladys en HTTPS via Let's Encrypt
#235

Pour l’instant j’étais pas allé jusqu’à penser au sapin, mais je suis pas fermé à cette idée, on pourrait complètement ajouter des icônes personnalisées (facultative) :slight_smile:

Pour le dark mode, on dépend du thème tabler que j’utilise, le créateur du thème a communiqué qu’il lancerait le dark theme avec la version 1.0.0 de tabler :slight_smile:


#236

Transmission de pensée, j’avais pas lu ce topic encore :sweat_smile:


#237

@VonOx J’ai vu ton message pour l’optimisation des builds, tiens moi au courant c’est top ça!

Je me demande si ça serait pas plus rapide en utilisant CircleCI au lieu de TravisCI.

J’utilise CircleCI dans pas mal de projets et c’est vraiment puissant.


#238

Bah faudrai tout passer sur circleci, histoire de build uniquement si les tests sont OK.


#239

Je dis pas qu’il faudrait switcher sur CircleCI, je pense il faudrait benchmarker avant :slight_smile: CircleCI c’est puissant mais à voir dans ce cas précis si c’est plus rapide!


#240

Oui je me suis mal exprimé, si c’est concluant faudra tout passer sur circle ci :wink:


#241

@MathieuA Bon j’ai commencé l’implémentation, c’est du vrai HTML là!

Edition d’une scène

Liste des scènes

N’hésitez pas si vous avez des retours :slight_smile: