J’ai développé le plugin Natural Light.
Il a été testé dans mon environnement : ZigbeeLinker et ampoule de différentes marques (Hue, Ikea, Leroy Merlin)
J’ai cependant trouvé et imaginé des comportements différents, et j’aimerai avoir votre avis :
J’ai tenté une formule à ma sauce liée à la période de la journée (heure de levé de soleil, heure de coucher, et l’heure auquel le soleil est le plus haut)
Cela risque d’être éblouissant au matin en été. Mmmh
J’ai tenté une autre formule liée à l’heure de la journée. Style entre 7H et 10H, la couleur passe du jaune au bleu, puis reste jusqu’à 9H comme cela avant de décliner en jaune.
Peut-être le plus juste. Mais mes horaires ne sont pas ceux des autres. Et encore moins le weekend et jours fériés
Du coup, avant de faire une usine à gaz, j’aimerais avoir votre avis et vos besoins. Tout ne sera pas réalisable, surtout au début. Mais cela me donnera des pistes.
J’aime bien l’idée de ton plugin. Je vais le tester. Pour l’instant j’ai regardé un peu le source, mais je ne comprends pas un truc : j’ai l’impression que tu envoie directement la valeur de la température de couleur désiré (en Kelvin) à l’ampoule, quel que soit son unité.
Par exemple, pour les ampoules Ikea, la variation se fait de 250 (4000 Kelvin) à 454 (2200 Kelvin). Ne faudrait-il pas ajouter au niveau de chaque équipement une correspondance du min et du max et faire un calcul permettant de transformer la température désirée dans l’unité de l’ampoule ?
[EDIT] En cherchant mieux, je vient de découvrir l’unité Mired qui est celle que tu utilises ainsi qu’Ikea !
Une première petite remarque : on peut avoir envie de limiter la variation de température de couleur de l’automatisme (ampoule trop rouge ou trop blanche à ses limites). Pour faire ça, j’aurai pensé régler les limites de l’équipement naturalLight. Mais à chaque refresh, l’équipement reprend les limites de l’ampoules (à cause des lignes 341 / 342 naturalLight/naturalLight.class.php at 944e0feced3ce398c69324d124f4e54dea20e91e · Arnaud69Jeedom/naturalLight · GitHub)
Je pense qu’il faudrait mettre à jour les min et max value en fonction des valeurs de l’ampoule lors du premier enregistrement, et à chaque refresh ne le changer que s’il n’est pas défini.
Oui, c’est une très bonne idée.
Merci pour cette remarque constructive
Je suis partie sur l’unité mired (que je ne connaissais pas non plus avant).
J’ai une remontée de bug avec le plugin Ikea qui semble est en % (0 à 100)
Il faudra que je reprenne l’unité de l’équipement d’origine.
Idéalement, il faudrait je pense utiliser le Kelvin qui est il me semble l’unité la plus universelle, et pour chaque équipement, au niveau des options, ajouter deux champs qu’il faudra remplir correspondant aux équivalents en kelvin des limites hautes et basse de l’équipement source.
Je ne sais pas si j’ai été clair
Je comprends que tu préfères l’unité K, car plus parlante.
Mais cela va peut-être faire usine à gaz.
Après, si je rajoute ce que tu proposes, cela te concernera
Ta formule basée sur l’heure ne me convient pas du tout : la lumière blanche après fermeture des volets était très agressive.
La formule de base est parfaite à mon sens, la lumière correspondait parfaitement à la lumière de l’extérieur au fur et à mesure que le soleil baissait
au moment où le soleil se baisse rapidement, 5 minutes entre 2 changements de couleur c’est trop, le changement est trop brusque. Il faudrait pouvoir choisir la fréquence de rafraichissement. cf ci-dessous.
Il manque un champs ‹ condition › afin de ne pas modifier la température de couleur si la condition est remplie. En effet, j’ai des ampoules de couleur qui si elles sont allumées en vert par exemple, vont se remettre en blanc à chaque fois que le cron du plugin s’execute.
Mes propositions pour le second point : un paramètre cron au niveau de la configuration du plugin (pas d’intérêt au niveau équipement, le calcul de température de couleur est fonction du soleil donc est toujours le même pour tous les équipements).
Pour le 3ème point, la condition est une configuration sur l’équipement.
public static function cron() {
$autorefresh = $this->getConfiguration('autorefresh', '*/5 * * * *');
try {
$c = new Cron\CronExpression(checkAndFixCron($autorefresh), new Cron\FieldFactory);
if ($c->isDue()) {
// calcul de la température de couleur une fois : pas d'intérêt de le recalculer à chaque équipements
$colorTemp = self::computeColorTemp();
foreach (eqLogic::byType('naturallight', true) as $eqLogic) {
if ($eqLogic->getIsEnable() == 1) {
$condition = jeedom::evaluateExpression($eqLogic->getConfiguration('condition', '1'));
if ($condition) {
$eqLogic->computeLamp($colorTemp );
}
}
}
}
} catch (Exception $exc) {
log::add('autorefresh', 'error', __('Expression cron non valide', __FILE__) . ' : ' . $autorefresh);
}
}
D’un point de vue performance, il est aussi inutile de recalculer la température de couleur à l’extinction de l’ampoule.
Il faudrai aussi vérifier la condition au moment du listener.
La fonction computeLamp() prend la température de couleur en paramètre pour ne pas avoir à la recalculer systématiquement.
Salut,
Merci pour ces remarques.
OK pour la formule d’origine alors. Perso, je la trouvais trop jaune alors qu’il n’était que 18H. Mais à tester.
Je revois le code actuellement pour faire des sous-fonctions, et voir si je peux prendre en compte la remarque concernant l’initialisation du minValue et maxValue. Je galère un peu pour le moment.
Le Cron5 fait des sauts désagréables, je l’ai constaté aussi.
Le calcul pour chaque ampoule : je me suis dit que le min et le max n’étant pas le même, il fallait le prendre en compte.
Mais effectivement, il y a une partie des calculs qui sont communs.
J’aime bien ta proposition : donc un cron global, un calcul global pour les choses en commun, puis un parcours sur chaque équipement…
La liste des choses à faire s’allonge, mais c’est bon signe
Je note tout ça.
Je ne suis pas fan non plus de ta correction d’altitude que tu fait dans la dernière beta : en effet, la température de la lumière extérieure est conditionnée par les couches d’atmosphère que doit traverser la lumière du soleil (au minimum quand le soleil est à 90° et au maximum quand il est juste au dessus de 0°). Refaire une proportion comme tu le fais dans la beta fausse complètement le calcul…
Je comprends. J’avais testé sans cette correction, et j’avais tout de même une lumière bien trop jaune-rouge toute la journée, du fait qu’on soit en hiver.
Tu as testé sans cette partie ?
Oui, et moi j’ai une lumière bien blanche la journée. La lumière commence à jaunir le soir, quand le soleil passe sous les 10° environ. Mais ça devient vraiment blanc chaud sous les 5°.
Salut,
Je viens de livrer une version BETA avec la refactorisation et le debug le plus simple :
Refactorisation du code
DEBUG : Retour sur la formule d’origine
DEBUG : Gérer min = 0
DEBUG : Prendre la formule d’origine plutôt que celle des heures : trop blanc
DEBUG : Suppression de la correction altitude
DEBUG : Cron au lieu de Cron5
J’ai créé un fichier TODO.txt pour lister ce qu’il reste à faire, et je mets à jour le fichier Changelog.
Dis-moi si cela corrige le problème de couleur que tu as constaté.
Question : tu proposes une condition pour ne pas mettre à jour la couleur, car déjà personnalisé.
C’est une bonne idée. Je vais rajouter un champ personnalisable. Tu mettrais quoi de ton côté comme condition ?
Sur mon ampoule couleur, j’ai une info « color_mode » qui est à 1 si on elle en mode couleur et à 2 si elle est en mode blanc quelle que soit la température.
Je mettrait donc comme condition « color_mode != 1 »
J’ai créé un fil d’Actualité afin de mettre le changelog ici :
J’ai modifié selon tes propositions :
– Paramétrage de valeurs min et max de la température couleur
Les valeurs par défaut sont récupérées du paramétrage de la lampe
La mise à jour est effectuée lors de l’enregistrement de l’équipement
– Gestion d’une condition pour modifier ou non la température de l’ampoule
Pour les valeurs min/max : en enregistrant l’équipement, tu verras les valeurs récupérées de la lampe. Elles sont modifiables.
Il n’y a pas de contrôle de cohérence pour le moment, je verrai plus tard (mis dans le TODO.txt)
Pour la condition : Je n’ai pas de condition d’utilisation chez moi exploitable, car la couleur varie et je n’ai pas le tag « color_mode ».
J’ai modifié le code de manière à faire les calculs si l’historisation est activée, car je trouve ça joli, mais pas utile en production.
A tester et à debuguer, avant que je vois ce que je peux faire par la suite.
Ampoule Ikea couleur avec le plugin officiel zigbee.
Le color_mode est pas présent par défaut. Je l’ai ajouté avec la commande 1::768::8
Je ne sais pas comment fonctionne le plugin zigbeelinker, mais d’après ce que j’ai lu il est très configurable donc je ne doute pas que tu puisse aussi récupérer cette info
