après un reboot de l’ESP, la première valeur de consigne est fausse ( setpoint = 214783647) => ce qui donne une consigne de chauffe en FF (chaudière au max à 100%). Si il y a en mémoire une target_temperature, et une current_temperature, alors une nouvelle consigne correcte est rapidement calculée. Sinon… ça peut être gênant. Peut être qu’il faudrait éviter d’envoyer une consigne temps que les valeurs ne sont pas correctement calculés ?
les variables heat_factor, offset, et kp reviennent à leur valeur initiale après reboot (valeurs initiales définies dans le fichier de configuration yaml).
Bonjour @erwan33fr
Merci pour ce retour, en effet, le calcul se fait quand la température extérieure ou intérieure évolue. Si l’une des deux n’est pas encore chargée par l’ESP depuis HA, le calcul est faux. Je vais corriger ça.
Sinon, j’ai poussé sur git une nouvelle version des composants, qui ne sont plus des custom components mais de vrais composants esphome plus facile à configurer dans le fichier yaml. J’utilise désormais la fonctionnalité external_components pour cela.
Les composants customs sont trop simples et on arrive vite aux limites de ce qu’on peut faire avec.
Je t’invite à faire la migration car l’ancienne version (toujours disponible) ne va plus évoluer.
Changement : l’ID de la chaudière et le numéro de pin se renseignent désormais dans le fichier yaml. Il n’y a plus à toucher au code c++.
Pour les variables globales qui ne sont pas sauvegardées, j’ai remarqué ça aussi alors que la doc dit le contraire. J’ai abandonné ce concept dans la nouvelle version en attendant mieux
@erwan33fr , c’est corrigé, dis moi comment ça se passe de ton coté.
J’ai également corrigé l’ancien code (déplacé dans /custom), c’est la dernière fois que j’y touche
@corti23, je viens de voir tes messages, je vais essayer de trouver le temps cette semaine pour tester cette nouvelle version
il y a de gros changement
Pour l’intégration dans Home Assistant, la modification des variables control_parameters et output_parameters de CLIMATE (heat_factor, offset, kp, output_factor, output_offset)
se fait via l’appel aux services suivant ? :
Il faudrait peut être documenter davantage l’intégration dans Home Assistant, pas toujours évident de comprendre le code et de retrouver les services Home Assistant associés.
Oui, tu as raison, il faut étoffer la doc pour l’intégration HA, c’est en cours.
Pour les services disponibles dans HA, je les ai remplacés par des « Actions » d’automatismes plus proches de la philosophie ESPHome et permet plus de flexibilité dans la création des services. Tout est dans la documentation.
Parfait, la documentation est plus complète maintenant
Petite remarque, il y a une inversion dans les exemples entre les chapitres « set_mode » et "set_level "
Dans le composant climate, pour output_parameters, il y a le paramètres minimum_output, output_factor, et output_offset. Pas de paramètre maximum_output et zero_means_zero ?
D’ailleurs pourrais tu préciser le rôle du paramètre zero_means_zero ?
Dans le fichier boiler.yaml de github, tu as les valeurs suivantes :
heat_factor: 1.65
offset: 21.5
kp: 0
Cela signifie que pour calculer ta consigne, tu ne tiens pas compte de la différence entre la température souhaitée et la température courante ? Donc tu ne tiens compte que de la différence entre température désirée et la température extérieure ?
Pour le moment j’avais ses valeurs :
heat_factor: 1.4
offset: 21
kp: 10
mais je me retrouve en moyenne 1° au dessus de la consigne.
Je vais tester :
heat_factor: 1.4
offset: 16
kp: 8
J’avais suivi ce fil cet été car je comptais me mettre à HA.
C’est maintenant chose faite, et je découvre que le projet s’est simplifié, quel bonheur
Je vais donc me lancer
J’ai néanmoins une question concernant le module ESPxxx
Je dispose chez moi de pas mal de shelly (ESP32) et dernièrement un nouvel add-on a été introduit dans leur gamme:
Dans le composant climate, minimum_output correspond à la consigne minimale envoyée à la chaudière en dessous de la quelle le climate enverra 0 (arrêt de la chaudière). Par défaut la valeur mini est 10%. Par exemple, si le climate calcule 9%, il enverra 0. Cela correspond au fonctionnement de la chaudière, en dessous de 10, il ne se passe rien.
zero_means_zero est un paramètre commun aux Float Outputs et est utile quand on configure un min_power (dans l’output, pas le climate). En gros quand l’output reçoit une consigne (entre 0 et 1), elle la convertit proportionnellement pour qu’elle soit entre min_power et max_power. Donc 0 sera converti en min_power sauf si zero_means_zero est true, dans ce cas zéro sera toujours égal à zéro.
Oui, une fois les bons coefficients trouvés, pas besoin de facteur proportionnel, à condition de ne pas changer la consigne durant la journée. Sans kp, la convergence peut alors être très longue. Par exemple si tu passes de 19°C à 17°C quand tu pars le matin, sans kp cela va mettre des heures à descendre. Avec un kp agressif, la chaudière va baisser significativement, au risque même d’être arrêtée, ce qui peut être un problème dans certaines pièces de la maison. Mais cela peut aussi être le comportement désiré.
Mon cas est particulièr, le séjour a de gros radiateurs en fonte avec de l’inertie et dans les chambres j’ai des radiateurs en tôle et robinets thermostatiques zigbee. Donc mes coefficients sont calculés pour le séjour mais il faut toujours de l’eau chaude dans les pièces car les radiateurs en tôle n’ont pas d’inertie. Quand la chaudière s’arrête, il fait vite froid dans les chambres. C’est pour cela que la régulation PID de Frisquet ne me convenait pas. La consigne de nuit arrêtait la chaudière à cause de l’inertie des radiateurs en fonte et on gelait dans les chambres.
Oui, ce n’est pas étonnant, ta loi d’eau doit être trop forte et la régulation proportionnelle ne permet pas de compenser. Il faudrait ajouter un terme intégral pour ça (je vais peut-être le faire). Tu as peut être une maison bien isolée (pas comme moi !).
En revanche, la loi d’eau, bien réglée devrait converger.
En hiver (maintenant par exemple), si c’est trop chaud, baisse la pente (0.1 p.ex.) , ne change pas l’offset. A la mi-saison, tu joues sur l’offset, par exemple baisse de 1 mais il faut compenser en augmentant la pente de 0,1.
Commence avec kp = 0 et regarde où ça te mène. Pense au kp comme un accélérateur.
Mon conseil, c’est de noter au cours de l’année la consigne envoyée à la chaudière (température d’eau) et le delta t constaté. En traçant la courbe (une droite normalement !), on trouve assez facilement les bon paramètres:
Comme je n’y connais rien en ESP, et que je n’ai pas trop envie de m’atteler à la partie hardware
Je suis tombé la dessus.
le pin G21 est disponible.
Est ce un bon choix pour se lancer dans ce projet ?
Interessant petit produit… Si on pouvait y coller les sondes Dallas sans effort ce serait parfait !
GP21 ou GP22 ont l’air libre, ça vaut le coût d’essayer. Tiens nous au courant.
Je ne vois pas comment t’aider plus à ce stade. Suis bien le tuto (sur GitHub, celui présenté ici sur ce thread n’est plus à jour) et si tu as des questions, n’hésite pas à revenir vers moi.
Pour revenir à la chaudière, le point critique est la détermination de l’ID de la chaudière, car il faut faire tourner un bout de code sur un Arduino pour écouter les trames reçues par le récepteur radio de la chaudière. Ça peut aussi se faire avec un ESP32 en mode Arduino mais ça, je n’ai pas essayé.
Ton fichier YAML a l’air correct.
L’erreur que tu as semble indiquer que ESPHome ne trouve pas les nouveaux composants.
Si tu enlèves les sensors, est-ce que le reste passe ?
Est-ce que les deux dossiers frisquet_boileret heat_curve_climate sont bien dans le dossier components ?
Est-ce que le dossiers sensor et son contenu est bien dans le dossier heat_curve_climate ?
Effectivement, il devait manquer quelque chose dans mon dossier « components ».
J’ai recopié l’arborescence et cette fois tout est ok
J’ai ajouté une ligne en 112 au fichier « heat_curve_climate.cpp » pour éviter les valeurs de consigne farfelu également lorsque la température courante n’est pas encore connu (après un reboot par exemple)
if (std::isnan(this->current_temperature))
{
ESP_LOGD(TAG, "Current temperature not available, skipping calculation.");
return;
}
Pour les paramètres de réglages (heat_factor, offset, kp), sous Home Assistant, j’ai créé des « input_number » avec une automatisation lors de changement :
alias: Chaudière Set Control Parameters
description: Set control parameters
trigger:
- platform: state
entity_id:
- input_number.chaudiere_heat_factor
- input_number.chaudiere_offset
- input_number.chaudiere_kp
condition: []
action:
- service: esphome.frisquet_set_control_parameters
data:
heat_factor: "{{ states('input_number.chaudiere_heat_factor') | float}}"
offset: "{{ states('input_number.chaudiere_offset') | float }}"
kp: "{{ states('input_number.chaudiere_kp') | float }}"
mode: restart
et pour restaurer les paramètres de réglage après un reboot de l’ESP, j’ai ajouté une automatisation :
Salut,
Content que cela fonctionne pout toi . Pour la modification que tu proposes, j’ai mis en place quelque chose de similaire dans la version que je vais pousser dans quelques jours. La différence est que si la température « current » n’est pas disponible, on saute juste le calcul proportionnel mais on continue avec la heat curve. Ce que tu proposes saute tout le calcul.
Quant aux automatisations que tu proposes, c’est super, je vais m’en inspirer probablement.
A noter que je suis en train d’ajouter un facteur intégral au climate mais je ne suis pas encore convaincu du résultat.
Pour le moment, après avoir trouver les paramètres adaptés à mon isolation (heat_factor 1.1 , offset 19 et kp 10), la régulation fonctionne parfaitement
Dans la prochaine version, est-ce que tu pourrais ajouter des sensors (heat_factor, offset et kp) pour avoir les paramètres pris en compte par l’ESP ?
J’ai jute un problème avec mon ESP (un Wemos D1 mini), il se reboot tout seul de façon assez cyclique (entre 37000 et 39000 secondes, soit toutes les 10h environ)
Le signal Wifi est bon, et j’ai essayé de changer l’alim.
En cherchant un peu, ce type de problème peut est lié à un 100% de load :
Est-ce que tu as constaté également ce phénomène ?
:
. Pour la modification que tu proposes, j’ai mis en place quelque chose de similaire dans la version que je vais pousser dans quelques jours. La différence est que si la température « current » n’est pas disponible, on saute juste le calcul proportionnel mais on continue avec la heat curve. Ce que tu proposes saute tout le calcul.