Philips Hue Fade-in

Salut !

Ce sujet concerne la faculté de programmer un allumage progressif d’une ampoule Hue, comme présenté dans cette issue

Je n’ai pas eu beaucoup de temps à passer sur ce sujet, mais j’ai une première ébauche qui est fonctionnelle.
Je pense qu’elle nécessite discussion avant de poursuivre et de finir tout ce qui est nécessaire pour que la PR soit valide.

Les sujets qui portent à discussion :

  • Il n’y a pas encore dans le projet la notion de « scénario » associée à une Scène. Jusqu’à présent toute scène est composée d’une suite d’actions basiques comme allumer une lumière ou actionner un interrupteur. Faire un fade-in demande d’enchaîner plusieurs actions de bases, l’API Hue ne proposant pas d’action directe pour faire un allumage progressif. Ici on a donc besoin de chaîner plusieurs actions simples : allumer la lumière puis changer la luminosité à intervalles réguliers. Ce « scénario » demande un jeu de paramètres plus évolué que pour les actions basiques : on a besoin à la fois de la durée de l’allumage et de la luminosité cible. Ce n’est pas possible d’intégrer ces paramètres dans le modèle actuel et j’ai dû tricher en modifiant la validation du format des actions d’une scène pour avoir quelque chose qui tourne. Je pense donc qu’il faut réfléchir à quelque chose d’adapté.
  • Côté front, j’ai encore dû tricher pour le Component LightFadeInParams pour gérer cette « action » avec plusieurs paramètres. A discuter aussi pour faire quelque chose de plus propre.
  • J’ai joué avec des setTimeout pour faire l’allumage progressif mais je n’aime pas trop cette solution : on risque d’avoir un allumage qui finit en retard. Il faudrait sûrement s’aider d’une librairie plus adaptée. S’il n’y a pas de package adapté déjà utilisé dans Gladys, je regarderais ce qui pourrait faire l’affaire. De plus, quand le temps d’allumage est court, l’API Hue semble changer l’état de la lumière un peu en retard par rapport au retour d’appel. Ce qui provoque des « saccades » dans le processus d’allumage progressif. Je vais regarder pour peut-être limiter le nombre d’appels à l’API.

Il y a pas mal d’autres choses à revoir sur la PR mais je préfère discuter de ces sujets avant d’aller plus loin.

Salut @christophe hésite pas à faire signe si tu as besoin de testeur

1 Like

Salut @christophe et top si tu as pris le développement de cette PR :slight_smile:

Tu es sûr de ça?

En cherchant rapidement, je suis tombé sur ça:

ça ressemble à ce que l’on cherche non ?

ce n’est pas « tricher », c’est comme ça qu’on développe à chaque fois ! Si tu as besoin de plusieurs attributs dans une action, c’est normal de rajouter ces attributs à la validation.

Tu pourrais montrer directement le code pour montrer en quoi c’est « tricher » ? :slight_smile:

Haha effectivement je ne me suis attardé que sur l’API sur le site Philips et n’ai pas été assez curieux pour regarder ce que proposait le module node directement. My bad, je vais regarder pour l’utiliser.

Pour préciser mon propos sur où j’ai modifié la validation du modèle : lien

Voilà où j’ai triché dans le front, dans l’implémentation du formulaire de création d’action de fade in : lien
Cela est lié à la validation du modèle d’une scène, comme j’ai ajouté un attribut « parameters » pour gérer l’ensemble de mes valeurs (voir le lien précédent), je mets à jour l’attribut « parameters » en entier à chaque fois plutôt que de ne mettre à jour qu’un sous-attribut de « parameters ». C’est pas hyper clean, mais en l’état actuel je ne vois pas comment faire autrement.

@VonOx merci, je te solliciterai quand ce sera un peu plus stable :slight_smile:

Ah effectivement c’est pas fou, pourquoi tu n’as pas fais 2 variables ? pas besoin d’une variable parente « parameters ».

On le fait dans plusieurs actions de scène pourtant.

Exemple dans ton cas:

handleChangeTargetBrightness = e => {
    this.props.updateActionProperty(this.props.columnIndex, this.props.index, 'target_brightness', e.target.value);
};

D’ailleurs, je remarque que tu fais un setState en plus de ton updateActionProperty, c’est pas terrible car ça t’oblige à synchroniser les 2 états. Tu pourrais directement utiliser la props props.action qui est injecté par le parent !