Aller au contenu

Felig

Membres confirmés
  • Compteur de contenus

    71
  • Inscription

  • Dernière visite

Réputation sur la communauté

18 Good

À propos de Felig

  • Rang
    Membre interessé

Profile Information

  • Sexe :
    Homme
  • Ville :
    Le Vesinet - Ile de France
  • Intéret :
    GEA
  • Box
    Home Center 2
  • Version
    4.60

Visiteurs récents du profil

551 visualisations du profil
  1. Felig

    Heating Manager - PID and more

    PID POUR LES NULS Si vous êtes comme moi, vous ne connaissez rien aux théories de régulation, et vous voulez avant tout un thermostat clé en main qui ne demande pas d'expertise, comme le SRT321. La bonne nouvelle c'est qu'un thermostat PID marche plutôt bien même avec des paramètres "au pif". Mais après plusieurs semaines d'utilisation, j'ai acquis un peu d'expérience pratique qui pourra vous être utile si vous recherchez une régulation (et une consommation) optimisées. Ce n'est que de la pratique, donc par avance mes excuses aux experts (l y a plein de littérature et d’équations complexes sur Wikipedia). Le fonctionnement de Heating Manager (développé initalement par Olivier Meyer) est le suivant : toutes les 15 minutes (délai réglable), le programme va allumer le chauffage pendant une durée comprise entre 0% et 100% du cycle (50% = radiateur allumé pendant 7m30s, etc.). Ce paramètre qu’on appellera POWER est la somme de trois « moteurs » : P, I et D (Proportionnel, Intégrale et Dérivée). Pour comprendre comment fonctionnent ces 3 moteurs, il faut imaginer que votre radiateur est un véhicule sans freins, qui grimpe une route de montagne, qui doit atteindre le plus rapidement possible un point précis, et ensuite s’y maintenir sans bouger. Tant que le véhicule est loin du point d’arrivée, il roulera à sa vitesse maximum (POWER 100%). Mais en approchant, il devra ralentir progressivement (souvenez-vous, il n’a pas de freins). A partir de quelle distance du point devra-t-il ralentir ? C’est ce qui est déterminé par le moteur P : P = Kp x distance. Vous pouvez modifier le paramètre Kp pour chaque radiateur. Quelle est la valeur optimale pour Kp ? Exemple : Supposons Kp = 50. Si la température est de 18.1° et la consigne est de 20°, on aura P = Kp x distance = 50 x 1.9° = 95%. Le radiateur sera donc allumé 14m15s sur un cycle de 15m. Si on avait fixé Kp à 100, la "vitesse" ne se réduirait qu'au-delà de 19°. Conclusion: Avec une valeur de Kp à 50, la décélération commence dès que la distance est inférieure à 2°. Si Kp =100, la décélération commence quand l'écart entre la consigne et la température < 1°. La valeur Kp idéale dépend de l’inertie de votre radiateur. Si votre radiateur est un camion (radiateur moderne), Kp doit être plus faible. Si votre radiateur est un scooter (radiateur électrique « grille pains ») Kp doit avoir une valeur élevée. La surface à chauffer entre aussi en compte: dans une grande pièce un radiateur aura moins d'efficacité, et il vaut mieux un Kp élevé. Dans une petite pièce avec un radiateur moderne j'ai mis Kp à 50. Dans la suite parentale, je trouvais les temps d'ajustements un peu longs, et j'ai augmenté à 100. Plus Kp est élevé, plus le radiateur sera réactif. Je vous conseille de commencer avec 100 et de baisser si le radiateur a tendance à dépasser la consigne au lieu de converger. Si le radiateur est peu puissant, une valeur supérieure à 100 sera sans doute plus adaptée. N'ayez pas peur de faire des erreurs : un Kp trop faible va faire que le radiateur mettra plus de temps à atteindre l’objectif (rien de grave), un Kp trop élevé va le conduire à le dépasser un peu (rien de grave non plus). Note: Le paramètre Kp est surtout important en cas de changement fréquent de consigne: si la consigne est stable, le paramètre Kp aura peu d'impact. Supposons maintenant que la température est parfaitement alignée avec la consigne à 20°. On aura une distance égale à 0 et donc P = 0. Et pourtant, si le radiateur ne chauffe pas, la température va baisser, et on va s’éloigner de l’objectif. Rappelez-vous, le véhicule est sur une route de montagne : s’il n’accélère plus, il va reculer. C’est là qu’intervient le deuxième moteur : I = Ki x cumError. Ce moteur est intelligent car il doit s’ajuster en fonction de la pente de la route. S’il fait très froid dehors il faudra un moteur puissant pour maintenir la température. La température extérieure étant variable, ce paramètre doit s’auto ajuster en permanence. Cet auto ajustement se fait tout seul par le paramètre cumError (somme des erreurs) : à chaque cycle, le programme va regarder à quelle distance il est de l’objectif (erreur = distance) et ajuster sa valeur en conséquence. Quelle est la valeur optimale pour Ki ? Exemple : Supposons Ki = 5 et cumError = 5. On a donc I = 5x5 = 25%. A la fin du cycle, supposons que la température soit 0.5° en-dessous de l’objectif, on ajoute cette erreur à la somme des erreurs précédentes, ce qui donne cumError = cumError + 0.5 = 5.5 ; le programme va donc chauffer un peu plus (I = 5 x 5.5 = 27.5% au lieu de 25% au cycle précédent). Le paramètre I s’ajustant tout seul, la seule chose que vous pouvez déterminer c’est la vitesse à laquelle il va s’ajuster, avec le paramètre Ki. Si Ki est trop faible les ajustements vont être progressifs, et il faudra plus de cycles avant d’atteindre la température parfaite. Si Ki est trop élevé, les ajustements vont être brusques et vous risquez de dépasser l’objectif. Là aussi, le plus simple est l’expérience : regardez comment votre thermostat se comporte quand il est proche de l’objectif, et s’il met trop de temps à converger, augmentez Ki. Chez moi (radiateurs électriques modernes) je trouve que ça fonctionne bien avec 6. N'ayez pas peur de faire des erreurs, de gros ajustements ont un impact limité et Madame ne verra sans doute pas de différence. Le troisième moteur D est moins important : il réagit en fonction de la variation des erreurs (c’est une sorte de dérivée) et en pratique son impact est minime chez moi. J’utilise un coefficient Kd de 3 (probablement trop faible), mais j’avoue que pour l’instant pas trop vu l’intérêt de ce facteur. Il est peut être plus important pour des chauffages avec une énorme inertie. En résumé, deux messages importants : 1) Ne soyez pas inquiets. A moins de valeurs extrêmes, il n’y a pas de mauvaise valeur pour vos coefficients Kp, Ki et Kd. N’ayez pas peur de garder les valeurs par défaut ou de faire au pif, et vous verrez que le résultat sera quand même très bon. L’optimisation c’est bon pour les geeks comme moi qui râlent quand le thermostat reste pendant 2 heures à 19.9° alors que la consigne est 20°! Le thermostat SRT321 que nous utilisons tous a des coefficients en dur qui ne sont pas optimisés pour votre pièce, et ça ne l’empêche pas d’être efficace. 2) Have fun. Si vous êtes un peu geek, c’est intéressant de voir comment les cycles de chauffe s’ajustent en fonction de la température extérieure. On mesure mieux les problèmes d’isolation, via le % d'activité des radiateurs (qui peut être affiché sur un virtual device). Et c’est satisfaisant de battre les (rares) thermostats PID du commerce avec juste quelques lignes de code (la régulation PID tient sur moins de 10 lignes).
  2. Felig

    Heating Manager - PID and more

    @Dgille Désolé de l'apprendre, j'espère que ce n'est pas grave, et tous mes vœux de rétablissement rapide. J'en profite pour partager ma version de Heating Manager, développée en parallèle de la tienne, mais incluant ton ajout sur la régulation PID notamment. Je n'ai pas intégré la partie Anticipation de Chauffe. Mes modifications sont résumées dans les notes de version, mais en gros j'ai ajouté la possibilité de piloter HM avec un virtual device dans chaque pièce (soit pour récupérer la consigne du thermostat, soit pour afficher des infos sur le taux d'activité des radiateurs, soit les deux) (possibilité qui était dans la version originale de O Meyer mais dans un format différent). J'ai beaucoup travaillé sur la robustesse et la simplification du code (je l'utilise pour mon chauffage, et Madame ne plaisante pas avec ça!) et pour ceux qui aiment comprendre ce que fait le programme, il y a la possibilité d'activer une option "debug" qui donne beaucoup (trop) d'infos. Le troisième axe d'amélioration est la régulation PID, avec notamment un cycle propre à chaque radiateur, ce qui permet une synchronisation sur les temps de réveil de la sonde de température de la pièce. Il y a aussi des petits ajouts de confort comme la possibilité de déclencher des événements en fonction de l'heure, ou la possibilité de configurer les pièces en utilisant leur nom plutôt que leur ID. Je ne connaissais rien à PID avant, mais honnêtement le résultat est impressionnant: la température dans la chambre parentale reste constante au dixième de degré près. Je suis sûr que c'est mieux que le STR321 qu'on ne peut pas vraiment adapter à chaque pièce. L'autre grand avantage de HM par rapport au STR est qu'en cas d'ouverture de fenêtre par exemple, le temps de réaction est immédiat, pas la peine d'attendre le réveil du thermostat pour transmettre une nouvelle consigne. Et le retour d'infos donnés par le programme est intéressant et très utile pour optimiser la consommation: quand il fait froid dehors, on se rend compte que baisser la consigne de 0.5° a un gros impact sur le taux d'activité des radiateurs. PS: Si vous souhaitez tester le programme sans perturber votre système de chauffage actuel, il y a une option "simulation". Pour l'utiliser vous devez quand même paramétrer au moins un radiateur existant (si le radiateur n'est pas valide le programme vous avertira et n'ira pas plus loin). Dans ce mode le programme ne touchera pas aux radiateurs, mais ça permet de tester si votre configuration est valide, y compris pour les événements. C'est une version pour HC2 (je n'ai pas encore de HC3). Heating Manager PID 4.01.lua
  3. Felig

    Heating Manager - PID and more

    Autre sujet plus intéressant: Sur la régulation PID (j'ai mis du temps à comprendre le fonctionnement), j'ai testé une modification que je trouve assez efficace: au lieu de calculer l'erreur cumulée (CumError) comme étant la somme des [10] dernières erreurs*, je la calcule comme la somme cumulée de toutes les erreurs. Ça simplifie le programme (pas la peine de mémoriser les 10 dernières erreurs, on mémorise juste la somme, et on ajoute la dernière erreur*). Mais surtout ça évite d'avoir des données faussées par la sortie de l'erreur la plus ancienne de l'échantillon à chaque cycle, qui peut compenser l'impact que devrait avoir la dernière erreur. Bref, je trouve que ça donne un meilleur résultat. A tester. (*) pour les non spécialistes en langage PID, erreur = différence entre la température actuelle et la consigne du thermostat
  4. Felig

    Heating Manager - PID and more

    Bonjour @Dgille et merci pour ce gros travail. Un thermostat sans PID on est d'accord ça ne vaut rien! J'avais de mon côté aussi amélioré le programme de Olivier Meyer pour l'adapter à mon environnement, et le rendre plus convivial (je suis un maniaque des messages dans la console qui expliquent ce que fait le programme). Du coup j'ai passé pas mal de temps à fusionner ma version avec la tienne, ce qui m'a permis de trouver quelques bugs supplémentaires: 1) dans addHeater() j'ai remplacé if (self.HMCF.kP.start) par if isnil(self.HMCF.kP.data[tostring(idHeater[1)]) 2) Toujours dans addHeater, j'ai remplacé properSonde = isnil(idSonde), par properSonde = isnotnil(idSonde), 3) dans setIndoorSonde(), il y a une typo: j.TemperatureSonde doit être remplacé par j.temperatureSonde 4) dans checkConfiguration / checkRoomArray(), j'ai remplacé checkRoom(room) par err = checkRoom(room); if isnotnil(err) then return err end (err est bien mis à jour dans la fonction checkRoom, mais ce n'est pas renvoyé dans la fonction checkConfiguration) 5) de même, dans checkConfiguration / checkCondition() j'ai remplacé checkVariable(condition[1]) par local err = checkVariable(condition[1]); if isnotnil(err) then return err end et checkDevice(condition, 5, true) par local err = checkDevice(condition, 5, true); if isnotnil(err) then return err end 6) Enfin, dans startHeater() j'ai remplacé _f:call(item.heater, "pressButton", item.actions[1]) par _f:call(item.idHeater, "pressButton", item.actions[1]) Voilà, rien de grave, vu que dans la majorité des configs ces lignes de code ne seront pas utilisées, mais si ça peut être utile pour le développement de la QA
  5. Felig

    Support Gea

    Un VD a été développé pour trouver les ID de portables (désolé je ne sais plus par qui), mais en voici une copie que j’utilise. Elle ne fonctionne qu'avec les portables iOs, mais je suppose qu'il y a un équivalent pour Android. Fais une recherche sur le forum. IOS_Info_v1.00.json
  6. Felig

    Support Gea

    Je n'ai pas de vanne chez moi, et je ne sais pas quel module tu utilises, mais en général, la valeur du thermostat d'un module est dans une propriété spécifique (pour la différencier des valeurs de température ou de durée de consigne manuelle notamment). Essaie ceci: GEA.add( {{"Value+", id["BUREAU_VANNE_THERMO"], 12}}, 10, "", {"ThermostatLevel", id["BUREAU_VANNE_THERMO"], 10}, "Changement consigne thermostat" ) Je te conseille la lecture du fichier syntaxe_GEA. Il y a des commandes pour augmenter la température de 1° par exemple. Si ca ne marche pas il faudra trouver le nom de la propriété dans le json du module et la changer directement avec la fonction "Property"
  7. Felig

    Support Gea

    @971jmd Les premiers guillemets ont effectivement toujours été là. A l'origine GEA était surtout conçu pour envoyer des notifications via email ou push (genre "porte de garage ouverte depuis 30 minutes!") donc les "" ont été inclus dans la syntaxe de base, même s'ils sont rarement utilisés aujourd'hui. Les deuxièmes "" sont relativement nouveaux (ca doit se compter en années quand même ?): ils servent juste à indiquer ce que GEA fait dans le log console, ça permet de mieux suivre ce qui se passe en cas de pb. Le premier "" est obligatoire mais tu peux supprimer les deuxièmes: ils sont optionnels.
  8. Felig

    Support Gea

    @SGBVida Tu crées un script dans une scène "Test" du genre: device = 323 local value = fibaro:getValue(device, "value") fibaro:debug('Current value = '.. tostring(value)) -- turn On fibaro:call(device, "turnOn") fibaro:debug("Envoi commande turnOn et attente 1s") fibaro:sleep(1000) value = fibaro:get(device,"value") fibaro:debug("=> Nouvelle valeur = "..tostring(value)) -- turn Off fibaro:call(device, "turnOff") fibaro:debug("Envoi commande turnOff et attente 1s") fibaro:sleep(1000) value = fibaro:get(device,"value") fibaro:debug("=> Nouvelle valeur = "..tostring(value)) Tu peux aussi consulter le json du device: http://192.168.1.xxx/api/devices/323 (rechercher le champ "value")
  9. Felig

    Support Gea

    Oui, il faut bien les 3 lignes. Et pour répondre à ta précédente question @SGBVida c'est plus propre d'avoir une commande pour chaque action (éviter les OR). Comme Lazer j'ai une seule scène GEA avec une centaine d'instructions et ça marche parfaitement. Pour ta lumière, elle est peut-être sur variateur. Essaie ceci (changement dans la 3è ligne: value 1 remplacé par value+ 0) GEA.add({ {"Value", id["BUREAU_MOTION"], 1}, { "Value-", id["BUREAU_LIGHT"], seuilLuminosite}, {"Time", "07:00", "21:00"}, {"Days", "WeekDays"} }, -1, "", {"turnOn", id["BUREAU_LUMIERE"]}, "Bureau Présence détectée -> allumage de la lumière (Semaine)") GEA.add({ {"Value", id["BUREAU_MOTION"], 1}, { "Value-", id["BUREAU_LIGHT"], seuilLuminosite}, {"Time", "10:00", "21:00"}, {"Days", "WeekEnd"} }, -1, "", {"turnOn", id["BUREAU_LUMIERE"]}, "Bureau Présence détectée -> allumage de la lumière (Week end)") GEA.add({ {"Value+", id["BUREAU_LUMIERE"], 0}, {"Value", id["BUREAU_MOTION"], 0} }, 10*60, "", {"turnOff", id["BUREAU_LUMIERE"]}, "Plus de mouvement -> extinction lumière")
  10. Felig

    Support Gea

    @SGBVida Le fait que le déclenchement ne soit pas instantané est normal. GEA fait un check toutes les 30 secondes, donc ça peut prendre au maximum 30 secondes. Si tu veux un déclenchement instantané, if faut remplacer le 0 par -1, et ajouter '123 value' en-dessous de %%properties au début du script de la scène (remplacer 123 par l'id de BUREAU_MOTION). Regarde les pages précédentes, gorn avait un cas similaire. Ensuite tout dépend de ce que tu veux faire. Tu peux faire une extinction automatique de la lampe au bout d'un certain délai sans mouvement. Par exemple: GEA.add({ {"Value", id["BUREAU_MOTION"], 1}, { "Value-", id["BUREAU_LIGHT"], seuilLuminosite}, {"Time", "07:00", "21:00"}, {"Days", "WeekDays"} }, -1, "", {"turnOn", id["BUREAU_LUMIERE"]}, "Bureau Présence détectée -> allumage de la lumière (Semaine)") GEA.add({ {"Value", id["BUREAU_MOTION"], 1}, { "Value-", id["BUREAU_LIGHT"], seuilLuminosite}, {"Time", "10:00", "21:00"}, {"Days", "WeekEnd"} }, -1, "", {"turnOn", id["BUREAU_LUMIERE"]}, "Bureau Présence détectée -> allumage de la lumière (Week end)") GEA.add({ {"Value", id["BUREAU_LUMIERE"], 1}, {"Value", id["BUREAU_MOTION"], 0} }, 10*60, "", {"turnOff", id["BUREAU_LUMIERE"]}, "Plus de mouvement -> extinction lumière")
  11. Felig

    Support Gea

    @Domodial Dans ma version 6.11F (postée page précédente) j'avais fait la correction de l'appel d'API mentionée par Lazer. Mais si tu fais un upgrade autant passer à la version 6.13 (que je n'ai jamais testée).
  12. GEA a toujours créé les variables globales au lancement mais il y a eu un changement de la syntaxe de création de variables globales (isEnum=0 doit être remplacé isEnum=false) qui a fait bugger GEA, avant que la syntaxe soit corrigée dans 6.13. J'avais fait la correction dans ma version 6.11 et ça marche.
  13. Felig

    Support Gea

    Bravo. Tu verras en faisant tes tests que la lumière disparait avant l'heure officielle du coucher du soleil, et apparait après (le délai exact dépend des nuages). C'est pour ça que j'utilise Sunset-20 et Sunrise+20. Have fun.
  14. Felig

    Support Gea

    @gorn Ok, j'ai trouvé, la ligne 2019 correspond au chargement des plugins GEA. il faut que tu effaces la variable globale "GEA_Plugins". Je te conseille d'effacer toutes les variables GEA en fait. Elles seront recréées au premier lancement de GEA.
  15. Felig

    Support Gea

    @flacon030 Essaie ceci (remplace 98 par le numéro de ta scène) GEA.add( {"Time", "17:25"}, 0, "", {"DisableScenario", 98}, "Désactivation scène") GEA.add( {"DisableScenario", 98}, 30, "", {"EnableScenario", 98}, "Activation scène")
×