Ecoute, je n’en sais rien. Avec une clim réversible on ne fait pas de TPI qui exclusivement en over_climate.
J’ai bien quelques utilisateur qui font de l’over_switch en mode clim mais c’est rare et je connais pas leur coefs.
Après personne ne s’est plaint mais ca ne veut rien dire.
1 « J'aime »
Je vous adore, vous etes des oufs 
Presque autant de moi on dirait !
3 « J'aime »
>Dans l’idée à termes si ca fonctionne, tu vois ça directement dans VTherm ou comme une extension autonome ?
Je t’avoue que pour l’instant je fais ça directement depuis versatile à modifier à ma guise pour tester différents algos rapidement. Selon les modifications, tu me diras si ca rentre dans le package, mais si ça part en laboratoire du CERN, vaut peut etre mieux externaliser ça.
L’idée c’était de faire “simple” au départ, c’est un peu partit en c..et ça s’arrange pas avec @Gael1980 ^^
Je peux fournir un service de mise à jour des coef qui peut être appelé depuis l’extérieur sans trop de soucis.
Ca peut être pratique oui, pour l’instant t’as assez de sav à faire avec la v8 
Y a un autre projet qui permet de prévoir les changements de preset à l’avance pour que la pièce soit à température à l’heure dite. Ca utilise aussi des modèles prédictifs. Je me demande si il n’y a pas du rapprochement à faire.
Je surveille oui. Il y a de très bonnes idées aussi.
Je me demande si tout ce qu’on fait là n’est pas over-enginered qd même.
Ca serait bien de pouvoir comparer avec les algos du thermostat jeedom pour avoir une base de référence d’une methode simple qui fonctionne déjà très bien depuis des années.
Je pourrais assez rapidement intégrer ça à VT, j’ai déjà documenté l’équivalent quelque part.
Ca peut être léger et non intrusif.
Puis voir après si on peut faire mieux avec la modélisation.
Pour l’instant mes résultats avec le modèle sont assez hazardeux. J’ai 2 pièces où il m’a trouvé des coeffs realistes assez proches de ce que j’ai. Les autres il considère que les modèles d’apprentissages sont insuffisants. J’ai pas assez de variance vu que c’est déjà correctement stabilisé. Il faudrait forcer des cycles froid chaud avec des coeff assez fort pour avoir de bonnes données.
Avec le script de @Gael1980 ( impressionnant d’ailleurs jusqu’où tu es allé dans les rapports ), il me sort des coeff carrements laxistes ( très bien argumentés, j’ai adoré cette partie là ).
Mais les données que j’ai remontent à moins d’une semaine et ne sont pas exemplaires.
──────────────────────────────────────────────────────────────
╭ 
Résultat optimal – climate.thermostat_chambre_verte – 2025-11-26 17:02 ╮
│ │
│ Algorithme : Nelder → méthode locale sans gradient │
│ │
│ Coefficients TPI - maths + (clip) : │
│ coef_int = 0.100 → inertie du bâtiment (réactivité intérieure) │
│ coef_ext = 0.035 → pertes thermiques (sensibilité extérieure) │
│ │
│ Coefficients TPI — XgBoost +(clip) : │
│ coef_int = 0.100 │
│ coef_ext = 0.032 │
│ │
│ Erreurs de modélisation : │
│ MSE (train / val) = 0.020671 / 0.026238 │
│ RMSE (train / val) = 0.143774 / 0.161981 │
│ │
│ Validation croisée : │
│ Précision ON/OFF = 98.7% → cycles correctement reproduits │
│ Overshoot moyen = 0.044 °C → dépassement typique de la consigne │
│ │
│ Lecture rapide : │
│ - Le modèle reproduit 98.7% des états réels du radiateur. │
│ - L’écart moyen (RMSE_val) est de 0.162 → excellent calibrage. │
│ - Overshoot ≈ 0.04°C → comportement inertiel normal. │
│ - Coeffs → système lent, forte sensibilité extérieure. │
│ │
╰──────────────────────────────────────────────────────────╯
Salut @KipK,
bravo pour l’initiative d’un auto TPI. Ayant une maison mal isolée, suivant le froid et le vent, je dois modifier mon TPI. Ça serait le top, d’avoir un auto TPI fonctionnelle sous Vtherm.
À force, Vtherm va être la rolls des thermostats 
3 « J'aime »
Salut 
Superbe initiative et j’attends avec impatience la version finale publique 
Ma maison est, je pense , comme celle de @WarC0zes : pas super bien isolée (maison de 1970, malgré une isolation refaite de l’intérieure par l’ancien propriétaire).
Je n’ai pas assez de recul quant aux TPI à changer , je ne me suis même jamais posé la question 
Et surtout , normalement j’utilise un poêle à bois pour chauffée la pièce principale (salon/sejour/cuisine) donc très peu les radiateurs électriques… mais là la vitre du poêle est fendue donc ce dernier inutilisable. On chauffe donc qu’avec les radiateurs, dont seulement 4 sont équipés de modules NodOn fil pilote.
D’ailleurs à ce propos , il me semble que via les VTherm, on ne peut pas avoir un radiateur à 50% (ou autre valeur < 100%) n’est-ce pas @Jean-Marc_Collin ?
Bref en tout cas ceci (l’Auto-TPI) me semble une excellente idée et surtout je suis impressionné par vos algorithmes et connaissances en la matière r’
J’en ai d’ailleurs pas tout saisi bien qu’ayant eu une formation assez poussée en mathématiques , mais davantage en physique chimie (je suis enseignant en SPC ).
Sur ce bonne journée à tous
1 « J'aime »
Il existe en réalité de nombreuses méthodes pour rechercher des coefficients optimaux.
De mon côté, j’utilise principalement la grid search : c’est une méthode de type brute force qui teste l’ensemble des combinaisons possibles des deux coefficients. C’est la méthode la plus exhaustive, donc la plus fiable, mais elle est aussi très coûteuse en temps de calcul et en ressources.
Les deux autres algorithmes que j’exploite poursuivent le même objectif, mais de manière plus rapide, car ils ne testent pas toutes les paires de coefficients.
Une fois une zone intéressante identifiée, j’applique ensuite une méthode de Powell, limitée autour des coefficients trouvés, afin d’affiner le résultat :
J’ai également expérimenté une recherche basée sur XGBoost, mais je ne maîtrise pas encore suffisamment cet outil. Le principe est différent, car ici l’algorithme apprend directement le comportement thermique de la maison.
Cela dit, tout cela reste un raffinement assez théorique, puisque les valeurs sont de toute façon clippées aux limites acceptées par vth. Et au final, on régule une température, pas la trajectoire d’un satellite 
La méthode d’apprentissage basée sur les pentes (slopes) est aussi pertinente, mais je pense qu’elle ne fonctionne correctement qu’avec de fortes variations. L’apprentissage devrait d’ailleurs pondérer davantage le modèle le matin, lorsque le on_percent est proche de 100–90 %, et pénaliser les faibles on_percent.
La méthode des petits pas (désolé, je ne connais pas le nom exact de ta méthode), proposée par @KipK, est également très intéressante, car la thermodynamique d’une pièce est lente.
De mon côté, je lance mes algorithmes tous les lundis avec 14 jours d’historique. C’est suffisant, et cela permet aussi de s’adapter progressivement aux changements de saison.
D’ailleurs, @Jean-Marc_Collin, s’il est possible d’avoir un service permettant de modifier automatiquement ces coefficients, cela m’intéresserait beaucoup : cela éviterait toute intervention manuelle chaque semaine 
En pratique, il existe une multitude de couples de coefficients différents qui produisent le même résultat. Le graphique ci-dessous l’illustre très bien.
Le centre de la vallée correspond à la zone où les coefficients sont optimaux. On voit que cette vallée est large, ce qui est parfaitement logique. On observe également que la méthode XGBoost n’est pas la plus adaptée ici, puisqu’elle identifie une paire de coefficients située en dehors de la meilleure vallée.
En résumé, quelle que soit la méthode choisie, l’essentiel est d’obtenir une première bonne paire de coefficients, puis d’effectuer une optimisation locale autour de celle-ci (par slope ou petit pas), en tenant compte des évolutions climatiques.
1 « J'aime »
Hello,
Quelques réflexions par rapport à ce projet.
J’avais réfléchit à comment faire de l’auto-tpi, il y a qqes temps maintenant et je vous donne mes conclusions dès fois que ca éclaire vos travaux.
Les grandeurs physique à optimiser
Dans cet article, Baissez vos factures de chauffage avec Versatile Thermostat, on voit comment l’humain sait qu’il faut changer de paramètres. Il y a 3 valeurs à optimiser :
- minimiser la durée de la montée en charge,
- minimiser les oscillations,
- minimiser l’écart de stabilisation.
Mesure les grandeurs physiques
Là je pèche. Une approche naïves ne suffit pas (si la current_temp dépasse …). Il faut des modèles statistiques pour détecter le bon moment (la mesure l’écart de stabilisation ne doit se faire que si la situation est stable, …). On sent bien que le slope (dTemp/dt) peut aider.
Optimiser les valeurs
Je suis assez fan de l’algo du recuit simulé qui permet d’optimiser une fonction de cout en faisant varier ses paramètres. Donc si on arrivait à exprimer une fonction de cout en fonction de ces 3 mesures, je serais capable de l’optimiser. L’algo de recuit simulé est celui qui est utilisé dans l’intégration Solar Optimizer qui permet de trouver la meilleure combinaison d’états ouverts / fermés d’une série de switch. Donc le code est là et directement utilisable au besoin.
Oui je vais bricoler un truc non documenté pour l’instant. Ce ne sera pas persistant (un arrêt/relance ou changement de conf du VTherm recharge les paramètres) car je ne sais pas le faire mais j’ai pas chercher.
Ca peut permettre à @WarC0zes d’adapter les paramètres si il y a besoin. D’ailleurs ca m’intéresse de savoir quand et pourquoi tu changes les paramètres ? été/hiver ? pluie / sec ? …
avec des chauffages électriques , j’utilise cette configuration en TPI
Mais quand il fait vraiment froid et avec beaucoup de vent , j’augmente le coef_ext à 0.07.
1 « J'aime »
Froid et vent tu n’atteins pas la consigne et si tu laisses à 0.07 tout le temps tu dépasses la consigne. C’est là que les travaux de @KipK et @Gael1980 prennent tout leur sens. Après c’est à la journée du coup. Il ne faut pas que ca mette 2 semaines à apprendre les nouvelles valeurs.
Donc je vais faire un service qui va te permettre d’automatiser ce changement.
1 « J'aime »
c’est exactement ça
en soi ce n’est pas dérangeant de modifier le TPI du central VTherm. Mais pourquoi pas une action et faire une automatisation, qui modifie ça suivant la température et vitesse du vent
Je ne sais pas si la méthode du recuit simulé est une bonne base pour de l’optimisation de température, je vais regarder.
En automatisme industrielle, on utilise plus souvent le PID, mais les méthodes de recherche de paramètres kp, ki et kd optimaux ont besoin souvent d’une phase ou tu force le chauffage à 100 et tu regarde ces oscillation pendant une longue période.
Mais cela ressemble plus au graphe que tu nous a mis.
Apres, avec XGBoost, tu peux lui injecter un tas de capteur, humidité, soleil, pluie… bref, une tas de capteur.
Mais il faut que je poursuive les recherches sur cette bibliothèque.
Avec les 1er essai, je il me renvoi ceci comme paramètre qui influence le plus (basé sur mes 14 derniers jours)
Variables qui influencent le PLUS ta consommation (XGB importance) :
- temp_ext_mean → 0.446
- deltaT → 0.280
- DJU → 0.158
- rain → 0.061
- hum_ext → 0.031
- wind → 0.024
explication des resultats:
temp_ext_mean → 0,446 (44,6 %) : Plus il fait froid dehors, plus les pertes thermiques sont fortes donc Plus le chauffage doit compenser. Logique (heureusement)
deltaT → 0,280 (28,0 %) : deltaT = T_int - T_ext représente directement le gradient thermique à compenser.
DJU à 19 (Degrés-Jours Unifiés) → 0,158 (15,8 %) : Les DJU représentent une accumulation du besoin de chauffage sur une période.
rain → 0,061 (6,1 %) : Effet secondaire mais réel. La pluie agit indirectement via, l’augmentation de l’humidité des parois et la baisse du rayonnement solaire
Le vent et l’humidité ext est négligeable.
Attention, les valeurs ici sont pour ma maison, pour une autre personne ailleurs en france, peut etre que le vent sera plus important et la pluie plus faible…
1 « J'aime »
Que de bonnes idées ici. 
Pour rajouter une couche voici la méthode Jeedom, que je voudrais implementer comme base de réference ( rien à voir avec la formule postée en tete du topic )
La regulation utilise le même principe TPI que versatile ( avec une nnuance, les CoeffInt/Ext sont différents en fonction de la direction froid/chaud )
Power = (direction × ΔT_int × Coeff_int) + (direction × ΔT_ext × Coeff_ext) + Offset
Chaque coefficient a un compteur d’apprentissage (max 50) :
coeff_indoor_heat_autolearncoeff_outdoor_heat_autolearncoeff_indoor_cool_autolearncoeff_outdoor_cool_autolearn
Rôle : Plus le compteur est élevé, plus le coefficient est stable (moyenne pondérée).
L’apprentissage se déclenche si et seulement si:
Auto-apprentissage activé
Fenêtre temporelle écoulée (90% du cycle)
Puissance précédente entre 1% et 99%
Moins de 3 défaillances consécutives
Variables sauvegardées entre cycles
cache = {
'last_power': 57, # Puissance du cycle précédent
'last_order': 21, # Consigne du cycle précédent
'last_temp_in': 19, # Température intérieure début cycle
'last_temp_out': 5, # Température extérieure début cycle
'last_state': 'heat', # État : 'heat', 'cool', ou 'stop'
'end_date': '2025-11-26 14:53:00' # Fin de fenêtre d'apprentissage
}
Apprentissage ( exemple pour le chauffage )
1 - Coefficient intérieur (coeff_indoor_heat)
Quand ? La température a augmenté pendant un cycle de chauffe.
Conditions :
last_state == 'heat'
temp_actuelle > temp_précédente
consigne_précédente > temp_précédente
Algorithme :
# 1. Calcul du ratio de performance
delta_théorique = last_order - last_temp_in # Écart à combler
delta_réel = temp_in - last_temp_in # Échauffement constaté
ratio = delta_théorique / delta_réel
# 2. Nouveau coefficient théorique
coeff_nouveau = coeff_actuel × ratio
# 3. Moyenne pondérée (stabilisation)
coeff_final = (coeff_actuel × nb_apprentissages + coeff_nouveau) / (nb_apprentissages + 1)
# 4. Incrémenter compteur (max 50)
nb_apprentissages = min(nb_apprentissages + 1, 50)
Exemple :
Situation :
- last_temp_in = 18°C
- last_order = 21°C
- temp_in = 19.5°C
- coeff_actuel = 10
- 10 apprentissages déjà effectués
Calcul :
- delta_théorique = 21 - 18 = 3°C
- delta_réel = 19.5 - 18 = 1.5°C
- ratio = 3 / 1.5 = 2.0
- coeff_nouveau = 10 × 2 = 20
Moyenne pondérée :
- coeff_final = (10 × 10 + 20) / 11 = 10.91
- nb_apprentissages = 11
Interprétation : Le système chauffe moins bien que prévu (ratio > 1), donc on augmente le coefficient.
2 - Coefficient extérieur/isolation (coeff_outdoor_heat)
Quand ? Apprentissage intérieur impossible, mais température extérieure < consigne.
Conditions :
last_state == 'heat'
temp_ext < last_order
PAS (temp_int > last_temp_in ET last_order > last_temp_in)
Algorithme :
# 1. Calcul du ratio d'influence extérieure
ecart_int = last_order - temp_in
ecart_ext = last_order - temp_out
ratio_influence = ecart_int / ecart_ext
# 2. Contribution de l'extérieur
contribution = coeff_indoor_heat × ratio_influence
# 3. Nouveau coefficient
coeff_nouveau = contribution + coeff_outdoor_heat_actuel
# 4. Moyenne pondérée
coeff_final = (coeff_actuel × nb_apprentissages + coeff_nouveau) / (nb_apprentissages + 1)
# 5. Incrémenter compteur
nb_apprentissages = min(nb_apprentissages + 1, 50)
Exemple :
Situation :
- last_order = 21°C
- temp_in = 19°C (stable, n'a pas bougé)
- temp_out = 5°C
- coeff_indoor_heat = 10
- coeff_outdoor_heat_actuel = 2
- 5 apprentissages déjà effectués
Calcul :
- ecart_int = 21 - 19 = 2°C
- ecart_ext = 21 - 5 = 16°C
- ratio_influence = 2 / 16 = 0.125
- contribution = 10 × 0.125 = 1.25
- coeff_nouveau = 1.25 + 2 = 3.25
Moyenne pondérée :
- coeff_final = (2 × 5 + 3.25) / 6 = 2.21
- nb_apprentissages = 6
Interprétation : L’écart extérieur influence les pertes thermiques, on ajuste l’isolation.
Cycle de fonctionnement complet
Séquence d’exécution
┌─────────────────────────────────────────────────────┐
│ 1. DÉBUT DU CYCLE │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ 2. LECTURE DES TEMPÉRATURES │
│ - Température intérieure │
│ - Température extérieure │
│ - Consigne │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ 3. CALCUL DE LA PUISSANCE │
│ Power = (dir × ΔT_int × C_int) + │
│ (dir × ΔT_ext × C_ext) + Offset │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ 4. CALCUL DURÉE D'ACTIVATION │
│ Duration = (Power × Cycle) / 100 │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ 5. ACTIVATION CHAUFFAGE/CLIM │
│ Pendant "Duration" minutes │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ 6. AUTO-APPRENTISSAGE (si conditions OK) │
│ - Observer performance réelle │
│ - Ajuster coefficients │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ 7. SAUVEGARDE ÉTAT POUR PROCHAIN CYCLE │
│ - last_power, last_order, last_temp_in, etc. │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ 8. PROGRAMMATION PROCHAIN CYCLE │
│ Dans 59 minutes │
└─────────────────────────────────────────────────────┘
L’apprentissage s’arrète en cas :
-
defaillance sonde
-
defaillance chauffage/clim
Critères :# En chauffage : température baisse alors qu'on chauffe if (temp_in < last_order - offset_heat_failure and temp_in < last_temp_in and last_state == 'heat' and nb_apprentissages > 25): consecutive_failures += 1 # En climatisation : température monte alors qu'on refroidit if (temp_in > last_order + offset_cool_failure and temp_in > last_temp_in and last_state == 'cool' and nb_apprentissages > 25): consecutive_failures += 1 # Alerte après 2 cycles consécutifs if consecutive_failures >= 2: status = 'Défaillance chauffage/climatisation' # Exécution actions d'alerte # Blocage apprentissage après 3 cycles if consecutive_failures >= 3: autolearn_enabled = False
Logique : Le système doit être mature (>25 apprentissages) avant de détecter les défaillances.
Fonction SmartStart (Anticipation)**
Principe
Démarrer en avance pour atteindre la consigne à l’heure programmée.
Algorithme
def smart_start(next_event):
# 1. Consigne de l'événement
target_temp = next_event['temperature']
target_time = next_event['datetime']
# 2. Calculer puissance nécessaire
power = calculate_power(target_temp, current_temps)
# 3. Calculer durée nécessaire
cycle = 60 # minutes
duration = (power * cycle) / 100
if duration < 5:
return # Trop court, pas de SmartStart
# 4. Programmer démarrage anticipé
start_time = target_time - timedelta(minutes=duration)
schedule_activation(start_time, target_temp)
Exemple
Événement : 21°C à 07h00
Température actuelle : 17°C
Puissance calculée : 70%
Cycle : 60 minutes
Durée nécessaire : (70 × 60) / 100 = 42 minutes
→ SmartStart à 06h18 (07h00 - 42 min)
Évolution typique des coefficients
Phase d’initialisation (0-10 cycles)
coeff_indoor_heat: 10 → 12 → 15 → 18 → 16 → 17 → 16.5 ...
Variations importantes, le système explore
Phase de stabilisation (10-30 cycles)
coeff_indoor_heat: 16.5 → 16.8 → 16.6 → 16.7 → 16.65 ...
Variations plus faibles, convergence
Phase stable (30+ cycles)
coeff_indoor_heat: 16.65 → 16.66 → 16.64 → 16.65 ...
Micro-ajustements, système optimal
Compteur = 50 : Le coefficient devient très stable (nouvelle valeur a seulement 2% d’influence).
2 « J'aime »
Pas mal comme algo, à essayer.
Est il possible de rajouter l’humidité intérieur de la maison afin de corriger la consigne (consigne interne, pas l’affichage)
Un truc du genre :
def dew_point_from_T_RH(temp_c: float, rh_percent: float) -> float:
"""
Calcule le point de rosée (°C) à partir de la température (°C)
et de l'humidité relative (%), via la formule de Magnus.
"""
if rh_percent <= 0 or rh_percent > 100:
raise ValueError("rh_percent doit être dans l'intervalle (0, 100].")
a = 17.27
b = 237.7 # °C
gamma = (a * temp_c) / (b + temp_c) + math.log(rh_percent / 100.0)
dew_point = (b * gamma) / (a - gamma)
return dew_point
def humidex_from_T_dew(temp_c: float, dew_c: float) -> float:
"""
Calcule l'humidex à partir de la température de l'air (°C)
et du point de rosée (°C), selon la définition 'classique'.
"""
e = 6.11 * math.exp(5417.7530 * (1.0 / 273.16 - 1.0 / (dew_c + 273.15)))
humidex = temp_c + 0.5555 * (e - 10.0)
return humidex
def humidex_from_T_RH(temp_c: float, rh_percent: float) -> Tuple[float, float]:
"""
Renvoie (T_dew, humidex) à partir de T (°C) et HR (%).
Retour:
dew_point_c (float): point de rosée en °C
humidex (float): indice humidex (°C 'ressenties')
"""
dew_c = dew_point_from_T_RH(temp_c, rh_percent)
hx = humidex_from_T_dew(temp_c, dew_c)
return dew_c, hx
def corrected_setpoint_from_humidex(
consigne_c: float,
temp_c: float,
rh_percent: float,
gain: float = 0.7,
max_delta: float = 2.0,
) -> float:
"""
Corrige la consigne de chauffage en fonction de l'humidex.
- consigne_c : consigne 'sèche' (°C)
- temp_c, rh_percent : mesures intérieures
- gain : proportion de l'écart (Humidex - consigne) appliquée
- max_delta : limite absolue de correction (en °C)
NB : il n'existe pas de norme officielle disant que c'est 'LA' bonne loi.
C'est un choix d'ingénierie pour moduler la consigne en fonction du ressenti.
"""
dew_c, hx = humidex_from_T_RH(temp_c, rh_percent)
# Ecart ressenti vs consigne
diff = hx - consigne_c
# On ne baisse la consigne que si l'humidex est au-dessus de la consigne
if diff <= 0:
return consigne_c
# Correction proportionnelle limitée
correction = gain * diff
correction = min(correction, max_delta)
consigne_corrigee = consigne_c - correction
return consigne_corrigee
dans le code :
HR = humidity_percent
T = temp_in
consigne_cor = corrected_setpoint_from_humidex(
consigne_c=consigne,
temp_c=T,
rh_percent=HR,
gain=0.7,
max_delta=2.0,
)
| HR (%) | T_dew (°C) | Humidex (°C) | Humidex − consigne | Correction | Consigne corrigée |
|---|---|---|---|---|---|
| 30 | ≈ 1,0 | ≈ 17,1 | −1,90 | 0,0 | 19,0 °C |
| 40 | ≈ 5,1 | ≈ 18,3 | −0,68 | 0,0 | 19,0 °C |
| 50 | ≈ 8,3 | ≈ 19,5 | +0,55 | ≈ 0,38 | 18,6 °C |
| 60 | ≈ 11,1 | ≈ 20,8 | +1,78 | ≈ 1,25 | 17,8 °C |
| 70 | ≈ 13,4 | ≈ 22,0 | +3,02 | 2,0 | 17,0 °C |
| 80 | ≈ 15,5 | ≈ 23,3 | +4,26 | 2,0 | 17,0 °C |
Le gain représente :
La fraction de l’erreur de ressenti que tu acceptes de corriger par le chauffage.
exemple : avec gain = 0.7, :
Je ne compense pas 100 % de l’écart de ressenti, seulement 70 %.
Si cela ne fonctionne pas alors, tu mets gain = 0.0
@Jean-Marc_Collin : Je crois que c’était aussi une demande sur le github il me semble ?
1 « J'aime »
J’ai déjà rajouté l’entité humidité aux Vtherm sur ma branche. Du coup oui on peut tester.
1 « J'aime »
Tu as utilisé le même algo de compensation ?
@Gael1980 plus ou moins, c’était pour affiner le modèle thermique de la pièce.
On essaye de résoudre une equation qui prédit la vitesse de chauffe ( deltaTemp / dt )
DeltaTemp/dt = -alpha * (Room - Ext) + beta * Power (+ gamma * (Humidity - 50))
Elle prend en compte l’écart d’humidité par rapport à une moyenne de 50%.
L’algorithme calcule un coefficient spécifique pour l’humidité (appelé gamma dans le code). Si ce coefficient est utilisé, cela permet de « nettoyer » le calcul des coefficients principaux (alpha pour l’isolation, beta pour la puissance du radiateur)
C’est une variable de correction. Elle sert à expliquer pourquoi la pièce chauffe parfois un peu plus vite ou plus lentement que prévu, ce qui permet au final d’avoir des réglages de chauffage plus stables et précis.
Je prend note de ce que t’a posté plus haut..
J’ai eu beaucoup de demandes pour faire comme Jeedom. Ca avait l’air de plaire. C’est certainement une bonne piste avec un retour d’expérience positif.
T’as retro-ingénieré le code ? avec une IA ?
Oui j’avais acheté ce plugin du coup j’ai pu mettre le nez dedans. Et merci les IA pour faire la synthèse. Le code PHP est pas foufou à lire.
Edit: Je voudrais ajouter à ça la possibilité d’enregistrer les coeffs trouvés dans une banque , matchés avec des valeurs de conditions climatiques. Et qu’on ai une boucle qui verifie les conditions climatiques actuelle, puis applique automatiquement l’enregistrement le plus en adequation.
Si pas de coeff dispo pour les conditions actuelles, proposer de lancer un apprentissage et enregistrer cette nouvelle banque.
Je viens enfin de comprendre ce qui n’allait pas dans mon algo.
En fait je filtrais stupidement à l’acquisition des données. J’avais du tester ça tard le soir pour une raison obscure, et oublier de l’enlever.
Ca devrait bcp mieux marcher maintenant. Je recommence un apprentissage, on verra demain.
Sur le Github du vth, j’ai déposé une mise à jour du script compatible vth8.
Cette version se limite à l’affichage des coefficients coef_int et coef_ext proposés.
Elle n’intègre pas l’analyse de la consommation, ni l’utilisation de XGBoost, ni de modèle 2R2C.
exemple d’utilisation :
uv run calibrate.py --thermostat climate.thermostat_cuisine
uv run calibrate.py --thermostat climate.thermostat_cuisine --cycle-sec 600 --tpi-high 1.5 --tpi-low 0.2 --min-on 45 --min-off 45
2 « J'aime »