Parlons de Gladys V4

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:

1 « J'aime »

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:

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:

1 « J'aime »

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 »…

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:

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 ?

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:

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

1 « J'aime »

@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.

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

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!

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

1 « J'aime »

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

2 « J'aime »

Arf moi aussi j’ai commencé hier soir @pierre-gilles :stuck_out_tongue:

C’est pas très avancé mais certaines choses sont fonctionnelles ^^
Tu veux que je te fasse une PR pour que tu puisse récupérer ce que j’ai fais ?

Je veux bien que tu m’envoie le HTML de la vue liste!

C’est pas mal ce que t’as fais :slight_smile:

Pas la peine de la jouer PR, les fichiers en MP ça suffira je dirais.

Pour la vue d’édition de scènes, j’ai l’impression que je suis allé un peu plus loin, t’en pense quoi?

Bah disons que j’ai pas fait que de l’HTML XD
J’ai rajouté une liste de scènes, le bouton de suppression est fonctionnel ainsi que la recherche aussi…

En gros j’ai poussé le vice comme toi avec les intégrations :stuck_out_tongue:

Je t’avoue que je suis pas fan, je trouve ça un peu gros ^^

Edit: l’html

Résumé
import { connect } from 'unistore/preact';
import actions from '../../actions/scenes';
import style from './style.css';

const SceneList = connect('scenes,currentUrl,totalSize', actions)(
  ({ scenes, currentUrl, totalSize, search, play, edit, remove }) => {

    const removeScene = (scene) => () => remove(scene);
    const editScene = (scene) => () => edit(scene);
 
    return (
      <div class="container">
        <div class="page-header">
          <h1 class="page-title">
                Scenes
          </h1>
          <div class="page-subtitle">1 - {scenes.length} of {totalSize} of  Scenes</div>
          <div class="page-options d-flex">
            <select class="form-control custom-select w-auto">
              <option value="asc">A - Z</option>
              <option value="desc">Z - A</option>
            </select>
            <div class="input-icon ml-2">
              <span class="input-icon-addon">
                <i class="fe fe-search" />
              </span>
              <input type="text" class="form-control w-10" placeholder="Search Scenes" onInput={search} />
            </div>
            <div class="ml-2">
              <a href="#" class="btn btn-secondary"><i class="fe fe-plus" />New Scene</a>
            </div>
          </div>
        </div>
        <div class="row row-cards">
          { scenes.map((scene) => (

            <div class="col-sm-6 col-lg-3">
              <div class="card h-100">
                <div class="card-body p-3 text-center">
                  <div class="text-right text-green">
                    <a href="#" class="icon" data-toggle="card-remove" onClick={removeScene(scene)}><i class="fe fe-trash" /></a>
                  </div>
                  <div class={style.scene_icon}><i class={`fe fe-${scene.icon}`} /></div>
                  <h4>{scene.name}</h4>
                  <div class="text-muted">{scene.description}</div>
                </div>
                <div class="card-footer">
                  <div class="btn-list text-center">
                    <button class="btn btn-outline-primary btn-sm" onClick={editScene(scene)} id={scene.selector}><i class="fe fe-edit" />Edit</button>
                    <button type="button" class="btn btn-outline-success btn-sm" onClick={play} id={scene.selector}><i class="fe fe-play" />Play</button>
                  </div>
                </div>
              </div>
            </div>
                
          ))}
        </div>
      </div>
    );
  });

export default SceneList;

Et le CSS ^^

Résumé
.scene_icon{
    font-size: 4rem !important;
    margin: 0;
    color: #9aa0ac !important;
}

Ah! Bon envoie les fichiers je vais me débrouiller avec :slight_smile:

Ah? Moi j’aime bien :stuck_out_tongue:

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 ^^

1 « J'aime »

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

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

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…

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

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

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

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!