Felig

Merci Jojo. Il y a des trous dans les logs donc j'ai pas une vision complète. Entre 1h49 et 1h59 la température est à 17.5, et la radiateur chauffe à fond, donc pas de pb de régulation a priori, mais j'ai pas les lignes avant pour comprendre comment la température est descendue, ni les lignes après pour voir si le chauffage a un impact sur la température au bout d'un moment. La ligne suivante commence à 3h50 et la température est toujours à 17.5, et le radiateur est à fond mais là aussi j'ai que 10 minutes. Si le radiateur a chauffé à fond entre 1h59 et 3h50 sans que la température bouge il y a peut-être un pb d'isolation, mais ça semble bizarre. En ce qui concerne l'affichage, je n'ai rien changé, c'est un bug de Yubii : si tu es en mode climatisation il affiche une seule consigne, alors qu'en mode chauffage il ajoute un OFF. Pour le message [INFO] en 1ère ligne c'est un message temporaire, qui disparait des que tu changes de consigne. Mais c'est vrai qu'il n'est pas super utile. Sur la 5.20.09, tu peux tester l'arrêt et redémarrage par GC par exemple (avec envoi consigne "Off"). Tu peux aussi vérifier que tes réglages de température sont conservés en changeant de version (j'ai changé les variables). La ligne 2 a aussi légèrement changé (le % moyen de chauffage reste affiché même quand le radiateur est éteint). Le reste c'est des changements mineurs. voici mes notes de version: 5.20 - Régulation PID améliorée (cumError -> LastI) (5.20.04) - Arrêt radiateurs plus robuste (cancel stop) (5.20.04) - Fonctions log / notify plus robustes (5.20.04) - Effacement messages warnings expirés (clearInfo) (5.20.04) - Mode Off persistant après un reboot (variable Status) (5.20.04) - Variable HM_Data remplacée par PID_Data (5.20.06) - Suppression des variables non utilisées (deleteOldvar) (5.20.06) - Affichage températures maintenu en mode Off (self.isOff) (5.20.06) - Bug: item.lastTemp actualisé même quand thermostat off (5.20.07) - Affichage temps de réveil capteur au démarrage, même si nul (5.20.08) - Affichage item.power sur UI même quand radiateur éteint (5.20.08) - Ajout paramètre wakeUp dans addHeater (5.20.08) - Valeurs min-max pour Kp, Ki, Kd et wakeUp (5.20.08) - Variables Confort,Eco,Manuel,Vacation regroupées -> variable Modes (5.20.09) - Valeurs anciennes variables transférées vers nouvelles (5.20.09) - Thermostat sort du mode Off quand reçoit consigne externe (5.20.09) - Possibilité d'éteindre thermostat via consigne externe "Off" (5.20.09)

Je vais regarder pour le bouton Set si j'arrive à l'intercepter. Perso je préfère appuyer sur un seul bouton sans confirmation, mais on peut prévoir un paramètre pour choisir sa préférence. Pour le bouton Manuel ça va prendre trop de place sur les petits écrans. Je peux indiquer emoji nom et durée, ou emoji nom et consigne, ou emoji consigne et durée (sans doute le mieux, je vais tester). Il y a eu un truc étrange cette nuit sur ton graphe. Le QA commence à ralentir à 18.5, et il commence à se stabiliser à 18, et puis brusquement il décroche à 17.5. Si tu as les logs de la prochaine nuit (sans interférence du soleil) et en showDebug 1 pour avoir une longue période regroupée, ça serait parfait. J'en profite pour partager la dernière version (pièce jointe supprimée, la dernière version est disponible en téléchargement sur la première page)

Merci Jojo, j'ai copié ton log, tu peux l'enlever de ton post (pour faciliter le scrolling du forum). Je veux bien à l'occasion un log quand la température est proche de la consigne (désolé, après j'arrête, promis!). D'après les logs, ton Google Calendar envoie la consigne 20, et non pas "Confort". Avec GEA moi j'ai bien l'affichage suivant:

Merci Jojo! Je veux bien un fichier log (en showDebug 1) pour voir comment la régulation fonctionne dans le nouveau système. Tu as des cycles courts ce que je n'ai pas chez moi, donc tes tests sont très instructifs. Et si tout va bien je publierai une version stable dans le premier post.

Si tu ne connais pas la fréquence de mise à jour, je te conseille de fixer HMCF.minCycle à 900 dans le fichier config. Tu as les changements de température dans les logs, ça te donnera peut-être une idée. Le QA essaie de se synchroniser avec les remontées de température (le début du cycle est calé sur la dernière remontée) mais ça ne marche que lorsque le temps de réveil est connu. Il va falloir que je prévoie une option pour le saisir manuellement.

Je ne connais pas les Zigbee Aquara mais normalement le QA s'ajuste en fonction du temps de réveil du capteur. Il faut juste que le temps de réveil soit de 15 minutes max. Si le temps de réveil n'est pas disponible dans 'properties.wakeUpTime' (ce qui j'imagine est possible avec Aquara) le QA va croire que le capteur n'a pas de temps de réveil, et dans ce cas il faut forcer le temps de réveil réel dans HMCF.minCycle (fichier config). Pour tester, il suffit de regarder les logs au démarrage. Si le QA fonctionne sur des cycles courts (pour l'instant le minimum est 3 min, mais je l'ajusterai peut-être en fonction des tests faits actuellement par jojo, car ça me semble un peu court pour du chauffage classique), c'est que le QA n'a pas trouvé le temps de réveil du capteur.

Première question: Oui. Et si l'id du radiateur change, il repartira de zéro aussi (l'apprentissage est lié à l'id du radiateur). Deuxième question: Oui aussi. Il faut que ce soit strictement > 0 et < 100. EDIT: Grâce à tes logs j'ai identifié un pb dans le calcul de D. Peux-tu remplacer par cette version stp: (pièce jointe supprimée, la dernière version est disponible en téléchargement sur la première page)

Oui c'est un point que j'ai identifié aussi entre-temps. Par défaut quand le programme n'a pas d'historique PID (nouvelle installation), il démarre avec une valeur de 0 pour I (qui détermine le ratio de chauffage quand on est à la consigne). Ensuite il va l'augmenter avec l'apprentissage, et la bonne valeur sera conservée en cas de reboot bien sûr. Dans les prochaines versions il démarrera à 20%, ce qui est une valeur arbitraire, mais probablement plus réaliste en moyenne, et qui accélérera un peu l'apprentissage.

Oui je n'utilise plus le fichier tools depuis la 5.19, tu peux le supprimer. En fait quand le thermostat est off, le QA est stoppé, et donc il ne fait plus les routines de vérification des températures. Mais je vais voir si je peux faire autrement. EDIT: Voilà, essaie cette version stp. (pièce jointe supprimée, la dernière version est disponible en téléchargement sur la première page)

La valeur minimum de Ki c'est 1 pour l'instant, mais en réfléchissant le mettre à zéro ça sert pas à grand chose, Ki ne ralentira pas le chauffage. Si Kp est très élevé, le rôle de Ki et Kd deviendra négligeable. Si Kp = 200, le chauffage sera à 100% jusqu'à 0.5° sous la consigne. Si Kp = 100 => 1°. Le programme n'apprend que lorsqu'il est autour de la consigne, i.e. quand l'activité de chauffage est supérieure à 0 et inférieure à 100%. Dans ton exemple, si le système est à 20° et que tu met une consigne qui ne sera jamais atteinte, ça n'affectera pas son apprentissage. Et si il atteint les 12° il ajustera son apprentissage pour stabiliser les 12°. Le "GEA" à la fin ne sert qu'à indiquer d'où vient la consigne. C'est un texte qui sera repris sur l'UI et dans les logs pour que l’utilisateur comprenne pourquoi la consigne a changé, et quel programme en est à l'origine (cf. exemple). C'est un paramètre facultatif, si il est manquant il sera remplacé par "System". Voici une version bêta à tester. J'ai fait beaucoup de changements donc il y a surement des trucs à corriger. Principaux changements: système de régulation PID plus robuste (source: ici). système d'arrêt des radiateurs revu, et le mode Off (thermostat et radiateurs éteints) est maintenant préservé après un reboot. Pour bien tester, ne met pas Kd à zéro stp, la nouvelle régulation modifie le mode de calcul de D. HCM v520.lua Merci!

Il y avait cette possibilité dans le programme d'origine, mais je l'ai supprimée par simplification. En théorie PID n'est pas le mieux quand on a des changements importants de consigne, mais il fait très bien le boulot quand même. Et tu peux obtenir quelque chose qui ressemble à de l'hysteresis en mettant Ki et Kd à zéro (j'ai bloqué la possibilité de mettre Ki à zéro pour l'instant mais c'est facile à changer): Si Kp = 50 (Ki=0, Kd=0) et la consigne est 20°, le thermostat aura le comportement suivant: Température <= 18° : chauffage à 100% Température 18.5° : chauffage à 75% Température 19° : chauffage à 50% Température 19.5° : chauffage à 25% Température >= 20° : pas de chauffage Si Kp = 100 (Ki=0, Kd=0) et la consigne est 20°, le thermostat aura le comportement suivant: Température <= 19° : chauffage à 100% Température 19.5° : chauffage à 50% Température >= 20° : pas de chauffage Si Kp = 200 (Ki=0, Kd=0) et la consigne est 20°, le thermostat aura le comportement suivant: Température <= 19.5° : chauffage à 100% Température >= 20° : pas de chauffage Donc pour ta salle de bain, si tu met un Kp élevé le thermostat va rapidement dépasser la consigne avec l'inertie, mais comme tu ne cherches pas une température précise, pourquoi pas. Pour revenir sur ta cave à vins, ça m'intrigue le comportement de ta clim. Est-ce que c'est du au fait qu'il lui faut plus de délai entre une commande on et off pour la laisser reposer ? Il n'y a pas moyen de la commander par fil pilote (moins brutal que on/off)? Il faut peut-être tester des cycles un peu plus long genre 4 minutes, même si on aura le pb de la température qui remonte très vite quand elle est off. Et qu'est-ce qui a changé par rapport à la période ou on n'avait pas de grosses oscillations ? J'ai une nouvelle version que j'aurais bien aimé que tu testes, mais ça serait mieux si c'était avec un radiateur plus facile à contrôler.

Merci Jojo. C'est intéressant mais très bizarre. On dirait que la clim. ne répond pas bien aux commandes de mise en marche. Sur ce cycle de climatisation de 3 minutes (donc au maximum), on ne voit aucun effet sur la température, qui continue à monter: [31.01.2023] [14:04:47] [DEBUG] [QUICKAPP846]: [REGUL] Cave Vins|Cave_AirCo : C 13°C | T 13.7°C | Début clim. 2m 58s [31.01.2023] [14:07:17] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 13.7°C => 13.8°C [31.01.2023] [14:07:47] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 13.8°C => 13.9°C Alors que sur d'autres cycles le fonctionnement semble beaucoup plus normal: [31.01.2023] [19:13:47] [DEBUG] [QUICKAPP846]: [REGUL] Cave Vins|Cave_AirCo : C 13°C | T 13.4°C | Début clim. 2m 36s [31.01.2023] [19:13:57] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 13.4°C => 13.6°C [31.01.2023] [19:14:47] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 13.6°C => 13.4°C [31.01.2023] [19:15:17] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 13.4°C => 13.1°C [31.01.2023] [19:15:47] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 13.1°C => 12.9°C [31.01.2023] [19:16:17] [DEBUG] [QUICKAPP846]: [INFO ] Cave_AirCo : Modif. Température 12.9°C => 12.6°C [31.01.2023] [19:16:24] [DEBUG] [QUICKAPP846]: [REGUL] Cave Vins|Cave_AirCo : Arrêt climatisation J'aurais tendance à penser que c'est lié au fonctionnement de ta clim, mais ça n'explique pas pourquoi on n'a pas ce problème avec l'ancienne version. Tu peux la réinstaller et vérifier que ça se stabilise? Si c'est le cas je veux bien un log et le fqa de l'ancienne version pour comparer le code.

J'avais fait une modif sur la fonction d'arrêt des radiateurs sans la tester. Ça devrait être corrigé, j'ai mis à jour les fichiers dans le premier post.

Ça ce sont les logs avec la précédente version du code non ? Je crois que j'ai trouvé quelque chose de mon côté, je posterai la version corrigée ce soir.

Tu as les logs correspondant à ces variations ?

HEATING & COOLING MANAGER - THERMOSTAT PID POUR LA HC3 (QUICKAPP) Je démarre un nouveau sujet pour que la dernière version soit plus facile à trouver. Le Heating Manager original a été développé par @OJC pour la HC2, et adapté ensuite par @Dgille pour la HC3. J'ai réécrit une grande partie du code pour essayer de le fiabiliser et le simplifier mais les ajouts les plus visibles sont l'interface QuickApp (utilisation mono pièce) et la possibilité de piloter des climatiseurs (demande spéciale de @jojo). J'ai enlevé les modes de régulation non PID et ajouté quelques fonctions de sécurité (recherche d'un autre capteur de température si le capteur par défaut n'est plus valide, test intensif de la configuration au démarrage, etc.). Il y aussi beaucoup de messages dans les logs pour suivre ce qui se passe (pour ceux que ça intéresse). Ce QA est dédié à @Dgille qui a continué à le développer sur son lit d'hôpital pour nous alors qu'il se savait condamné. Remerciements à @jojo d'avoir pris le temps de le tester et pour toutes ses suggestions très utiles. HCM peut être commandé facilement par GEA, mais il est aussi possible de configurer des événements spéciaux qui imposent une consigne prioritaire dans certaines conditions (par exemple consigne fixée à 5° tant qu'une fenêtre est ouverte). Une fois l'événement terminé, la consigne précédente est rétablie et l'utilisateur peut reprendre la main. Il est aussi possible de le piloter par une zone de climat (ex. panneau de chauffage). Un mode "simulation" est disponible si vous voulez le tester sans perturber votre installation actuelle. Voici le fichier à télécharger pour une première installation: HCM.fqa Pour mettre à jour votre version actuelle sans modifier votre configuration, remplacez le contenu du fichier 'main' par: HCM v520.19.lua Attention, le fichier config a été modifié à partir de la 5.20.13 (remplacement de la fonction HM:setIndoorSensor par HM:setRoomSensor). Si vous upgradez d'une version antérieure, il est conseillé de mettre à jour votre configuration en utilisant ce modèle: config new.lua Voici le mode d'emploi complet (inclus dans le fqa, dans l'onglet 'help'): HCM help Et enfin le guide de démarrage rapide (première partie du mode d'emploi): ===================================================== HEATING & COOLING MANAGER - GUIDE DE DEMARRAGE RAPIDE ===================================================== Ce QuickApp est un thermostat PID dédié à une seule pièce. Par défaut, le QA utilisera le capteur de température de la pièce. Ce capteur doit avoir un temps de réveil de 15 min max. Pour le configurer, tout se passe dans l'onglet 'config' en suivant ces 3 étapes: 1) CHAUFFAGE OU CLIMATISATION ? Par défaut ce QA gère des radiateurs. Pour gérer des climatiseurs, vous devez utiliser le paramètre suivant dans les USER SETTINGS du fichier 'config': HMCF.coolingDevice = true -- false : chauffage, true : climatisation 2) PERSONNALISATION DES MODES Grâce à l'interface du QA (UI), l'utilisateur pourra alterner entre 5 modes de consigne. Il y a 4 modes à consigne fixe pré-configurés: Confort, Eco, Vacances, et Manuel. L'utilisateur peut via l'UI ajuster la consigne pour chaque mode (ex: 21.5° pour le mode Confort) avec les touches + et -. Cependant, vous pouvez fixer une valeur min et max pour chaque mode avec les réglages suivants dans USER SETTINGS: HMCF.range.Confort = {19, 22} -- Valeurs {min, max} pour le mode Confort HMCF.range.Eco = {10, 21} -- Valeurs {min, max} pour le mode Eco HMCF.range.Vacation = { 5, 5} -- Valeurs {min, max} pour le mode Vacances HMCF.range.Manuel = { 5, 23} -- Valeurs {min, max} pour le mode Manuel Contrairement aux autres modes, le mode Manuel a une durée limitée, fixée par défaut à 2h. Une fois ce délai écoulé, la consigne précédente sera automatiquement rétablie. Vous pouvez ajuster la durée du mode Manuel ici: HMCF.manualTimer = 2*60 -- Durée maximum (en minutes) du mode Manuel Le mode Auto permet que la consigne soit gérée par une source externe, comme une zone de climat. Pour la zone de climat 1 par exemple, utilisez le paramètre suivant: HMCF.modeAuto = "#1" Le mode Auto peut aussi être associé à variable globale, ou même un autre thermostat. Des exemples sont disponibles dans la section UTILISATION AVANCEE ci-dessous (chapitre 4 PERSONNALISATION AVANCEE DES MODES). Si vous ne configurez pas le mode Auto, il sera par défaut équivalent au mode Confort. 3) CONFIFURATION DES RADIATEURS / CLIMATISEURS Chaque appareil (si il y en a plus d'un dans la pièce) doit être ajouté dans la section HEATERS CONFIGURATION du fichier config avec la fonction HM:addHeater(). Dans la plupart des cas, le seul paramètre nécessaire est son id: => Ex: HM:addHeater({id=145}) -- ATTENTION: un seul appareil par commande HM:addheater() Par défaut, chaque appareil est commandé avec les commandes "turnOn"/"turnOff" et son retour d'état est vérifié avec la propriété "value". Si votre appareil n'est pas standard, des paramètres optionnels sont disponibles (cf. UTILISATION AVANCEE). Si votre radiateur a un thermostat intégré, assurez-vous de le régler sur une valeur toujours supérieure à la consigne maximum de votre pièce. Par exemple, si vous chauffez votre chambre entre 18° et 22°, le thermostat du radiateur doit être fixé à 23°. Voilà! Votre Thermostat PID est configuré et prêt à être utilisé.

@Phil1789 le post s'adresse à des gens qui sont très à l'aise avec le concept de Virtual Device dans la HC2, ce qui était mon cas. Pour moi un VD c'était juste des ligne des code avec une interface, et je ne comprenais rien au concept de QA, auquel on devait donner un "type" quand on le créait. Par contre, si tu as programmé des VD, et que ça te semble obscur, ça veut dire que j'ai été trop rapide, et en me relisant c'est vrai qu'il n'y a pas beaucoup d'exemples. Si tu as des suggestions de concepts à éclaircir, ou un exemple de QA que tu veux développer, je compléterai le post initial.

C'est dommage de gâcher une ligne juste pour ça. J'ai une meilleure idée. Cf. ci-joint. HM HC3 Cool.lua

Voici une version modifiée à tester. Je n'ai pas mis la deuxième icône (le soleil dans ton exemple) car il y a déjà pas mal d'infos à afficher sur cette ligne (si le mode manuel est activé par GEA il y aura le compte à rebours + la source GEA par exemple) et je pense que l'utilisateur se fiche des étapes intermédiaires (il n'y a que moi que ça intéressait!). Les événements sont aussi affichés sur la même ligne. HM HC3 Cool.lua

J'utilise la ligne 2 quand certains modes sont imbriqués (tu peux tester en modifiant la ligne comme suit HM:setModes({Auto="Confort"}) dans le fichier config et ensuite sélectionne le mode Auto). La ligne 2 sert aussi quand un événement est en cours (Fenêtre ouverte); mais je dois pouvoir faire sans, en affichant les événements dans la dernière ligne. C'est vrai que dans 99% des cas la ligne affiche 2x la même chose, dis-moi ce que tu veux mettre à la place.

Ok. Tu peux me dire si tu as toujours des problèmes d'emoji avec cette version ? HCM v517.lua A ta disposition pour la simplification de l'UI.

Oui je vais ajouter ce paramètre par défaut dans config. Le cycle détermine la fréquence à laquelle la clim. est démarrée. A la fin de chaque cycle le programme regarde la température, analyse l'erreur par rapport à la consigne, et en déduit la durée de chauffage/climatisation sur le prochain cycle. Le cycle doit être supérieur ou égal au temps de réveil du thermomètre (le programme le vérifie au démarrage). Tu as un thermomètre sans temps de réveil, donc on peut faire des cycles courts, la seule contrainte c'est les appareils qui n'apprécient pas d'être allumés ou éteints trop souvent (comme ta Daikin qui refuse de s'allumer tout de suite après avoir été éteinte). Dans le QA, par défaut la durée d'allumage minimum d'un radiateur est de 30 secondes. Avec un cycle de 3 minutes, tu devrais avoir une période de clim de 1 minute environ toutes les 3 minutes environ d'après les logs, donc ça devrait être bon.

Pour répondre à ta question sur pourquoi la clim est arrêtée quand le thermomètre est au-dessus de la consigne, c'est normal. Dans les logs tu vois aussi l'inverse: la clim se déclenche même quand la température est inférieure à 13°. C'est pour tenir compte de l'inertie: quand tu déclenches la clim ça met du temps à faire effet, donc il ne faut pas attendre que la temp. remonte trop. Et inversement, quand tu arêtes, il y a un peu d'inertie normalement. Mais en l’occurrence l'inertie est super faible chez toi: quand on arrête la clim, la température continue à baisser pendant même pas une minute et ensuite remonte vite. Essaie d'augmenter Kp à 100 et Ki à 6 stp, ça rendra la régulation plus agressive, voyons si c'est mieux. Et si les changements ne sont pas flagrants essaie Kp=150 ou 200. On est dans une configuration avec quasiment pas d'inertie. L'autre solution c'est d'avoir des cycles plus courts. J'ai mis une durée minimum de 5 minutes, pour éviter d'allumer et d'éteindre les appareils tout le temps, mais pour de la clim ça semble trop long. Ajoute la ligne suivante dans ton fichier config pour passer à 3 minutes: HMCF.minCycle = 3*60 -- min. duration (sec) of PID cycle (Default: 5*60)

Entre-temps j'ai trouvé le bug de la version 5.16, donc ça tu peux laisser tomber. C'est corrigé dans la version ci-jointe. Pour les oscillations ça ne m'étonne pas, le problème n'est pas seulement que le thermomètre ne reporte que les changements de 0.5°, c'est que la température change très vite, ce qui dans une configuration de chauffage normale n'est pas le cas. Mais ça serait intéressant d'avoir des logs sur quelques heures (avec showDebug=1 pour éviter le spam) pour voir comment la régul travaille. HM HC3 Cool.lua

Ok, de mon côté je vois 2 choses qui restent à régler: 1) le reboot de la HC3: si tu as le temps est-ce que tu peux faire un reboot manuel et vérifier si tu as aussi le pb du thermostat qui se met sur off ? - Si ça bloque est-ce que tu vois un log au démarrage ? - Si ça ne bloque pas ça veut dire qu'un reboot automatique est plus violent qu'un reboot manuel, c'est pas intuitif, mais je testerai chez moi 2) la version 5.16 qui refuse de démarrer: est-ce que c'est réglé ? D'après les logs il y a un problème dans la fonction addheater. Est-ce que tu peux poster ton fichier config en format file (pour éviter le pb des emoji) (ou carrément le fqa si plus simple) et j'essaierai de reproduire le bug chez moi. Merci!