Hello.
Je repasse en mode peuffinage…
J’ai ces courbes de debug avec les valeurs suivants.
kp: 40
ki: 0.007
kd: 2400
ke: 0.6 # pour l'exterieur
A votre avis, est ce que ça peut etre amélioré ? J’ai toujours le D proche de 0…
C’est un plancher chauffant électrique avec une inertie plutôt très forte…
Les gros dépassements c’est le soleil à travers les fenetres…
Je multiplierais kp par deux, et diviserais ki par deux.
Thx
Pourquoi penses tu qu’il faut doubler Kp ?
Attention je sais pas si tu te souviens, mais quand je suis sous la consigne, la puissance rééelle est déjà au max => Sur la capture on voit bien le rapport cyclique à 50%, qui est le maximum. A priori le thermostat d’origine fonctionnait déjà comme ça. Je pense qu’il faut éviter d’aller au dela.
Voici mon fichier de conf pour info
target_sensor: sensor.air_monitor_temperature
min_temp: 7
max_temp: 23
ac_mode: False
target_temp: 19
keep_alive:
seconds: 60
away_temp: 14
kp: 40
ki: 0.007
kd: 2400
ke: 0.6 # pour l'exterieur
pwm: 00:20:00
#difference: 50 # limite le rapport cyclique à 50% soit pas plus de 10 min
outdoor_sensor: sensor.temperature_sht35
debug: true
min_cycle_duration: 60 # 60 secondes minimum pour un état donné. Evites que le relais soit allumé moins d'une minute.
# le thermostat peut etre utilisé en manuel pour d'autres choses
force_off_state: false
# remplace le parametre difference
output_max: 100
out_clamp_high: 50
Je pensais monter le Kp pour compenser plus fortement l’intégrale, mais si on le laisse comme ça, alors il faudra baisser plus fortement le Ki et mais aussi le Ke, la somme des deux provoquant une chauffe trop importante alors que la température est au dessus de la consigne.
Essaie ki = 0,0035 et ke = 0,3.
Bonsoir,
Vos climates sont-ils toujours fonctionnels depuis la mise à jour de Z2M?
Bonjour, j’ai un plancher chauffant également. Le terme Ke devrait être le terme prépondérant.
Le Kd ne fonctionne que lorsque la température varie, et est inutilisable lorsque la température varie trop lentement, comme pour un plancher chauffant, et compte tenu de la manière dont le terme dérivé est calculé.
Je suggérerais donc de régler Ke d’abord, puis Kp, et enfin Ke. J’ai fait ça sur mon chauffage, et ça fonctionne.
Avec un plancher à forte inertie, vous ne pourrez avoir de température qui ne varie pas lorsque les variations sont rapides. C’est de la physique pure et dure…
Pour être tout à fait complet. Vous remarquerez que, parfois votre température augmente alors que vous avez une commande à 0. Cela est du au fait que vous chauffez votre dalle qui ensuite chauffe l’air. Donc il faudrait un « vrai » terme dérivé pour traiter la chose.Celui qui est codé est trop simpliste : il faudrait faire un terme dérivé « moyenné » sur un temps caractéristique bien plus long que ce qui est codé.
Bonjour,
j’ai défini le paramètre PWM sur 20 min, mais le signal peut être sur ON bien plus longtemps, plus d’une heure, voire plusieurs heures en mode boost. Est-ce que j’ai oublié un paramètre?
min_temp: 10
max_temp: 24
ac_mode: False
target_temp: 20
keep_alive: 00:00:60
kp: 70
ki: 0.05
kd: 2000
ke: 0.6
pwm: 00:20:00
sampling_period: 00:04:00
target_temp_step: 0.1
precision: 0.1
sensor_stall: 12:00:00
away_temp: 15
sleep_temp: 19
eco_temp: 18
boost_temp: 21
comfort_temp: 20
min_cycle_duration: 0:05:00
min_off_cycle_duration: 0:07:00
boost_pid_off : false
debug: true
Bonjour Scratman,
dans ton message de février 2024, tu écris :
Mais si le PID dit 100% ça restera ON tout le temps
Mais de mon côté je souhaite que si le PID est à 100% le signal reste ON le temps défini par le paramètre pwm, soit 20 min dans mon cas. Sinon est-ce que je peux forcer le PID à 99% en modifiant le code?
Bonjour à tous 
Depuis quelques temps j’ai constaté un souci qui devient majeur avec le temps et qui a empiré avec les dernières màj de HA.
A ce jour :
En effet, depuis un moment maintenant HA active/désactive mes switchs pour quelques millièmes de secondes seulement, même si le PowerOutput est à plus de 15% par exemple.
Sachant que la durée de vie d’un switch se compte en cycles marche/arrêt le système est en train de flinguer mes switchs un à un tout en faisant n’importe quoi avec les températures…
J’ai l’impression que ce souci est apparu progressivement au fil des mises à jour de HA car tout fonctionnait à la perfection au début de l’hiver et je n’ai rien touché à ma configue depuis, en dehors des mises à jour HA.
Ce matin, j’avais un peu de temps donc j’ai supprimé un thermostat spécifique et j’ai recréé proprement ce thermostat (après supression des entités liées et reboot) avec les paramètres les plus simples possible pour vérifier le comportement de base.
- platform: smart_thermostat
name: Smart Thermostat Bureau
unique_id: smart_thermostat_bureau
heater: light.ts0004_2_climat_pilote_radiateur_bureau
invert_heater: True
target_sensor: sensor.stat_temperature_moyenne_bureau
outdoor_sensor: sensor.temperature_exterieure
keep_alive:
seconds: 30
pwm:
seconds: 180
target_temp_step: 0.1
min_temp: 7
max_temp: 24
away_temp: 7
eco_temp: 14
comfort_temp: 17
boost_temp: 18
kp: 100
ki: 0
kd: 0
ke: 0
Résultat avec une température à 17,8 et une consigne à 18.0 les allumages/extinctions se multiplient et la température baisse. Notez que c’est une gestion par fil pilote (Off is On)
Bien entendu j’ai essayé avec le paramètre « min_cycle_duration » mais il n’a plus aucun effet.
J’ai exactement le même souci que mes switchs soient en ZigBee ou en WiFi.
Je suis le seul avec ce souci ?
Merci à vous pour votre aide et votre contribution 
Bonjour,
je viens de comprendre que pour limiter le rapport cyclique je peux utiliser les paramètres output_max et out_clamp_high 
. Par contre je ne comprends pas la différence entre les deux.
Je suis rassuré, façon de parler, car j’ai vu sur github que je n’étais pas le seul avec ce souci qui se présente à l’identique chez d’autres depuis la même période avec les mêmes aggravations au fil des MàJ de HA.
Je suppose que des modifications apportées à HA dans le comportement de climate engendrent des soucis de compatibilité, ou un truc du genre…
Heureusement le besoin de chauffage touche à sa fin, espérons que cela sera corrigé avant l’hiver prochain, au pire je retournerai à mes automatisions qui étaient fonctionnelles mais bien moins pratiques que ce module.
A tester aussi les inters virtuels à intercaler entre le module et les switchs, il semble que ça règle le souci (étrange, les classes ?).
Merci à ScratMan pour tout le travail
Bonjour,
vu le nombre important de messages et suivi du sujet. Pour éviter de saturer, l’envoie de mail quand un nouveau message est écrit. Nous passons le sujet en archive.
Un nouveau sujet est ouvert ici: