@Gael1980 t’es pas sur la bonne branche. Il n’y a pas de minize sur la version itérative.
La branche c’est « Jeemostat »
Je reprendrais l’autre branche quand jeemostat fonctionnera bien, et qu’on pourra comparer les resultats entre les 2 approches.
1 « J'aime »
ça marche, j’ai pris le lien tout en haut
le topic est completement pété. Y a trop de sujets en meme temps 
C’est pour ça que j’ai mis la doc technique de mon implementation jeemostat ici :
edit: cela dit j’ai changé pas mal de choses de la version jeedom.
J’ai viré la pondération qui diminue par cycle ( pour le moment ) , je teste quelque chose de plus doux au départ. Je regarde comment ça se comporte là, je rajouterais surement apres la ponderation au bout de X cycles.
edit 2: ca me coute un bras en chauffage ces tests oO
1 « J'aime »
Je ne l’ai pas vu dans la doc, je ne sais pas si tu fais un test si la température est stable sur plusieurs cycles (tu restes longtemps sur du 20-30% de power), tu peux estimer l’écart résiduel du coup ajuster ton offset?
1 « J'aime »
A l’origine, l’algo utilise une moyenne pondérée pour le poid des nouveaux coeffs a chaque cycle:
coeff_final = (coeff_actuel × nb_apprentissages + coeff_nouveau) / (nb_apprentissages + 1)
j’ai retiré ça temporairement pendant que je teste un EMA à la place:
avg_coeff = (old_coeff * 0.8) + (coeff_new * 0.2)
Sauf que j’ai scripté la génération de cette doc pour que Gemini la mette à jours à chaque commit.
1 « J'aime »
Je sais pas si c’est ça que tu entendais, mais ca se passe comme ça à peu près
l’algo ne calcule que Kint pendant la montée en température jusqu’à la consigne.
Comme ça stabilise vers la consigne, et qu’il y a de moins en moins de variations de temperature, il ajuste Kext pour se rapprocher du point de consigne.
Si ca overshoot il ajuste Kint
Si l’écart est très faible, c’est le tour de Kext
Et ca fait ca 50 cycles par coeff.
Oui oui, c’est à cela que je pensais.
Je vais rendre configurable le choix d’utiliser l’ema ( et la rendre paramètrable ) ou la ponderation qui baisse avec le nombre de cycle ( et pouvoir regler le poid du premier cycle validé ) .
Pour ajuster des coeffs deja dans les clous, l’ema sera surement plus adaptée.
Voila, maintenant il y a le choix des 2 types de calculs , average ou ema.
L’idée de l’ema, c’est surtout pour l’apprentissage continu. On peut paramètrer l’alpha de l’ema ( par défaut 20% )
Je voudrais tester de l’utiliser aussi pour l’apprentissage en 50 cycles, avec une ponderation qui diminue par cycle comme pour l’average.
@Gael1980, vu que l’ema est bcp plus lente, à ton avis quelle serait la meilleure formule pour faire baisser le poid de l’ema avec les cycles de manière bcp plus douce que ce qu’on fait avec l’average. J’imagine faire baisser alpha progrssivement, mais quels paliers ?
1 « J'aime »
De mon point de vue, l’EMA reste avant tout un filtre de lissage.
Ce que tu cherches à faire, si je comprends bien, ce n’est pas seulement lisser, mais surtout réduire progressivement l’influence de l’historique au fil des cycles, un peu comme une notion de demi-vie appliquée à l’apprentissage.
Dans ce cas, oui, faire décroître alpha progressivement me semble la bonne approche. En revanche, plutôt que des paliers fixes, je verrais plutôt :
- soit une décroissance exponentielle de alpha en fonction du nombre de cycles,
- soit une loi du type alpha(n) = alpha0 / (1 + k·n) pour avoir une baisse douce et continue.
Les paliers en dur risquent d’introduire des ruptures artificielles dans l’apprentissage.
1 « J'aime »
C’est exactement le type de réponse que j’attendais merci 
1 « J'aime »
De rien, si cela t’aide
Je rajoute à l’algo d’apprentissage la notion de heating/cooling factor.
En phase de chauffe/clim normale ( pas seulement en phase d’apprentissage ) l’auto tpi profites des cycles à 100% pour calculer le heating/cooling rate du radiateur/clim dans la pièce ( default à 0.1° )
Ca apparait maintenant dans le climate comme attribut max_capacity_heat et max_capacity_cool et dans l’entité auto_tpi_states
L’auto_pid se sert de ces valeurs dans le calcul de l’estimation vs realité.
On peut aussi les paramètrer soit même.
L’algo jeedom compare la valeur de consigne à ce qu’on a obtenu en fin de cycle. C’est complètement con, si il y a une consigne 2° superieure, c’est physiquement inateignable en un cycle ( 20mn chez moi ) . Et ca force un Kint beaucoup trop elevé.
Du coup maintenant il estime combien on aurait du gagner en 1 cycle connaissant la capacité du radiateur, et compare ça.
C’est détaillé là y reste plus grand chose de l’algo jeedom va falloir que je renomme la branche
Hello,
Je vois que ça avance bien. C’est cool. Pour l’intégration dans Vtherm, je vois bien une nouvelle option ici (écran de config des entités liées en over_switch / over_valve) :
J’avais prévu à l’époque d’avoir le choix dans les algos. Jusque là le TPI à toujours suffit mais je crois que c’est l’occasion d’avoir un nouveau choix : « Auto- TPI (experimental) ».
Il faut certainement garder les coef du TPI comme valeurs initiales de vos algos. C’est vous qui savez si y en a besoin.
J’ai lu le gist Auto_TPI: version itérative · GitHub et j’ai qqes remarques :
- les cycles s’enchainent sur Vtherm. La fin du cycle précédent déclenche immédiatement un nouveau cycle. Par cycle, j’entends : temps de chauffe - temps de repos. Ou temps de chauffe est
on_percent * cycle_minet temp de repos est(1 - on_percent) * cycle_min.
Donc, je l’ai déjà dit dans les commentaires des PR, mais détecter une fin de cycle ou un démarrage c’est pareil et ce sera en même temps. - Un cycle peut s’arrêter (passage sur off par exemple) et dans ce cas, la méthode cancel_cycle permet de le savoir.
- Lors d’une modification de la température de la pièce, le calcul des nouveaux on_percent / off_percent est immédiat mais ils ne seront appliqués qu’un prochain cycle. On finit toujours un cycle en cours avant de le changer.
- Si plusieurs switch sont sur le même VTherm, les cycles sont décalés pour lisser un maximum la puissance consommée. Ils ont tous la même durée mais ils sont décalés. Chaque underlying prend en entrée dans le start_cycle la valeur de son décalage. Ca donne ça :
A vous de voir si tous ces éléments sont maitrisés ou vont poser des soucis sur l’algo auto-TPI.
1 « J'aime »
Est-ce que vous pensez être proche du but ou je démarre un nouveau cycle de dev sur qqes évols attendues ? Objectif fin d’année pour moi.
On approche du bout oui. Enfin je pense.
Après, vu la feature, on va avoir besoin d’une bonne dose de beta test avec des configs variées. Noël c’est un peu proche.
Je teste chez moi avec des convecteurs un peu sous dimensionnés, c’est pas ouf comme contexte.
Va falloir voir comment ça se comporte avec tous les autres types.
J’ai besoin de me faire challenger l’algo. Faut vérifier les maths derrière, il y a sûrement des coquilles.
Par ex, je continue de calculer Kext après un dépassement de consigne, est ce une bonne idée ?
( Au départ je pensais que c’était nécessaire pour réagir aux overshoots , je commence à douter )
D’autant qu’en cas de baisse de consigne, ça vient parasiter le calcul.
Clairement te bloque pas @Jean-Marc_Collin si tu dois avancer sur autre chose.
Y a encore un peu de taf, la doc à faire, le config flow a revoir, les trads, .
J’avais prévu à l’époque d’avoir le choix dans les algos. Jusque là le TPI à toujours suffit mais je crois que c’est l’occasion d’avoir un nouveau choix : « Auto- TPI (experimental) ».
l’auto tpi utilise TPI. C’est une couche en plus qui ne touche pas à la régulation. Pas sûr que ce soit le meilleur emplacement.
1 « J'aime »
Tu le vois comme une option séparée ? Typiquement une case à cocher à coté de TPI « auto-tpi (experimental) ».
Le mieux pour avoir des retours, c’est de le publier en mode expérimental dans une version beta. Il faut que tu puisses accéder à toutes les infos via log ou fichiers séparés. Là, tu auras plein d’utilisateurs dans des contextes différents. C’est clairement du boulot de répondre à tout le monde mais ça marche pas mal. Je fais ça tout le temps en fait sur les grosses modifs et tu as toujours 5 ou 6 personnes qui sont intéressées.
Bon, je continue sur ma roadmap et dès que tu as qqe-chose qui tient la route on fait une beta (ou une alpha). Si c’est facile à débrayer, ca ne doit pas poser de soucis.
2 « J'aime »
J’ai lancé un apprentissage ce matin avec la dernière version.
Ca prend quelques jours pour se terminer, c’est le tout début, mais déjà je vois enfin un comportement normal
Pour l’instant ca n’a pas encore calculé trop de Ki, vu que ca ignore les cycles à 100% de puissance.
Mais cette phase à 100% sert à calculer le max heating rate ( max_capacity_heat ) .
Dans l’example ici, j’utilise le max heating rate comme reference pour la montée en température à 100%. Il est ajusté en temps reel au fur et à mesure des cycles ( quand un cycle à 100% est passé ) . Ca va donc forcément calculer des Ki plus elevé pour avoir la montée en température la plus rapide.
Ce n’est pas forcément ce qu’on cherche sur les usages.
Il est possible de paramètrer soit meme le heating/cooling rate pour le mettre en dessous du max capacity, ce qui amenera vers un Ki plus light.
En gros plus on baisse le heating rate, plus la montée en température sera douce dans les coeff calculés.
Il n’y a pas de coeff parfaits, tout dépend des usages et de l’intention.
Tu le vois comme une option séparée ? Typiquement une case à cocher à coté de TPI « auto-tpi (experimental) ».
Pour l’instant j’ai créé une rubrique auto tpi sous tpi dans le menu de la conf. C’est temporaire.
Pour simplifier l’écran et pas avoir 40 parametres dans la meme page, j’imagine utiliser le step by step du config_flow et l’intégrer dans la conf TPI. Si auto tpi coché, ecran étape suivante: choix du type d’auto tpi, puis options liés à ce type.
1 « J'aime »
Je répond à tes remarques au dessus ( tu peux aussi commenter directement sur le document )
Pour info ce doc est mis à jours à chaque commit par un agent IA.
Il peut se glisser des erreurs. Mais dans l’ensemble il représente l’état actuel du code.
1/ C’est comme ça que ca fonctionne oui. Le callback envoie le top départ d’un cycle à auto tpi.
Quand un autre cycle démarre, auto tpi vérifie que le temps passé sur le cycle correspond bien au temps configuré par cycle dans versatile ( à quelques % prets )
Si ca ne correspond pas, il ne tient pas compte de ce cycle pour les calculs.
2/ du coup c’est géré, cf au dessus. Pas le bon temps de cycle, niet.
3/ parfait enfin non pas parfait du tout j’ai trouvé un gros bug, merci
4/ Ca ne devrait rien changer sur l’algo. A vérifier qd meme.
edit: Je viens d’ajouter ça, qui devrait résoudre le soucis de baisse de Kext pendant les phases de refroidissement.
1 « J'aime »
As tu pensé à gérer la fenetre ouverte ?
dint/dt tres négatif. → gelé l’apprentissage
vth lui coupe naturellement le chauffage