J’avoue que je ne comprends pas : s’il n’y a aucune convention, à quel moment on dit à jeedom quelle méthode il doit appeler pour ce mi-cron / mi-démon soit réellement déclenché ? (j’allais dire mi-ange mi-démon 
)
Salut tous,
@mika, je pense que je fait pas tout a fait la même chose, en tout cas pas de la même façon. ton plugin à l’air bien plus avancé sur toute la définition des transition entre les couleurs au vu des screenshot !
Je fais un truc qui est le moins bancale possible et qui exploite le plugin colortransition.
J’ai regardé coté démon, mais comme je ne souhaite que démarrer le script à la demande,
la solution que j’ai implémenté :
une boucle (aka moteur) dans un script php que je lance en background à la demande à l’aide d’un :
$command = '/usr/bin/php '.__DIR__.'/../../ressources/CT_motor_tick.php '.$cta_tr['dur_interval'].' '.$maxTime; // avec qques variables
$output = shell_exec($command.' >/dev/null &');// lancement en bg
avec les bons unset j’arrive à ne pas avoir de fuite de mémoire, et avec un timing raisonnable pas trop de cpu non plus.
j’exploite un bout de mémoire que je réserve avec les objets qui vont bien à l’aide de
shm_attach / shm_put_var / shm_get_var
que je met en place et supprime au besoin.
J’ai testé le usleep, mais avec mes wled j’ai du mal à voir si je passe sous la seconde.
si ça intéresse, dispo sur le git : https://github.com/Bbillyben/ColorTransition_actuator
Je ne suis pas sur que ce soit super bonne pratique codage jeedom, mais ça tourne plutôt bien, j’ai fait tourner 4 instance en // avec des timings différents sans noter de pb.
Le seul pb ce sont les approximations sur les fractions dans les calculs. j’ai mis des round à 10-3 pour limiter mais c’est vraiment une rustine.
Je n’ai pas réussi à mettre en défaut la gestion de la boucle, le script fini toujours par sortir des processus en cours.
Par prudence, j’ai mis un cron pour tester si existence et si il tourne depuis lgtemps pour le killer au besoin.