oui tout cycle avec une coupure comme fenetre ouverte, overpower etc est ignoré.
Tout cycle interrompu de toute façon n’est pas pris en compte
2 « J'aime »
C’est peut-être overkill mais quid de tenir compte
- de l’ensoleillement
Si les volets sont ouverts, le soleil peut très bien aider au chauffage de la pièce même si le chauffage seul galère, c’est le principe d’une véranda !
- du nombre de personne dans la pièce
4 personnes ca fait 4x80 = 320w soit une part significative de certains radiateurs électriques
- des conso électriques de la pièce
Si le four ou un ordinateur gamer fonctionne ca peut largement contribuer au chauffage…
Au passage ne pas en tenir compte ralentit l’apprentissage non?
Pour une v2 ? 
Merci pour cette feature en tout cas qui s’annonce super!
Jeedom a un paramètre offset qui est ajouté à la formule de regulation.
Il est paramètrable dynamiquement. Du coup on peut moduler l’offset avec une automation en fonction des paramètres que tu évoques ( nombre de personne, source de chaleur externe, appareils en fonctionnement dans la pièce , etc )
Ca touche à l’algo TPI mais ca serait une bonne chose de l’ajouter oui. @Jean-Marc_Collin
Power = (direction × ΔT_int × Coeff_int) + (direction × ΔT_ext × Coeff_ext) + Offset
Et ca casse rien 
Si on le rajoute dans la formule, on peut aussi l’intégrer dans l’algo d’apprentissage mais ca ne sert à rien sans.
1 « J'aime »
Oui je bidouille l’offset de chaque pièce toutes les 15 minutes pour tenir compte de tout ça 
Mais c’est des scénarios et donc très artisanal
Je me demandais à quoi il servait dans ta formule initiale. J’ai donc compris. Je l’avais dans les toutes premières versions mais si il est statique il fausse les calculs et ça marchait mieux sans. Si tu penses que tu peux le faire varier dynamiquement et que ça peut aider → go.
1 « J'aime »
je te ferais un pr pour ça.
1 « J'aime »
Hello.
Je pense tenir quelque chose qui commence à tenir la route.
Les températures élevées m’empêche un peu de faire des tests réalistes.
Il me faudrait quelques courageux pour tester dans d’autres conditions, avant de lancer un vrai beta test.
Plutôt des profils un peu tech à l’aise avec HA et surtout VT pour ne pas à avoir à faire du support technique pour l’instant.
Hello
Est ce que ça peut s installer a côté du VTherm legacy ? J ai une pièce qui peut servir de test sans impacter les autres personnes du logement 
1 « J'aime »
Non mais si l’autotpi est desactivé sur les autres thermostats il n’y a aucun risque. Le fonctionnement reste legacy.
La branche est maintenue à jours quotidiennement avec les derniers commit.
Je suis le mec chiant 
La configuration est conservée ? Conservable en cas de bascule ?
Et réciproquement, si un besoin de rollback sur le legacy ?
Oui ça ne touche à rien de l’existant dans la conf.
Je passe régulièrement d’une version à l’autre depuis que je teste.
Je ferais un document pour expliquer simplement comment ça fonctionne et surtout les bonnes conditions à avoir pour un bon apprentissage.
Je mettrais à dispo une archive/branche de test.
Suffit d’ecraser les fichiers dans le répertoire custom_components/versatile_thermostat ( en sftp ou autre )
Pour rollback en legacy depuis hacs télécharger la dernière version
Ne pas tester ce qui est sur mon git dans la branche de dev je fais bcp de changements et rollback au cours de mes tests.
1 « J'aime »
@Jean-Marc_Collin voilà ce que j’ai fait pour l’options_flow:
C’est découpé en plusieurs écrans, conditionnés par rapport à ce qui est selectionné à l’étape précédente.
Si t’as des remarques.
Sinon je pense avoir reglé la plupart des soucis que j’ai rencontré.
Dernier apprentissage lancé ce matin, on va voir, mais j’ai bien Ki et Ke qui sont capables de redescendre, c’était mon principal problème. Erreur de logique.
Bon il fait 16° dehors, c’est pas ouf pour tester.
3 « J'aime »
Hello @KipK ,
Génial tout ça !
Sur l’aspect configuration, j’ai l’impression qu’il y a beaucoup de profondeur qu’on pourrait remettre à plat :
-
- Attributs TPI (check « Activer » l’apprentissage auto TPI")
-
- Paramètres généraux de l’apprentissage Auto TPI,
-
- Auto TPI Puissance
-
- Auto TPI Méthode
-
- Auto TPI moyenne
Y a plein de soucis avec ce mode « tunnel » qui à l’usage n’est vraiment pas pratique :
- on ne peut pas revenir en arrière. Y a pas de back. Si je suis à 4. et que je veux revenir à 2. je tout recommencer,
- pour changer une valeur je dois me retaper tout le tunnel,
- impossible de stopper le tunnel au milieu.
Bref, j’avais pris cette méthode dans les premières versions mais j’en suis revenu pour avoir un menu à plat qui permet de configurer que ce que j’ai besoin de configurer.
Si il y a 2 niveaux ca va, mais 5 niveaux je pense que c’est rédhibitoire.
3. 4. et 5. pourrait très bien se mettre sur une seule page et avoir une nouvelle entrée dans le menu général « Auto TPI » pour rentrer sur la page 2. si le check « Activer » l’apprentissage auto TPI" est coché.
Je fais ça souvent, c’est bien dans l’esprit et ça pose pas de questions. On aurait donc:
Menu général:
- TPI,
- Auto TPI si coche « Activer auto TPI »,
- arrivée sur la page 2,
- arrivée sur la page 3 mutualisée.
- arrivée sur la page 2,
- Finaliser les modifications ne s’affiche que si coche et Auto TPI configuré sinon « Configuration incomplète » comme maintenant.
Regarde pour l’auto-regulation par vannes c’est exactement comme ça que ça se passe :
T’aurais du me demander avant d’avoir tout fait. Ca fait du rework.
@Jean-Marc_Collin Disons que c’est la methode recommandée par HA.
J’avais commencé par tout mettre sur un ecran, mais comme il y a pas mal de paramètres conditionnés, ca faisait vraiment très lourd et pas clair pour les utilisateurs.
La ca les accompagne en douceur et permet d’avoir de la place pour ajouter des descriptions.
On ne peut pas faire de formulaires dynamiquies avec le config_flow du type si telle case est cochée, fait apparaitre tel ou tel champs. On ne peut que faire du step par step ( ils nous forcent un peu la main sur ca )
Par contre je peux séparer auto tpi de TPI ( c’est ce que j’avais fait au départ ) , en rajoutant une entrée au menu ?
2 « J'aime »
@Jean-Marc_Collin pour que tu ai un peu plus de visibilité ca donne ca les conditions:
Premier ecran auto-tpi, en plus des paramètres généraux auto tpi, case à cocher en bas pour utiliser “Capacité Auto” , si cochée il y a l’écran capacités manuelles, sinon on passe directement au suivant.
Cet ecran suivant propose 2 types de calculs Auto TPi ( Average et EMA )
Selon ce qui est selectionné ici, l’écran d’après est différents.
Average:
- poid initial
EMA:
- paramètre alpha
- taux de décroissance
Il y a surement d’autres paramètres qui vont venir s’ajouter.
Si on met tout sur le meme écran, il faut bien expliquer que tel ou tel param est pour tel ou tel calcul, et ca commence à être vite confu. Pire encore sur mobile.
Edit: je suis en train de faire un gros refactoring, suite à cette “découverte” aujourd’hui.
Ca va retirer l’étape capacités manuelles du config_flow autotpi
Oui c’est très contraint. C’est censé resté simple la conf et là on pousse le bouchon très loin.
Yes ! Et regroupe peut être 3 et 4. Y a 2 champs par écran pour faire un compromis. Je te laisse juge.
Ce se disperse un peu entre le github, hacf, … Ca va vite devenir compliqué à suivre. Je propose de rester là. Votre avis ?
Il vaut mieux garder la séparation entre les 2 méthodes.
- La première sert pour un premier apprentissage si on n’a pas d’historique ( cas des install récentes ) , c’est la méthode jeedom un peu brutale et qui prend un moment avant d’arriver sur de bons coeff.
-. La deuxieme méthode est pour ceux qui ont déjà une historique avec leur thermostats. Ca va calculer le heat_rate max du radiateur, et au passage estimer Kint et Kext. Puis lancer un fine tune avec un apprentissage doux.
Les paramètres n’ont rien à voir entre les 2 méthodes, si on mélange ca va cafouillax.
Mais on saute déjà une étape avant.
Ce se disperse un peu entre le github, hacf, … Ca va vite devenir compliqué à suivre. Je propose de rester là. Votre avis ?
Rien que le topic est dispersé. Faut que je refasse le premier message qui n’a plus rien à voir. Mais oui c’est ici qu’on rassemble tout.
1 « J'aime »
@Gael1980 , je suis sur la documentation là. J’essaye de proposer des paramètres par défaut corrects selon les cas.
Dis moi si t’es d’accord avec moi là dessus concernant les recommendations à la fin:
Méthode de calcul EMA Adaptatif
La méthode EMA (Exponential Moving Average) utilise un coefficient alpha qui détermine
l’influence de chaque nouveau cycle sur les coefficients appris.
Comportement
Au fil des cycles, alpha décroît progressivement pour stabiliser l’apprentissage :
| Cycles | Alpha (avec α₀=0.2, k=0.1) | Influence du nouveau cycle |
|---|---|---|
| 0 | 0.20 | 20% |
| 10 | 0.10 | 10% |
| 50 | 0.033 | 3.3% |
| 100 | 0.018 | 1.8% |
Paramètres
| Paramètre | Description | Défaut |
|---|---|---|
Alpha initial (ema_alpha) |
Influence au démarrage | 0.2 (20%) |
Taux de décroissance (ema_decay_rate) |
Vitesse de stabilisation | 0.1 |
Formule
alpha(n) = alpha_initial / (1 + decay_rate × n)
Où n est le nombre de cycles d’apprentissage.
Cas particuliers
-
decay_rate = 0 : Alpha reste fixe (comportement EMA classique)
-
decay_rate = 1, alpha = 1 : Équivalent à la méthode « Moyenne Pondérée » ( méthode Jeedom )
Recommandations
| Situation | Alpha (ema_alpha) |
Taux de Décroissance (ema_decay_rate) |
|---|---|---|
| Apprentissage initial | 0.15 |
0.08 |
| Apprentissage fin | 0.08 |
0.12 |
| Apprentissage continu | 0.05 |
0.02 |
Explications:
-
Apprentissage initial:
Alpha: 0.15 (15% de poids initial)
- Cycle 1: α = 0.15 (forte réactivité initiale)
- Cycle 10: α = 0.083 (commence à stabiliser)
- Cycle 25: α = 0.050 (filtrage accru)
- Cycle 50: α = 0.036 (robustesse finale)
Taux de décroissance: 0.08
Décroissance modérée permettant une adaptation rapide aux 10 premiers cycles
Balance optimale entre vitesse (éviter stagnation) et stabilité (éviter sur-ajustement) -
Apprentissage fin
Alpha: 0.08 (8% de poids initial)
Démarrage conservateur (coefficients déjà bons)
Évite les sur-corrections brutales- Cycle 1 : α = 0.08
- Cycle 25 : α = 0.024
- Cycle 50 : α = 0.013
Taux de décroissance:: 0.12
Décroissance plus rapide que l’apprentissage initial
Converge vers un filtrage très fort (stabilité)
Adaptation majoritaire dans les 15 premiers cycles -
Apprentissage continu
Alpha = 0.05 (5% de poids initial)
Très conservateur pour éviter dérive
Réactivité modérée aux changements graduels- Cycle 1 : α = 0.05
- Cycle 50 : α = 0.025
- Cycle 100 : α = 0.017
- Cycle 200 : α = 0.011
Taux de décroissance: = 0.02
Décroissance très lente (apprentissage à long terme)
Maintient une capacité d’adaptation même après des centaines de cycles
Adapté aux variations saisonnières (hiver/été)
Edit: Sachant que pour le cas de l’apprentissage continu, je garde volontairement un taux de décroissance pour éviter le bruit.
Mais j’ai intégré un boost de alpha temporaire en cas de changement systèmique.
Un peu comme ça dans la classe auto_tpi_manager:
def _detect_regime_change(self, recent_errors: list) -> bool:
"""
Détecte un changement de régime thermique (modification permanente).
Si détecté, on peut temporairement augmenter α.
"""
if len(recent_errors) < 10:
return False
# Test statistique simple :
# Les 10 dernières erreurs ont-elles un biais systématique ?
mean_error = sum(recent_errors) / len(recent_errors)
std_error = (sum((e - mean_error)**2 for e in recent_errors) / len(recent_errors))**0.5
# Test t de Student : erreur systématique significative ?
t_stat = abs(mean_error) / (std_error / len(recent_errors)**0.5)
# Seuil à 95% de confiance (t > 1.96 pour n=10)
return t_stat > 2.0
def _get_adaptive_alpha(self, cycle_count: int) -> float:
"""Calculate adaptive alpha with regime change detection."""
# Calcul standard
base_alpha = self._ema_alpha / (1 + self._ema_decay_rate * cycle_count)
# Si changement de régime détecté, boost temporaire
if self._continuous_learning and self._regime_change_detected:
boost_alpha = min(base_alpha * 3.0, 0.15) # Max 15%
_LOGGER.info(f"Regime change detected, boosting alpha: {base_alpha:.3f} → {boost_alpha:.3f}")
return boost_alpha
return base_alpha
Ton avis là dessus aussi ?
Je regarde précisément demain, mais je trouve ta proposition très cohérente d’une 1re lecture rapide.
Mais je préfère lire à tête reposée avant de te répondre
1 « J'aime »
@Jean-Marc_Collin Je viens de terminer la documentation.
Elle est ici: versatile_thermostat/documentation/fr/feature-autotpi.md at jeemostat · KipK/versatile_thermostat · GitHub
J’ai essayé de pas faire indigeste. Exercice difficile vu le sujet
Quelques avis exterieurs seront appreciés
2 « J'aime »