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
Quel intérêt d’afficher les valeur par défaut ? Je pense que ça alourdi l’interface pour rien (si on veux le connaitre, il suffit de regarder la définition de l’ampoule)
pourquoi avoir mis les valeurs min/max dans l’onglet Lumières ? La notion est déjà présente dans l’onglet commande → cette duplication est perturbante, d’autant plus que les deux ne sont pas liés et que du coup celui de l’onglet commande devient inutile. Je pense qu’il faudrait garder un fonctionnement homogène avec Jeedom c’est à dire les valeurs présente dans l’onglet commande.
La condition est elle une condition d’exécution ou une condition de non exécution ? → il faudrait l’indiquer sur la page.
Je teste aujourd’hui la condition et je te tiens au courant.
je n’ai pas réussi à modifier la valeur minValue et maxValue de ma commande facilement.
Cmd->setConfiguration est obscure à mon goût.
l’emplacement sur la page principale me paraît plus intuitif pour l’utilisateur.
Jusque là, j’avais réussis à initialiser les valeurs sur la commande, mais je n’y arrive plus et encore moins à la modifier.
Je ne m’en servais pas non plus d’ailleurs, en me basant sur la commande de la lampe.
Pour la condition, oui c’est obscure, je vais rajouter une explication/aide.
Je viens de livrer une version Beta qui ajoute un tooltip pour la condition.
A noter que j’ai eu une demande pour gérer le plugin Ikea qui est en pourcentage.
J’ai eu une proposition aussi pour gérer le Kelvin - je ne sais pas quel plugin gère comme ça, mais c’est fait.
La condition fonctionne mais le bouton de sélection de commande info ne permet de sélectionner que des commandes binaires… Donc pour une formule plus complexe, il faut écrire le nom de la commande à la main. Mais ça fonctionne.
