@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 
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 
@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
Arf moi aussi j’ai commencé hier soir @pierre-gilles 
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
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 
Je t’avoue que je suis pas fan, je trouve ça un peu gros ^^
Edit: l’html
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 ^^
.scene_icon{ font-size: 4rem !important; margin: 0; color: #9aa0ac !important; }
Ah! Bon envoie les fichiers je vais me débrouiller avec 
Ah? Moi j’aime bien
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 ^^
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
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 
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 
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!
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.
C’est aussi ce que je voulais faire au début mais encore une fois je suis aller au plus simple 
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.
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!
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…
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é.
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.
Bref, on va dans la bonne direction! 
Xiaomi c’était obligé !
J’espère que ça fait parti du matos intégré de base dans Gladys 4
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.
