Felig

Ok, désolé Jojo. Mais je pense que c'est un bug de GEA. J'en ai trouvé un autre petit, de formatage:

Bonjour, J'ai un problème avec la règle suivante: GEA.add({"Breached", "Alarme"},-1,"INTRUSION",{"Email","admin","Intrusion détectée","Alarme Fibaro"},"INTRUSION") Quand l'alarme est déclenchée, GEA se lance bien en mode event, mais il ne trouve pas de règle à exécuter. J'ai le message d'erreur suivant: [29.07.2022] [01:42:10] [TRACE] [QA_GEA_28]: ---------------------------------------------------------------------------------------------------- [29.07.2022] [01:42:10] [TRACE] [QA_GEA_28]: GEA 7.37 started by event: mode alarm #2 Alarme breached [29.07.2022] [01:42:10] [TRACE] [QA_GEA_28]: ---------------------------------------------------------------------------------------------------- [29.07.2022] [01:42:10] [WARNING] [QA_GEA_28]: No entry to check in automatic mode [29.07.2022] [01:42:10] [WARNING] [QA_GEA_28]: No entry for this event Alarm[2], please remove it from header En mode non instantané (si je remplace -1 par 0), la règle s'exécute normalement. Vous avez une idée ? Merci d'avance

Merci, c'est intéressant. J’utilisais une variable globale pour mémoriser le profil précédent, mais c'est plus élégant comme ça.

Je savais que c'était possible pour GEA 6 j'avais écrit quelques options custom, pour sélectionner un label par son contenu notamment, mais j'avais pas encore testé sur GEA 7. Je vais le faire. J'ai une addiction pour le débogage et les améliorations inutiles désolé, je vais essayer de me contrôler. J'avais aussi amélioré quelques messages dans les logs (une autre de mes maniaqueries), mais sur GEA 7 pas besoin, tu as fait un super boulot, ils sont clairs et esthétiques.

Bonjour, Ci-dessous une suggestion pour la fonction de contrôle de "sleep". Ça ne change rien au fonctionnement, mais ça permet d'avoir des messages d'erreur plus explicites dans mes tests: sleep = {name = "Sleep", control = function(duree, option) if type(duree) ~= "number" then return false, string.format(self.trad.not_number, duree) end return self:getOption(option).control() end, Pour tester j'ai utilisé: GEA.add(true,0,"",{"sleep","10",{"Global","varxxx","Test"}},"Test Sleep 1") GEA.add(true,0,"",{"sleep",10, {"Global","varxxx","Test"}},"Test Sleep 2")

@LazerJe crois qu'il y a un pb avec la fonction de contrôle de quickapp. La voici en développé: en cas d'id multiples, seule la première id est contrôlée (il y un return dans tous les cas après la première id): control = function(id, method) if type(id) ~= "table" then id = {id} end for i=1, #id do local check, message = self.options.number.control(self:findDeviceId(id[i])) if check then return type(method) == "string", string.format(self.trad.not_string, method) else return check, message end end end, Par contre, ça dépasse mes compétences de trouver la correction à apporter...

J'ai créé un autre utilisateur que admin, et c'est la même chose: l'ID du mobile fonctionne pour fibaro.alert("push" ..) mais pas l'ID utilisateur. Par contre, pour fibaro.alert("email" ...) il faut bien utiliser l'ID utilisateur, (on n'a pas d'autre option de toutes façons) et ça fonctionne.

Merci, je ne connaissais pas non plus. J'utilisais la méthode suivante, qui fonctionne toujours sur ma HC3, mais je vais changer: c'est beaucoup plus propre d'utiliser les ID utilisateurs plutôt que les ID mobiles. local mobileList = {28, 34} function push(message) for _, id in pairs(mobileList) do fibaro.call(tonumber(id), "sendPush", message) end end EDIT: En fait j'ai l'impression que fibaro.alert prend comme arguments les ID des mobiles et non celles des users comme suggéré dans le post de @idomotique. Si je tente ça, j'ai aucun résultat (2 est l'id de l'user admin, et il y a bien un mobile associé avec les notifications activées): fibaro.alert("push", {[1] = 2}, "test") Alors que si j'utilise l'ID du mobile (29), ça marche: fibaro.alert("push", {[1] = 29}, "test") Je suis le seul à avoir un bug avec les ID users ?

En parlant de typo, j'en ai trouvé une dans le code LUA de la v 7.37 (pour les rares qui utilisent la version anglaise): il faut remplacer les messages "doesn't exists" par "doesn't exist" (4 occurrences).

Merci Lazer! je vais corriger.

Pour ceux qui connaissent HC2 mais débutent en HC3, voici des réponses aux principales questions que je me suis posées ces derniers jours. Rien de nouveau, tout est sur le forum (et en plusieurs exemplaires !) mais l'idée est de faire un post avec les principes de base et questions fréquentes (actualisé si besoin en fonction de vos commentaires/corrections), pour les débutants en HC3 qui comme moi sont très mauvais avec les moteurs de recherche. Sources et liens essentiels: ils sont indiqués par @Lazer ici. Un grand merci à lui, beaucoup de mes apprentissages viennent de ses posts. Qu'est-ce qu'un QuickApp (QA) ? Un QA est 3 composants en 1 : Un script LUA, qui peut être organisé en plusieurs fichiers: par exemple un fichier pour votre programme principal ("main"), un fichier pour une librairie de tools, un fichier pour la config utilisateur, etc. Pour utiliser une fonction du fichier tools, il suffit de l'appeler par son nom dans l'onglet principal. Pour créer un nouveau fichier, cliquer sur l’icône Files dans la marge à gauche de l'interface UI. Un module virtuel (device). Contrairement aux VD de HC2, le module virtuel d'un QA simule un module physique (interrupteur, détecteur, sonde, etc.). C'est pour ça que chaque fois qu'on crée un QA il faut choisir le type de device associé. En fonction du type, vous aurez des propriétés ("lastBreached" pour un détecteur par exemple), des icônes, et une interface utilisateur spécifiques équivalentes à ce que vous auriez pour un QA physique du même type. L'idée est que ce module virtuel soit piloté par la HC3 de la même manière que s’il était réel, via des appels fibaro.get(), fibaro.getValue(), fibaro.call() et même via l’API. Le grand avantage est que vous pouvez personnaliser et modifier son « micro-programme » et son interface (UI), ce qui n'est pas possible pour un module réel. La liste des types disponibles et propriétés associées est ici (fichier excel à la fin du post). C'est aussi si besoin une interface (UI) avec des labels, boutons, sliders, comme un VD de HC2. Attention, l'interface par défaut dépend du type de device que vous sélectionnez à la création du QA (cf. ci-dessus). Chaque composant est optionnel. Comme illustré ici il est possible d'avoir des modules QA qui fonctionnent sans une ligne de code (pilotés par des calls externes). Et inversement, si vous n'avez pas besoin de module virtuel, vous pouvez sélectionner l'option "Appareil désactivé" ("Device disabled") dans l'onglet "Avancé" du QA : le QA ne pourra plus être appelé par des calls fibaro, mais le programme LUA fonctionnera normalement et l'interface UI aussi (par contre j'ai l'impression que ça fait disparaitre le QA de l'interface mobile, donc pas forcément une bonne idée...). Comment fonctionnent les variables persistantes dans un QA ? Dans HC2, si on veut une variable persistante, on a le choix entre un label de VD ou une variable globale. Les variables globales existent toujours dans la HC3, elles sont gérées par les fonctions fibaro.getGlobalVariable(var) et fibaro.setGlobalVariable(var, value). Par contre les labels de QA ne sont plus persistants (réinitialisés à chaque démarrage du QA), et leur contenu n'est pas facile à lire (pas de fonction fibaro, il faut passer par le JSON du QA). Mais heureusement ils sont remplacés par les "variables QA" (« quickVars ») : des variables persistantes, mais internes au QA. Ces variables sont gérées par les fonctions QuickApp:getVariable(var) et QuickApp:setVariable(var, value). A noter : Si la "quickVar" n'existe pas, QuickApp:getVariable() renverra une valeur "" et non nil. Il y aura juste un warning dans le log du QA si la variable n'existe pas. Si vous utilisez QuickApp:setVariable() sur une quickVar qui n'existe pas, elle sera créée. Les quickVars peuvent aussi être créées, modifiées ou supprimées dans les paramètres du QA (onglet Variables). MAIS : toute valeur saisie manuellement dans l’interface Web sera convertie en format string (« 99 » au lieu de 99). Pour utiliser un autre format (numérique ou table), il faut utiliser QuickApp:setVariable(). Il est possible de récupérer le contenu des quickVars d'autres QA par des fonctions détournées (mais ce n'était pas l'intention des développeurs). Les variables globales HC3 peuvent être gérées dans l'onglet Variables du menu Réglages/Général (basique, mais j'ai mis du temps à le trouver!). Comment fonctionnent les fonctions dans un QA ? Compte tenu de ce qui précède, ça ne devrait pas vous étonner qu’on ait deux types de fonction : les fonctions normales de n’importe quel code LUA (function test(x) return x+x end) et les fonctions QuickApp qui sont ajoutées au code du module virtuel (son « micro-programme » pour reprendre mon image initiale). L’intérêt principal des fonctions QuickApp est qu’elles sont appelables par d’autres QA. L’autre intérêt est que chaque QA vient avec des fonctions déjà existantes qui sont bien utiles (ex : QuickApp:debug(), QuickApp:getVariable(), etc.). La fonction de gestion de l’interface UI notamment est une fonction QuickApp. Le QA simule une logique de langage orienté objet. Pour faire un parallèle avec Python (le seul langage orienté objet que je pratique un peu), QuickApp est une classe qui contient des fonctions (ou méthodes) mais aussi des variables (QuickApp.id est l'id du QA par exemple). Au sein d'une fonction QuickApp les autres fonctions et variables du QA peuvent être appelées par self:fonction() ou self.variable. L’appel d'une fonction d’un autre QA se fait via fibaro.call(id, "maFonction", arg1, arg2, etc.). L'inconvénient de cette méthode est qu'il n'y a pas de retour (pas de confirmation de succès, ni possibilité de renvoyer une variable au QA d'origine). Là aussi, il est possible de régler le problème par des contournements, comme expliqué ici. Comment est structuré le code LUA d’un QA ? La structure normale du code LUA d’un QuickApp est comme suit : Le code est exécuté une première fois de haut en bas. C'est l'occasion de déclarer les variables et fonctions. Ensuite, le QA lance la fonction QuickApp:onInit() si elle existe. C'est dans cette fonction que votre code doit commencer normalement. Voici un exemple (fonctionne avec un QA de type "multilevel sensor", qui accepte des valeurs numériques pour sa propriété "value"): function QuickApp:turnOn() -- appelable par fibaro.call(id, "turnOn") self:updateProperty("value", "99") afficheValeur(self) end function QuickApp:turnOff() -- appelable par fibaro.call(id, "turnOff") self:updateProperty("value", "0") afficheValeur(self) end function afficheValeur(self) self:debug("Valeur du module "..self.id.." : "..self.properties.value) end function QuickApp:onInit() self:debug("onInit - Démarrage du module "..self.id) --afficheValeur(self) setTimeout(function() afficheValeur(self) end, 0) end Contrairement au code des VD HC2, le code des QA ne s’exécute qu’une seule fois. Si vous souhaitez une boucle, il faut créer une fonction mainLoop() appelée via une fonction setInterval(). Tout est expliqué ici. Pourquoi on voit souvent l'instruction setTimeout(function() maFonction(self) end, 0) à la fin de la fonction QuickApp:onInit() ? C’est expliqué ici. En résumé, ça permet d’avoir accès à une variable LUA globale « quickApp » qui contient toutes les propriétés et méthodes de la classe QuickApp (instanciation), mais qui ne s’initialise que si la fonction QuickApp:onInit() est terminée. Même si on n'utilise pas cette variable, c'est une bonne habitude de laisser la fonction QuickApp:onInit() se terminer avant de lancer la fonction suivante.

Oui désolé j'avais édité car je l'ai trouvé entre temps (je suis en version anglaise, il fallait chercher Rollershutter et pas Blind). Merci pour l'astuce fichier texte, je ne savais pas que les fqa étaient en mode texte, ça va bien simplifier les choses et m'éviter de poser d'autres questions bêtes. Voici une image pour expliquer ce que je veux dire avec Integration (probablement un pb de langue français/anglais encore): EDIT: Grâce à ton astuce fichier texte, j'ai trouvé: "Integration" semble correspondre à "com.fibaro.deviceController"

Merci Lazer, je suppose que le hack est en manipulant device.properties.viewLayout dans le json du QA. J'avais commencé à regarder mais je ne vais pas me lancer là-dedans effectivement. Autre question d'un hyper-débutant de la HC3: les QA que j'importe du forum (ex: GEA) sont souvent de type "Integration" mais je ne retrouve pas ce type dans le menu déroulant quand je veux créer mon propre QA ?

Bonjour, Je me suis inspiré de ce QA pour tenter de piloter mes volets (qui sont gérés par un autre protocole: RTS Somfy). A chaque volet correspond un child device. Je voudrais pour chaque child device ajouter 3 boutons (Monter, Baisser, Stop), mais je n'y arrive pas. Quand je les ajoute manuellement avec la fonction edit et que je sauvegarde ça semble être OK, mais si je rafraichis la page ils disparaissent, comme si l'UI du child device était verrouillé. Je me demandais aussi si on pouvait ajouter les boutons directement lors de la création du child device (qui se fait par code lua, via la fonction ci-dessous): function QuickApp:createChild(name, open, close, stop) local child = self:createChildDevice({ name = name, id_open = open, id_close = close, id_stop = stop, type = "com.fibaro.rollerShutter", }, MyChild) self:debug("Child device "..name.." created: "..child.id) end C'est mon premier QA donc désolé si j'ai raté un truc évident.

Merci pour ces retours d'expérience, j'avais pas pensé au maillage réseau. Je vais effectivement attendre de bien maitriser les QA et d'avoir réécrit et testé toutes mes scènes avant de migrer en masse.

Oui je voulais commencer par ré inclure certains modules à la mano, mais je me demandais si je pouvais ensuite migrer les modules résiduels (les fils pilotes notamment). Mais j'imagine qu'on ne peut pas mélanger car les modules migrés pourraient avoir le même id que ceux déjà inclus à la mano, ce qui créerait un conflit. Merci pour l'astuce sur les QA qui remplacent un module, ça sera plus simple pour tester ma scène de thermostat. Sur ce coup là il faut que j'ai tout migré et testé avant l'hiver sinon madame ne me pardonnera pas.

Bonjour, Je viens de commander une HC3 et suis assez tenté par une installation propre, d'autant que j'ai pas mal de scènes et VD à réécrire comme Lazer, et que j'aimerais transférer les modules de manière étalée dans le temps pour tester les nouvelles quickapp. Deux questions: - est-ce que je risque d'avoir des problèmes avec les fils pilotes que j'avais eu un mal fou à inclure dans ma HC2 ? de mémoire l'inclusion sous HC3 n'était pas plus facile à l'époque - quand on fait une migration, est-ce que ça écrase les éventuels modules existant dans la HC3 (dont j'aurai besoin pour mes tests) ? Merci d'avance

Merci Lazer, je suis malheureusement bien au courant de ces pbs d'inclusion, ça m'avait pris une matinée pour inclure 2 malheureux fils pilotes, et les astuces partagées sur ce forum m'avaient été très précieuses à l'époque. Je réagissais juste aux notifications de Fibaro après la dernière MAJ, qui me recommande de reconfigurer les modules dont la configuration est "incomplète". Je ne me souvenais plus si j'avais ces messages avant, mais visiblement il n'y a rien de nouveau, donc je ne touche à rien! La prochaine étape sera le les transférer sur la HC3 que je viens de commander, mais je comprends que ça ne devrait pas poser de pb une fois qu'ils sont reconnus par la HC2.

Bonjour, Tous mes fils pilote Qubino sont dans la liste des device à reconfigurer. J'avais eu du mal à les faire accepter par la HC2, donc j'hésite un peu. Est-ce que vous savez si un template est disponible maintenant pour ces modules ?

Désolé, je n'ai pas consulté le forum pendant plusieurs mois, et là je me prends une grosse baffe avec cette nouvelle si triste, que David a visiblement vu venir et à laquelle il a su se préparer avec beaucoup de simplicité et de dignité de ce que je peux percevoir dans ses messages. On ne se connaissait pas, mais j'ai beaucoup travaillé sur son programme, et c'est comme construire quelque chose ensemble, ça crée des liens, d'autant que je viens de réaliser que nous avons pratiquement le même âge. Je n'ai pas encore osé passer à la HC3, car j'ai une config compliquée et plein de programmes à réécrire (y compris un GEA avec plusieurs fonctions personnalisées) mais c'est prévu dès que j'aurai quelques semaines de vacances, et je compte bien travailler sur son QA. Notre collaboration n'est pas finie! David, repose en paix, et merci pour tout ce que tu as partagé. @BertrandD Merci d'avoir partagé cette nouvelle avec nous.

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).

@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

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

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

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