@Mimic33 a été plus rapide ! lol
Ca va régler ton soucis.
Quelle noob je fait ! Merci Beaucoup !
Bonjour à tous,
Je me lance pour piloter mes clim daikin…
Je suis en train d’étudier la solution de @Mimic33 … Tu es restée sur ta solution de décembre 2020 ? Car en avril 2021, tu dis l’avoir fait évoluer ? Ou ça ne concerne que la partie programmation via l’Agenda ? Sinon, toujours content de ta solution ?
Mais je regarde aussi la solution de @eleckito21 
Toujours content à l’usage ?
PS : Soyez indulgent, je débute 
Salut,
Effectivement j’ai tout passé sur des agendas l’année dernière, plus souple à utiliser je trouve. Derrière j’ai des modes qui gèrent l activation ou non des thermostats en fonction des modes sélectionnés été/hiver/mi saison et vacances/travail/absent/WE (1 thermostat par zone/saison/période).
J’ai ajouté quelques scénarios liés à l’utilisation des modes et de l’agenda pour relancer le chauffage au changement de mode de mémoire (ça commence à dater).
J’ai un scénario aussi qui tourne via Domogeek pour passer Travail/WE en auto.
Et j’ai rajouté 1 scénario pour maintenir la maison quand trop froid dehors le matin en hiver pour ne pas qu’elle descende trop bas dans la journée.
Tout fonctionne nickel de mon côté ça s auto gère 
Et je pilote a distance grâce à JeedomConnect.
J’ai toujours dans la tête d’intégrer le télétravail mais j ai du mal à m y mettre 
Hésites pas si besoin. 
Merci pour ton retour
Mais déjà pour la partie de base de la régulation, via thermostat/scénario, ce que tu as écrit au dessus est toujours d’actualité ? Les 3 scénarios…?
Il faut que je regarde aussi cette histoire de variable, car je n’en ai encore jamais intégré…j’avance…
PS : ça doit te faire un sacré nombre de thermostats…
Yes j ai toujours mes 3 scénarios allumage/off/envoi ordre, ça ça n a pas bougé.
Yes j ai 2 zones 3 modes périodes (Vac/WE/Travail) et 2 saisons (hiver/mi saison), la combinaison de tout ça fait quelques thermostats mais ils se ressemblent pas mal.
Bonjour @Miracle @Mimic33
Il semble que nous ayons les meme splits Daikin…
J’ai du mal à comprendre vos captures , et ne correspondent pas donc suite au manque d’info à l’attendu de mon systeme…
Je constate que certains utilise des scénarios en dehors des scénarios du thermostats …
En soit que certains appel d’autre scénario du plugin Thermostat…
Je m’y perd un peu , beaucoup même , ne ce serait ce qu’en déclencheur…
J’ai testé des scénarios appelé par le plugin Thermostat … mais rien n’y fait …
Le besoin :
Dans le salon , il y une « Sonde [Température][Principal][Température] » qui donne une température plus réel que la sonde Daikin (comme beaucoup je suppose) …
L’idée est de créer de une température de consigne sur le SPLIT Daikin selon la température de cette sonde…
Par la suite toujours le but est selon le mode ( ECO, CONFORT, ABSENCE) de passer le SPLIT à une consigne de X degrés selon la température de la SONDE SALON …
Je reste assez curieux sur la manière dont vous vous y êtes pris …
Actuellement
Le thermostat SALON est Configuré ainsi
Dans l’action ainsi :
Et dans le scénario :
Dans les MODES :
Dans le mode Confort (par exemple) : (le scénario PAC SALON CONFORT) :
Et le descriptif de son scénario :
Dans mon idée donc dans le scénario (Hors thermostat)
Si la sonde [Température][Principal][Température] donne moins de 20 :
- elle met en marche la pac
- Active le mode Chauffage
- Ordonne une consigne de chauffe de 24 …
Sauf que actuellement , la sonde [Température][Principal][Température] donne 19.5 et le la consigne de la PAC ne change pas toujours a 22.5 …
IDEM si la Sonde [Température][Principal][Température] donne 20 ou plus , elle ne modifie la consigne de la SPILT #[Climatisation][Clim Salon][Température (consigne)]#
Hier il me semblait avoir des logs , suite au clic droit / exécuter …
A ce jour pas de log … mais exécution selon Jeedom OK …
Pas de déclenchement selon AGENDA
Ni depuis le Widget : si clique sur Off pour passer en On , il ne se passe rien…
La température de la sonde
Je pense avoir poster au meilleur endroit , malgré les derniers post d’il y a 8 mois…
Cdt … Chris.
Bonjour
Sans vouloir trop m’avancer, pour le changement de consigne si la T°>20, je dirai que c’est ton déclencheur de scénario qui coince.
Ton scénario se déclenche si T°<20, ton SINON ne se déclenchera jamais puisque la T° sera toujours <20° vu que c’est la valeur attendue pour lancer ton scénario.
Je mettrais le déclencheur #[Température][Principal][Température]# sans valeur et après ton bloc si/sinon prend le relai pour savoir si T° > ou < à 20°.
Maintenant, pas sûr que ce soit une très bonne solution non plus, car ça veut dire que ton scénario va se lancer à chaque changement de température.
Bonjour @Nex008
Pardon pour le retour tardif , pas de notification de ta réponse…
J’ai abandonner le plugin thermostat…
En gros , j’ai créer 2 cas …
Présence ou non dans la maison …
La présence est contrôlé par l’état d’une caméra ( Armée ou non ) ou si l’état en ligne ( Ok ou nok ) d’un haut parleur ECHO STUDIO ( Blink ayant eu des problèmes de communications dans Jeedom)
Si présence KO , vérification que la maison ne tombe pas sous les X températures selon la pièce .
Si présence OK
Tout marche correctement avec le déclenchement comme suit :
Le scénario est modéré en demande de température , tenir la pièce principal à 21 malgré une hauteur de plafond de 3m50 , au milieu de toit 2 pentes //
Si besoin d’un coup de boost , j’ai créer 2 scénario qui bascule de Confort à Modéré :
Pour le moment je les lance depuis JeedomConnect , le lancement depuis une Scène Alexa , n’est pas performant pour le moment , il me semble que depuis le passage de tous les équipements sous Zigbee2Mqqt , Alexa réagi bien moins bien et rapidement , voir oblige la répétition que auparavant sous la Conbee2 et Deconz …
En résumé , ma PAC se gére automatiquement , selon la température , je ne touche plus du tout au commande , et la température reste « agréable à vivre » , le ressenti dépend ensuite de notre forme …
On constate sur cette dernière , la nuance entre la présence et l’absence …
Journée de repos la veille et travaillé ce jour .
Bonjour,
Tout d’abord merci à tous pour vos contributions, ça m’a permis d’y voir plus clair dans les gestions possibles thermostat/scénario pour les PAC air/air. Je viens d’en installer une chez moi (Mitsubishi+Melcloud), et je regardai pour l’intégrer à mon installation Jeedom. Je commence juste à faire fonctionner cette PAC, mais je partage avec vous l’option que j’ai retenu pour le moment, si ça peut en aider certains !
Comme vous, mon problème consistait à gérer les deux particularités principales de ces PAC :
- pas de possibilité de fonctionnement on/off par envoi de consigne allumage/extinction
- le fonctionnement des unités intérieures/UI (et indirectement unité extérieure/UE) qui comporte déjà leur inévitable régulation thermostatique basée sur une température de la pièce mesurée au sein de l’unité qui peut s’éloigner assez fortement de la température moyenne ressentie réellement dans la pièce
Ces PAC sont des systèmes sensibles, je souhaitais rester au plus proche de la régulation « fabricant », afin de garantir un fonctionnement optimisé des cycles thermodynamiques et leur adaptation aux besoins chaud/froid. Cela exclut évidemment un fonctionnement où je fais des marches/arrêts répétitifs (je ne compte en faire qu’un ou deux par jour). Mais cela implique aussi pour moi de perturber le moins possible la régulation interne de la machine : autrement dit je voulais éviter d’avoir une double régulation cumulée/successive « jeedom/thermostat » + « régulation UI » qui me semble pas forcément idéale (envoyer des +2° et des -2° pour arrêter/éteindre, ça fonctionne mais ça ne permet pas à la machine de bien connaître les besoins chaud/froid réels, ça permet d’éviter les problèmes et inerties associés à un simple on/off mais je suis pas certain que ça garantisse les meilleurs cycles et l’optimisation que la machine cherche à faire en interne ?). Et c’est dommage, parce que ces machines en inverter devraient permettre un fonctionnement souple et un maintien en température avec peu de variation dans la pièce une fois la consigne atteinte. Reste le problème de la sonde de température de l’UI qui s’écarte parfois fortement du réel.
Mon fonctionnement souhaité est donc :
-
- gestion par Jeedom de la consigne (et toutes les possibilités associées, modes, absence, saisonnalité, ralentis jour/nuit et autres programmations …)
-
- gestion par l’UI de son propre fonctionnement (appels de puissance à l’UE, vitesse ventilateur adaptée au besoin de puissance, …) en fonction de la consigne fournie par Jeedom
-
- mesures correctives pour compenser les écarts entre la sonde de température de l’UI et la température réelle de la pièce
Je n’utilise donc le plugin thermostat que comme une « façade », pour avoir une intégration facilitée/centralisée avec le reste de mes équipements, mais il n’aura pas vraiment de fonction de régulation puisque je laisse ça à la machine (je n’ai donc pas rempli d’ordre de chauffe ou d’arrêt). J’aurai pu passer par un scénario et un virtuel, mais je trouvais ça un peu plus simple pour gérer les modes, les contrôles des sondes de T° et les alertes associées/défaillances …
Pour corriger l’écart lié à la sonde interne de l’UI, j’ai opté pour une solution simple : j’envoie à l’UI une consigne qui tient compte de l’écart entre la température de la pièce mesurée par ma sonde bien placée et la température de la sonde de l’UI remontée par Melcloud. Par exemple, actuellement j’ai une consigne Jeedom de 21° dans la pièce, ma sonde mesure 20° mais l’UI (qui vient de chauffer pas mal) mesure 24° (soit 4° de plus que le réel), alors j’envoie la consigne de 25° à la machine, et je laisse la régulation de la machine faire son travail (monter de 1°).
Je passe pour cela par un scénario simple :
Dans mon cas, j’ai dû arrondir mon calcul à l’unité, sinon la machine de prenait pas en compte la consigne.
Ce scénario est déclenché par les changements de consigne, de température de la pièce (mesurée ou via l’UI).
La consigne vue côté UI s’adapte donc en permanence en fonction des écarts de la sonde interne. J’ai donc en permanence le même écart (consigne - température réelle) = (consigne adaptée UI - température UI)
Voilà, je suis preneur de vos avis, pour l’instant ça fonctionne plutôt bien, avoir dans le temps …
2 « J'aime »
Bonjour,
Ayant fait l’acquisition d’une clim réversible Toshiba il y a qlq semaines, j’ai rapidement vu la mauvaise régulation des splits, avec 2 voire 3 degrés degrés d’écart entre la demande et le réel.
Pour essayer de corriger cela, j’ai d’abord acheté un capteur de température + télécommande IR Smart Life, mais cela ne répondait pas à mon problème (beaucoup trop limité).
Puis je me suis tourné vers Jeedom. J’ai mis cela sur une Raspberry, la connexion SSH/SSL, et tout le reste ! Je ne pensais pas y arriver, mais ca fonctionne !! Je dois dire que je suis assez impressionné par le système et ses capacités.
En plus de cela, j’ai de la chance : j’ai une chaudière Saunier Duval avec thermostat connecté Migo qui dispose d’un plugin Jeedom et pareil pour la clim réversible Toshiba.
Du coup, le thermostat de la chaudière me sert de sonde d’ambiance (résolution de 0,1°C), et je pilote le split (pour l’instant salon seulement). J’ai regardé un peu la solution de [nico73], mais ca ne fonctionnait pas chez moi, la sonde du split est trop « aléatoire »…
Du coup, sur la même idée, j’ai fait un scénario qui tourne toutes les 10min, et qui fait office de régulateur PID. Je vous mets la séquence ici.
Le scénario tourne toutes les 10min, car ma sonde Migo est mise à jour toutes les 10min seulement. Donc on ne peut pas faire mieux…
Voici les étapes :
- Attendre qlq secondes (car la mise à jour de la sonde intervient après qlq secondes passé les 10min (d’après les logs), donc histoire de coller au plus près à la mesure), sauf si il y a un saut de consigne,
- Enregistrement de la consigne actuelle, pour savoir si il y a un saut au prochain cycle,
- Calculer l’erreur,
- Calculer la commande proportionnelle (gain en vert)
- Calculer la commande intégrale (gain en rouge)
- Arrondir l’intégral à qlq décimales (j’ai lu sur d’autres post que les décimales pouvaient générer des erreurs, mais il ne me semble pas que ce soit le cas ici…)
- Saturation de l’intégrale en + et - (en orange), sinon on aura des dépassements très importants, le temps que l’intégrale « se vide »…
- Calcul de la commande dérivée (gain en bleu)
- Enregistrement de l’erreur sur le cycle en cours (pour le calcul de la dérivé du cycle suivant)
- Calcul de la correction totale
- Saturation de la correction totale (pas forcement nécessaire)
- Calcul de la commande de clim, qui vaut : consigne de température + correction, avec arrondi à l’entier pour pouvoir envoyer un ordre acceptable par la clim (tous les 1°C pour moi, peut être que d’autres marques font mieux).
- Saturation des consignes pour la clim
- Enfin, ma clim gère les températures faibles via le mode « hors-gel », donc je fais cela si on est en dessous de 16.5°C.
Certaines formules commencent par « 1*… » car j’ai l’impression que si je ne le mettais pas, c’était parfois interprété en chaine de caractère (vu dans le suivi des variables).
Et du coup, ca fonctionne plutôt bien chez moi, je vous mets quelques vues.
Voila, j’ai trouvé un jeu de paramètre (Ki, Kp, Kd) qui fonctionne plutôt bien, même si il y a qlq dépassements. On peut faire mieux en saturant encore plus bas l’intégrale, mais du coup, le système sera moins performant si l’erreur « naturelle » de la clim est élevée (il est sensé accepter ~3°C d’écart avec ces paramètres).
Donc je trouve cela satisfaisant, pour un système piloté par pas de 1°C toutes les 10min…
Je laisse donc les curieux essayer, et me faire un retour si vous trouver un jeu de paramètre qui fonctionne mieux, ou toute autre amélioration.
J’ai 2 autres splits à réguler : un bureau et l’espace chambres (couloir). J’attends 2 sondes DS18B20 (commandées) que je vais mettre sur la Raspberry pour faire le pilotage. J’espère que ca fonctionnera bien aussi.
3 « J'aime »
Salut,
Merci pour ton partage
Cela fait un bon moment que j’avais fais un scénario pour ajuster la température de mon salon en fonction de la différence entre la consigne et la température réelle. Je procédais par augmentation de la consigne de la PAC puis relançait le scénario au bout d’un certain temps dépendant de la différence de température. Je n’ajustais jamais pour descendre la consigne de la PAC en revanche et je la laissais gérer. J’ai quand même l’impression que c’est mieux pour le compresseur … mais bon j’ai voulu tout de même essayer pour voir ce que ça donnait.
Je me suis un peu cassé les yeux sur la capture 
mais ça tourne
J’en ai profité pour passer la presque intégralité dans un bloc code histoire :
- de ne pas avoir des variables qui trainent pour rien et qui sollicite la base de données à chaque fois car il n’y a réellement que 2 variables nécessaires (ou 3 par rapport à ton wait que je n’ai pas repris chez moi)
- permettre une mise en place plus facile si d’autres veulent essayer
Du coup ça donne ça coté scénario :
Déclencheur sur changement de la consigne et sur variation de la température relevé par le capteur :
Le code :
$Consigne_Salon = cmd::byString('#[Maison][Gestion des PAC][ConsigneConfortSalon]#')->execCmd();
$Temperature_Salon = cmd::byString('#[Salon][Sensor Salon (MQTT)][Température]#')->execCmd();
$borne_min_integr = -2.6;
$borne_max_integr = 2.6;
$borne_min_total = -5;
$borne_max_total = 5;
$borne_min_pac = 15;
$borne_max_pac = 24;
$scenario->setLog('|----------------------------------------------------------');
$scenario->setLog('| Consigne Salon : ' . $Consigne_Salon . ' °C / ' . 'Temperature Salon : ' . $Temperature_Salon . ' °C');
$scenario->setLog('|----------------------------------------------------------');
$Correct_integr = $scenario->getData('Correct_integr',0);
$scenario->setLog('| .Correct_integr (valeur précédente) : ' . $Correct_integr);
$Correct_erreur_previous = $scenario->getData('Correct_erreur_previous',0);
$scenario->setLog('| .Correct_erreur_previous (valeur précédente) : ' . $Correct_erreur_previous);
$Correct_erreur = $Consigne_Salon - $Temperature_Salon;
$scenario->setLog('| .Correct_erreur : ' . $Correct_erreur . ' -> mémorisation de la valeur');
$Correct_prop = 2 * $Correct_erreur;
$scenario->setLog('| .Correct_prop : ' . $Correct_prop);
$Correct_integr = $Correct_integr + $Correct_erreur;
$Correct_integr = round($Correct_integr * 1000) / 1000;
$scenario->setLog('| .Correct_integr : ' . $Correct_integr);
$Correct_integr = max(min($Correct_integr, $borne_max_integr), $borne_min_integr);
$scenario->setLog('| .Correct_integr borné ['.$borne_min_integr.' / '.$borne_max_integr.'] : ' . $Correct_integr . ' -> mémorisation de la valeur');
$Correct_deriv = 1.5 * ($Correct_erreur - $Correct_erreur_previous);
$scenario->setLog('| .Correct_deriv : ' . $Correct_deriv);
$Correct_total = $Correct_prop + $Correct_integr + $Correct_deriv;
$scenario->setLog('| .Correct_total : ' . $Correct_total);
$Correct_total = max(min($Correct_total, $borne_max_total), $borne_min_total);
$scenario->setLog('| .Correct_total borné ['.$borne_min_total.' / '.$borne_max_total.'] : ' . $Correct_total);
$Temp_consign_clim = round($Consigne_Salon + $Correct_total);
$scenario->setLog('| .Temp_consign_clim : ' . $Temp_consign_clim);
$Temp_consign_clim = max(min($Temp_consign_clim, $borne_max_pac), $borne_min_pac);
$scenario->setLog('| .Temp_consign_clim borné ['.$borne_min_pac.' / '.$borne_max_pac.'] : ' . $Temp_consign_clim);
$scenario->setLog('|----------------------------------------------------------');
$scenario->setData('Correct_integr', $Correct_integr);
$scenario->setData('Correct_erreur_previous', $Correct_erreur);
$tags['#set_consign_clim#'] = $Temp_consign_clim;
$scenario->setTags($tags);
J’en ai profité pour modifier le comportement de mon module relevant la température pour qu’il :
- Transmette toutes les 5mn
- Transmette si changement de 0,1°C
- Modifié le paramètre de répétition des valeurs à Oui
Et au final, bien sûr ça donne une température bien plus constante dans la pièce 
Voilà le graphique pour comparer. Nous n’avons pas changé la consigne mais comme je ne l’avais pas historisée avant, je n’avais pas la courbe rouge avant les modifications.
Variation autour du 0 :
Note : j’ai 2 capteurs positionnés à 2 endroits différents et l’ajustement est réalisé sur celui qui est en bleu.
2 « J'aime »
Merci pour le partage. 
J’avais idée aussi de tester en mode code.
Mais j’ai pas eu le temps de tester.
Salut,
Je ne maitrise pas le code, donc je l’ai fait à ma manière… 
Pour le nombre de variables, je ne sais pas ce que cela implique en terme de ressources. Je n’ai que cela qui tourne sur ma RPI, donc ca doit passer. 
Pour ta solution qui a l’air de bien fonctionner, qlq questions et remarques :
- les termes intégrale et dérivé ont une dimension temporelle, vu qu’ils sont calculés par rapport à l’état antérieur. Donc si tu fais cela toutes les 5min (au lieu de 10min chez moi) tu dois diviser les termes Ki et Kd par 2 environ (à ajuster).
- Si en plus des 5 minutes, tu déclenches le calcul à chaque changement de mesures, il faut (idéalement) le prendre en compte dans les calculs. Donc pour être le plus propre possible, il faudrait enregistrer le temps écoulé entre 2 calculs, et le prendre en compte. Bref, je suggère de rester sur un pas de temps fixe (5 ou 10min), et éventuellement recalcul pour chaque changement de consigne (ce qui arrive plus rarement a priori) pour conserver la réactivité.
- Que donne ta commande envoyée au split ? Si elle fait des sauts limités à 1°C, ca doit être acceptable pour le compresseur, car il continue de fonctionner en modulant sa puissance. Si les sauts sont de ~3°C, il fera du on/off et c’est moins bon.
1 « J'aime »
Salut,
C’est une bonne habitude à prendre, bien sûr que ça ne va pas écrouler ton système mais prends l’habitude de n’utiliser les variables que quand il faut stocker pour une réutilisation ultérieur. A l’intérieur du scénario, à la place, utilise des « tag » (sauf donc pour les variables qui sont réutiliser à l’appel suivant. les tag ne sont pas enregistrés en base de données et ne sollicitent donc pas le disque.
Ah, ok ! Du coup :
- Ki je présume que c’est pour l’intégrale mais il faut diviser quoi par 2 ? Le 2 de Correct_prop (vu qu’il influ que l’integrale) ?
- Kd je présume que c’est pour dérivé donc là il faudrait que je tente plutôt avec 0.75 plutôt que 1.5 pour Correct_deriv
Ok, je vais donc repasser en déclencheur toutes les 5mn pour voir ce que ça donne.
Oui on peut envoyer des commandes par pas de 1°c
Salut,
Le gain intégrale est ici :
Donc oui, si tu le mets toutes les 5min, il faudrait mettre 0,5 (pour avoir le même paramétrage que moi), après peut-être qu’avec 1 ca fonctionne bien chez toi.
Oui, c’est ca.
Est-ce que tu peux superposer la commande envoyé au split sur tes courbes de températures ? Pour voir si la commande ne fait pas trop le yoyo avec des valeurs trop espacées… C’est comme ca qu’on verra que la regul et propre et pas trop sollicitante pour le compresseur.
A 14h j’ai remis une programmation toutes les 5mn en retirant le déclencheur.
C’est clairement moins fin :
Je viens de changer les paramètres : La moitié de l’intégrale et de la dérivé à partir de 21h35. A suivre.
$Correct_integr = 0.5 * ($Correct_integr + $Correct_erreur);
$Correct_deriv = 0.7 * ($Correct_erreur - $Correct_erreur_previous);
Ah oui, effectivement, le comportement est étrange…
Le 0.5 (Ki) est à mettre ici :
$Correct_integr = $Correct_integr + 0.5 * $Correct_erreur ;
OK j’ai modifié mais je doute que ça change vraiment la donne 
En attente sur la journée de demain et peut-être du retour de @Arnaud_69
Bonjour,
J’ai laissé le scénario initial et un déclencheur de 10 minutes.
Et comme je n’ai pas compris le fonctionnement du PID, je n’ai pas osé bricoler plus.
Ça a tourné hier et ce matin encore, j’en suis satisfait.
J’ai laissé la climatisation en soufflerie auto, et c’est la température de consigne qui fluctue.
Et de votre côté, vous laissez en auto aussi ?
Je vais surveiller surtout aujourd’hui :
Que donne ta commande envoyée au split ? Si elle fait des sauts limités à 1°C, ca doit être acceptable pour le compresseur, car il continue de fonctionner en modulant sa puissance. Si les sauts sont de ~3°C, il fera du on/off et c’est moins bon.