Pilotage pompe à chaleur. Gestion des temporisation

[Stef32]

Bonjour,

Je souhaite piloter la pompe à chaleur de piscine pour compléter le routage sur chauffe eau. J'ai réussi à gérer le pilotage en TOR en insérant un relais dans la boucle du détecteur de débit.
Ce relais est intégré sur une carte 4 relais sur l'esp 192.168.1.203.
Le routage du chauffe eau se fait par un SSR sur l'esp 198.168.1.201.

Le fonctionnement que je souhaiterais (idéalement) serait le suivant :

• Passage de Off à On si : température chauffe eau > 55°C ET routeur chauffe eau > 40% (1)
  
• Passage de On à Off si : puissance consommation > 800W (1)
  
• interdire les cycles court : Temps ON mini 10mn / Temps OFF mini 10 mn (ou 5 mn si possible mais je ne pense pas que ça le soit)
  

(1) idéalement, je voudrais que le déclanchement s'active si les conditions sont maintenues pendant 1mn.
ex : 
T = 0s : température chauffe eau > 55°C ET routeur chauffe eau devient > 40% => reste à off (démarrage compteur 60s)
T = 10s : température chauffe eau > 55°C ET routeur chauffe eau devient < 40% => reste à off (reset compteur 60s)
T = 40s : température chauffe eau > 55°C ET routeur chauffe eau redevient > 40% => reste à off  (démarrage compteur 60s)
T = 60s : température chauffe eau > 55°C ET routeur chauffe eau reste > 40% => reste à off (compteur 20s)
T = 100s : température chauffe eau > 55°C ET routeur chauffe eau reste > 40% => passe à on (compteur 60s)
idem pour la puissance consommation > 800W

Est ce que les actions ON/OFF permettent de réaliser cela ? 
Quelle est la fonction des paramètres temporisation et répétition ? j'ai du mal à comprendre exactement, surtout pour le paramètre répétition.

Ci joint des copies d'écran de la manière dont je l'ai paramétré sur le routeur chauffe eau ainsi que l'esp "pisicine" 192.168.1.203
Cela ne fonctionne pas comme je voudrais. En particulier, j'ai des ON/OFF très fréquents. Je n'observe pas les 10mn attendues, ce qui est rédhibitoire.

Une idée ? quelque chose que je fais mal ?

Merci par avance et encore bravo à ce super projet !

[Mike]

Bonjour,
Le déclenchement que si les conditions sont maintenues pendant 1 minute n'est à ma connaissance pas possible.

La temporisation correspond au temps minimum entre chaque changement d’état. Le paramètre repetition correspond à la période de repetition de l'ordre courant (ON ou OFF).
Concernant le fait que vous observer des ON/OFF plus frequent que la valeur de la temporisation, vu que vous utilisez le endpoint /ForceAction, ce endpoint force l'action (à ON ou OFF) pour un temps donné en minutes qui est passé dans le paramètre Force. Si la valeur du paramètre Force est trop petite alors cela pourrait expliquer le comportement.
Dans votre cas vous devriez utiliser une grande valeur pour le paramètre Force. Une autre option est de mettre le paramètre Force à 10 par exemple et de mettre le paramètre de repetition à 540 (9 minutes).

[Stef32]

Bonjour et merci pour la réponse.

Le paramètre force est à 240 (/ForceAction?Force=240&NumAction=2 pour on et /ForceAction?Force=0&NumAction=2 pour off) donc normalement il ne devrait pas y avoir de problèmes. Et j’avais donc bien compris pour la temporisation mais le comportement ne semble pas coller ou je passe à côté de quelque chose. 
Je précise aussi que j’ai essayé de paramétrer l’action sur l’esp piscine donc pas avec « force » et le résultat est le même. Je n’ai pas les 10mn d’état stable systématique.

Pour répétition, je ne comprends pas bien le fonctionnement et l’usage. En particulier la proposition avec les 9mn.

Par ex, si après 9mn la condition de mise en marche est fausse, est ce que ça répète l’ordre initial (off -> on) ou l’ordre a l’instant t (on -> off) ?

Idem pour la temporisation : par ex
T = 0mn : température chauffe eau > 55°C ET routeur chauffe eau devient > 40% => passe à on (démarrage compteur 10mn)
T = 2mn : température chauffe eau > 55°C ET routeur chauffe eau devient < 40% => devrait rester à on car compteur < 10mn
T = 8mn : température chauffe eau > 55°C ET routeur chauffe eau devient > 40% => reste à on. Car condition vrai ou car compteur < 10mn ?
T = 10mn : température chauffe eau > 55°C ET routeur chauffe eau toujours > 40% => reste à on car condition vrai ou passe à off car condition reset a été activé précédemment et compteur 10mn depuis début ?
Si reste à on quand passera t il à off ?

[Mike]

Durant les 10 minutes que l'on voit de la courbe "Pompe à chaleur piscine" la temporisation était bien à 600 tout le temps ?
Si tel est le cas alors je n'ai pas d'explication, ce n'est pas le comportement que j'observe en testant de mon coté. Il n'y a pas eu d'action extérieure (manuelle ou depuis une autre action) qui aurait pu forcer à OFF ou ON l'action "Pompe à chaleur piscine" ?

[H3rv3]

Salut,

j'avais déjà posté à propos des temporisations. Comme constaté par Stef32, ça ne marche pas exactement comme on pourrait le penser.
Après pas mal d'essais et de revue de code, je suis venu à la conclusion que ça marche comme dans la première figure ci-dessous alors que je pensais (voulais) que ça marche comme dans la deuxième (aussi ce que cherche Stef32).

   

De base, le RMS évalue les conditions toutes les 'tempo' secondes et met l'état résultant sur la sortie. Ça ne prend pas en compte les changements d'état précédents, juste l'état actuel au moment T.

Pour mon application au VE avec contrôle de décharge de la batterie de la maison, j'avais besoin d'avoir la tempo attendue et donc je l'ai modifiée pour avoir une 'temporisation réarmable au travail et au repos'. C'est parfait pour mon cas mais je sais que , par exemple, la modification apportée affecte la répétition de l'envoi en mqtt. Donc peut-être pas adaptée au cas présenté.

Une autre anomalie est que l'envoi de l'état d'une action à un autre ESP32 envoie l'état avant que la temporisation ne soit appliquée (cad: l'état instantané). J'ai aussi modifié ça pour mon cas de façon à recevoir l'état réel de la sortie temporisée que je peux utiliser comme condition dans une action sur un ESP distant (ici, arrêter la charge du VE si la batterie maison est en décharge > 300W pendant plus de 5 minutes, sans que le thermostat du four affecte le résultat).

[Stef32]

Bonjour et merci H3rv3,

Le diagramme est clair pour la manière dont ca fonctionne. Ou du moins dont ca devrait fonctionner car je pense qu'il y a un des petits bugs qui font qu'il y a parfois des états qui changent entre deux "tempo". voir ici : https://f1atb.fr/forum_f1atb/thread-1511.html
j'observe la même chose. ci-joint un exemple ou j'ai volontairement mis un seuil >400W et <400W (j'ai la meme chose avec des seuils plus éloignés sur de fortes variations).

Pour ce qui est des améliorations éventuelles. Effectivement, ta proposition correspond parfaitement à ce que j'avais appelé les conditions maintenues. ce serait parfait pour éviter les déclanchements sur des pics et des phénomènes transitoires. Mais à mon sens, il faut un temps relativement court (30s, 1 mn ?) au dela, à l'inverse, les phénomènes transitoires vont invalider les changements d'états.

Ma préoccupation initiale est sur les couts cycles sur des pompes ou pompes à chaleur. Il faudrait une temporisation d'une dizaine de mn.

Ci-joint, ton diagramme complété avec 2 propositions complémentaires : 

1. la version actuelle
   
2. ta version temporisation conditions maintenues
   
3. une temporisation anti-court cycle avec un déclanchement instantannée
   
4. l'idéal ... les deux temporisations donc une tempo de conditions maintenues + une tempo anti-court cycle de maintient de l'état
   

Bien sur, l'idéal serait le 4 mais si trop complexe, pour mon cas personnel, je préfèrerais le 3 car ma préoccupation est de garantir des temps de cycle mini.
A date, le fonctionnement actuel est rédhibitoire avec ces micro-coupures entre les tempos. Si quelqu'un a une idée de paramétrage pour l'éviter je suis preneur car je n'ai pas mis en place le pilotage de la pompe à chaleur par crainte.

Merci encore à André et aux membres actifs pour ce projet, il est génial ! si c'est possible d'améliorer ce fonctionnement, ce serait top !

[H3rv3]

Tiens, maintenant que je vois le cas 3 sur un graphe, et vu le nom de la variable T_LastAction, je pense que ça devait être l'idée originale.

Toutefois, mes essais et mon interprétation du code me disent que ce n'est pas ce qui se passe. Ce qui se passe c'est que la temporisation se remet à zéro à chaque fois que la sortie sur la gpio est validée (quelque soit son état) mais pas nécessairement quand la gpio change d'état. Du coup, la validation arrive toute les x (tempo) secondes.

Je pense que passer au cas 3 ne sera pas trop difficile, il faudra peut-être ajouter un timer séparé si besoin de la répétition mqtt.
Pour le cas 4, il faudrait rajouter un paramètre dans les actions pour pouvoir mettre T1 et T2. Ce sera plus complexe, mais c'est le top.

Pour mon application VE, je préfère le cas 2. Je ne veux pas couper immédiatement à l'arrivée du nuage ou à la mise en route de la cafetière, j'accepte la petite importation. Si le nuage est persistant ou si je fais du café pour 12, ça ne va pas le rater. 
Pour la remise en route, ça va bien attendre que le soleil soit revenu ou que tout le monde ait fini sa tasse. Il faut jouer avec les W et les secondes pour trouver le bon compromis. Perso, j'ai 300W pendant 5 minutes (25Wh) sur la décharge de la batterie de la maison.

Peut-être qu'il serait aussi possible de combiner le cas 2 avec un relais temporisé externe qui jouerai le rôle de T2 ou le cas 3 avec un relais externe qui jouerai le rôle de T1?