[LUA] Chauffage PID

[rimram31]

Je ne suis pas aussi ambitieux que vous sur un algo de PID car je me dis que quels que soit les coeffs, la montée en T eco/confort se fera les 3/4 du temps a fond, 100% de chauffe jusqu'a l'arrivée a la consigne. @Hawk49 un Kp élevé te permettra de chauffer a 100% tout en ayant un algo de PID tout le temps.

Pour moi un PID permettra d'amortir les changements de consigne qui peuvent etre brusques chez moi (dépassement de consigne quand il fait très froid justement d'avoir "trop envoyé"/"trop longtemps" => inertie radiateurs) et aussi d'avoir un maintien pendant une période eco ou confort plus stable. Là aussi plus il fait froid, plus c'est "marqué" (hysteresis).

Par contre ogulf, je pense oui que pour le confort de garantir une température atteinte a une heure donnée (mais on parle de confort pas d'économies:-)), il faut plutôt jouer sur l'heure de départ chauffe. En pratique quand j'observe mes courbes de T, j'ai la chance d'avoir plusieurs zones/pieces différentes (consignes zones jour/nuit), je constate que certaines pièces un peu justes en "capacité de chauffe" souffrent si T ext bas, au contraire d'autres sont a la consigne presque "trop" tôt. Pertinent alors peut-être de programmer en fonction de ça, en tout cas je le vois plus que d'aller chercher le dixième de degré a la précision de nos capteurs de T près en plus.

[ogulf]

Je gère 6 zones indépendantes, toutes ont leurs caractéristiques spécifiques :
- PID adapté par pièce
- radiateurs différents
- programmation éco/confort différente

Par expérience, j'arrive toujours à la température de consigne à l'heure de réveil sachant que s'il fait froid dehors ça a chauffé presque à 100% tout le temps (le fameux paramètre incompressible : démarrer plus tard ferait une consigne non atteinte au réveil).
En ce moment là consigne est atteinte avant l'heure de réveil et c'est la qu'il faudrait pouvoir anticiper le temps nécessaire à atteindre la consigne et agir sur l'idée Confort plus tard.
Du coup plutôt que de calculer la perte de température par heure par degrés d'écart avec l'extérieur, je vais estimer l'inverse : gain de température le matin (avec l'historique des températures et la même méthode).
Avec ce chiffre je vais estimer le temps qu'il faudrait pour atteindre la consigne... et comparer avec la réalité.
Si c'est pertinent ça veut dire qu'on sait adapter la mise en Confort.
Ensuite il suffira de modifier dynamiquement le planning Domoticz.

A suivre

[Hawk49]

J'ai récemment réinvesti (maigrement ...) dans du xiaomi aqara + sonoff "pour voir" et le pid fait partie des sujets que j'ai envie de reprendre.

On a donc le même matériel à gérer.

Quand je pense que Kp ne dépend (pas trop) de la T extérieure et/ou conditions externes / bruit (de perturbation de la régulation), c'est qu'il intervient en % d'augmentation/réduction de la consigne (elle même un % mais de temps de chauffe) et pas une simple valeur brute de proportionnalité / température.

Là j'avoue que je ne te suis pas trop...

je ne suis pas motivé pour évaluer les 3 valeurs de pid de mes 7 zones de chauffage ...

Complétement du même avis !

L'idée que j'ai pour ma part serait (d'essayer ) d'utiliser une approche type méthode empirique de Ziegler&Nichols ou équivalent (mes liens précédents) pour calculer et/ou réajuster "'automatiquement" les coefficients en observant la réponse du système aux conditions a l'instant t (ou presque) dont j'ignore tout, ma seule donnée c'est la réponse du système -> la T obtenue.
Démarrage (coeff encore inconnus et/ou a recalculer ?) en hystérésis simple (ou avec marge comme j'ai actuellement) et attendre d'avoir des données eco et confort. Partant de là sur une plage de temps assez large on peut avoir deux valeurs de la réponse T (obtenue en moyenne) = f(% tps de chauffe). Le % de tps de chauffe je le connais en moyennant l'historique des on/off de mon hysteresis dans les phases eco/confort. On a donc l'équivalent de ce qui est décris dans l'intro de l'article http://www.rhaaa.fr/regulation-pid-comment-la-regler-12 la réponse du système a deux valeurs de consigne

Encore d'accord !

Suite de mon idée, une fois en "mode PID", on utilise une approche similaire (utilisations des données eco/confort, transition ...) pour réajuster en continu les paramètres, donc je me moque totalement des conditions extérieures, je ne fais qu'observer la réponse sur une période donnée.

Mais là non, je pars du principe que j'ai 2 entrées pour 1 sortie. Les 2 entrées sont la température extérieure et l'état du radiateur et la sortie est la réponse de la pièce en terme de température.

Un petit écueil de dz, pas trivial d'avoir un historique de valeurs (entendu en s'appuyant sur des scripts time toutes les minutes) car je pense que dans le principe il faudrait stocker les données a chaque cycle (ou minute ?).

Dans ton lien vers http://www.rhaaa.fr il parle de GnuPlot, je vais voir de ce côté (en fonction du temps que je vais avoir à y consacrer bien sûr)

En me promenant sur le net hier soir, je suis tombé là dessus: https://hal.archives-ouvertes.fr/tel-01144024/document oops ... pas utilisable pour notre sujet mais lecture intéressante (pour qui s'intéresse aux automatismes s'entend ) Pour les parties IA, c'est pour lecture, je vois pas d'intérêt évident.

Rho la vache ! Merci pour le lien, ça va me rappeler des souvenirs de fac !!! (c'est ma femme qui va faire la gueule si j'me replonge là dedans ! (et dire que je suis là pour avoir une régul WAF... Je devrais avoir honte d'en rire... Mais on s'refait pas !

[Hawk49]

C'est ça, lancer le chauffage à la bonne heure c'est:
- du confort pour ne pas le lancer trop tard
- des économies pour ne pas le lancer trop tôt

Ton approche n'est pas forcément inverse à la mienne. En estimant les gains d'une part et les pertes de l'autre, on aurait une bonne idée de ce qu'il faut faire.
Plutôt que d'avoir un planning adaptatif, je pars sur l'idée d'avoir un planning avec mes exigences et ensuite l'algo va chercher l'heure du prochain changement de consigne et calcule (recalcule toutes les 10 min en fait), en fonction des conditions actuelles, l'avance qu'il doit prendre pour être à l'heure.

[Hawk49]

J'ai regardé un peu GNUPlot. C'est génial ! Le logiciel propose (outre l'affichage de courbes) de calculer une régression (autrement dit de nous aider à trouver une fonction qui colle aux données, reste à trouver la tête de la fonction)
Courbe avec des données temporelles: https://www.ukonline.be/programmation/g ... /page3.php
Régression: https://www.ukonline.be/programmation/g ... /page5.php

[rimram31]

...

Quand je pense que Kp ne dépend (pas trop) de la T extérieure et/ou conditions externes / bruit (de perturbation de la régulation), c'est qu'il intervient en % d'augmentation/réduction de la consigne (elle même un % mais de temps de chauffe) et pas une simple valeur brute de proportionnalité / température.

Là j'avoue que je ne te suis pas trop...

J'admet que je me suis fait quelques noeuds au cerveau ... ce que je veux dire c'est que le calcul du % de temps de chauffe se fait en Kp x delta T, delta T = T cible - T actuel. Il y va y avoir quelques "pas de temps PID" lors d'un changement de consigne, je vois que vil1driver plus haut a mis 10mn, il faut une bonne heure trente a 2h chez moi pour passer de 16 a 19° le matin, soit 6 a 10 "pas de temps", je me dis que si il fait froid dehors, ça va chauffer plus longtemps a 100%

Si tu mets un Kp trop agressif, en tout cas chez moi (radiateurs avec inertie => pierre), la conséquence sera un dépassement de consigne, comportement que j'ai régulièrement avec ma régulation actuelle, hystérésis, quand il fait vraiment froid. Je l'ai d'ailleurs expliqué plus haut je crois, j'ai triché pour compenser ce comportement en chauffant 1h un peu en avance: je chauffe dès 4h45 jusqu'a 6h, arret puis reprise a 6h30 -> 8h ca me permet en période froide d'être plus "smooth". Accessoirement ayant encore un abonnement HC/HP, je chauffe + en période creuse (au risque de déperditions ...)

[Hawk49]

En attendant mieux, je te donne la solution que j'avais mis en place pour éviter trop de retard le matin en cas de nuit très froide, ça pourrait t'aider à éviter ton dépassement.
Au lieu de demander 17 la nuit puis directement 20 à 7h par exemple, tu peux rajouter une consigne intermédiaire du genre 18 à 6h.
Ainsi, avec l'inertie de tes radiateurs, si tu dépasses le 18 c'est pas grave, tu te rapproche de la température voulue à 7h. Ça pourrait t'éviter d'arrêter la chauffe pendant 1h30 comme tu le fais actuellement et améliorerait le côté "smooth" que tu recherches (couplé au PID de vil1driver ça marche plutôt bien).

C'est pas encore optimal ni automatique mais ça se rapproche de ce que tu voulais faire je pense...

[rimram31]

@Hawk49 merci pour le tuyau.

J'ai récemment réinvesti (maigrement ...) dans du xiaomi aqara + sonoff "pour voir" et le pid fait partie des sujets que j'ai envie de reprendre.

On a donc le même matériel à gérer.
...

Un point que je voulais éclaircir ... et c'est une bonne, que dis-je, une EXCELLENTE nouvelle, les sonoff/tasmota supporte une tempo d'allumage -> PulseTime https://github.com/arendst/Sonoff-Tasmota/wiki/Commands

On peut donc dire a un relai sonoff/tasmotta, allume toi pour n secondes et il continue sa route de façon totalement autonome. Ca 'intéresse plus d'une fois car ça permet une sécurisation me concernant car je n'ai pas de fil pilote. Avec ce feature, je peux "piloter" en "allume toi pour x secondes", si ma box tombe, le radiateur s'éteindra tout seul quoiqu'il en soit.

Reste a voir comment utiliser la fonction de domoticz ...

Edit: variante (parce qu'après quelques essais ca a pas l'air hyper précis le truc ... heu ca a une horloge un esp8266 ???) mettre une PulseTime a une valeur de securité, style 10mn/la période choisie de chauffage. Du coup ça peut se faire a l'initialisation des modules, pas obligatoirement dans la programmation.

[soulflydeath]

bonjour,
je voudrais mettre en place ce script chez moi, mais j'ai comme un petit problème d’exécution du script ..
j'ai parcouru toute les pages et j'ai essayé de le faire fonctionner avec le matériel que j'ai sur mon domoticz.
description du matériel :
- une sonde xiaomi "Temperature_Cuisine" et sa passerelle intégré dans domoticz
- un radiateur avec fil pilote + module Qubino ZMNHJD1 (il remonte dans domoticz comme un dimmer % "Qubino_fil_pilote_cuisine" )
- un bouton virtuel "Radiateur_Cuisine" avec 4 ordres ( Off, HORS-GEL, ECO et CONFORT)
- un switch virtuel On/Off "Chauffage"
- un thermostat virtuel "Thermostat_Cuisine"

l'appel du script dans les événements domoticz :

Code : Tout sélectionner

-- Ce script permet réguler la température de la zone

-- chargement des modules
dofile('/home/pi/domoticz/scripts/lua/modules.lua')

--------------------------------
------ Variables à éditer ------
--------------------------------
local pid={}

pid['debug'] = true	-- true pour voir les logs dans la console log Dz ou false pour ne pas les voir
pid['zone'] = 'cuisine' -- nom de la zone pour affichage dans les logs et distinction de variables
pid['sonde'] = 'Temperature_Cuisine' -- Nom de la sonde de température
pid['OnOff'] = 'Chauffage' -- Nom de l'interrupteur virtuel de mise en route
pid['thermostat'] = 'Thermostat_Cuisine' -- consigne ou 'nom' de l'interrupteur virtuel de thermostat
-- actionneur
pid['radiateur'] = 'Radiateur_Cuisine' -- Nom de l'interrupteur de chauffage
pid['invert'] = false	-- si On et Off doivent être inversé ou non

-- PID
pid['Kp'] = 45 -- Coefficient proportionnel 
pid['Ki'] = 20 -- Coefficient intégrateur
pid['Kd'] = 45 -- Coefficient dérivateur

pid['cycle'] = 10	-- temps en minute d'un cycle PID
pid['secu'] = 30	-- temps mini en seconde entre 2 ordres opposés

--------------------------------
-- Fin des variables à éditer --
--------------------------------

commandArray = {} 
compute(pid)
return commandArray

j'ai essayé déjà comme ça et ça n'a pas fonctionné, j'ai juste eu dans les log :

Code : Tout sélectionner

2018-04-18 19:55:00.206 LUA: PID cuisine initialisation..
2018-04-18 19:56:00.260 LUA: PID cuisine initialisation..

Du coup en parcourant les pages j'ai vu un conseil sur le fait de jouer sur le % du dimmer "Qubino_fil_pilote_cuisine" avec Set Level dans le fichier modules.lua
j'ai mis la variable pid['invert'] = true
et j'ai modifié le modules.lua avec ce qui avait été donné comme conseil quelque page avant

Code : Tout sélectionner

	-- définition des commandes marche/arrêt
	if pid['invert'] then
		marche = 'Set Level 100' ; arret = 'Set Level 0'
	else
		marche = 'On' ; arret = 'Off'
	end

et j'ai mis pid['radiateur'] = 'Qubino_fil_pilote_cuisine' dans Evenement.

je me retrouve toujours avec

Code : Tout sélectionner

2018-04-18 20:04:00.174 LUA: PID cuisine initialisation..
2018-04-18 20:05:00.229 LUA: PID cuisine initialisation..

je me permet de venir demander de l'aide car je ne vois pas trop d'ou pourrait venir le problème
merci !

[Hawk49]

Salut soulflydeath,

Code : Tout sélectionner

pid['invert'] = false	-- si On et Off doivent être inversé ou non

Code : Tout sélectionner

	-- définition des commandes marche/arrêt
	if pid['invert'] then
		marche = 'Set Level 100' ; arret = 'Set Level 0'
	else
		marche = 'On' ; arret = 'Off'
	end

Tu mets pid['invert'] à false, du coup les commandes marche/arrêt sont "marche = 'On' ; arret = 'Off'"
--> essai avec pid['invert'] = true pour que tes modifications soient prises en compte !

Code : Tout sélectionner

2018-04-18 19:55:00.206 LUA: PID cuisine initialisation..
2018-04-18 19:56:00.260 LUA: PID cuisine initialisation..

Vérifie si des variables utilisateurs ont bien été crées, il n'y a qu'à leur création que init == 1 , ce qui produit le message "PID cuisine initialisation.."

et j'ai mis pid['radiateur'] = 'Qubino_fil_pilote_cuisine' dans Evenement.

Qu'est ce que tu veux dire quand tu dis "dans Evenement" ?