Felig

Oui, c'est mieux si tu le précises. Bonne semaine!

Salut Jojo, Tu peux confirmer que tu as bien le paramètre suivant dans le fichier config de ta salle de bain: HMCF.turnOffNoTemp = false -- turn off heaters if max delay is exceeded Sinon pour le paramètre wakeUp, j'avais mis une valeur max pour permettre au cycle PID de se synchroniser avec celui du capteur de température. Mais ce n'est pas strictement nécessaire, du moment que la sonde envoie des mises à jour en cas de changement de température. Par contre il faut que le délai d'avertissement sur l'absence de remontée de température soit toujours supérieur au temps de réveil. C'est ce que j'ai modifié dans la version jointe (si tu peux la tester). HCM v520.18.lua

Ok. J'avais une autre solution en tête qui est plus simple à programmer: le % sera ajusté en fonction du thermostat - à 17° ou en-dessous le % sera égal à 0 - à 24° ou au-dessus le % sera égal à 100% C'est simpliste mais c'est mieux que de couper dans ton cas de figure. Pour répondre à tes questions: HMCF.checkDelayTemp = true -- warn if temperature has not been updated for some time Si ce paramètre est false, le délai de la dernière remontée ne sera jamais vérifié (pas de warning, pas d'action). Ce n'est pas un nouveau paramètre, il était déjà dans le programme principal. Le fonctionnement actuel c'est 'true' (valeur par défaut). HMCF.maxDelayTemp = 12*60 -- max delay between 2 temperature updates (minutes) Oui c'est pour paramétrer le délai pour les warning et l'action éventuelle. Ce n'est pas un nouveau paramètre, il était déjà dans le programme principal. J'ai juste modifié la valeur par défaut de 8h à 12h. HMCF.turnOffNoTemp = true -- turn off heaters if max delay is exceeded C'est un nouveau paramètre. Si ce paramètre est true, c'est le fonctionnement actuel. Si tu le met à false, on aura le comportement que j'ai décrit ci-dessus (100% à 24°, 86% à 23°, 71% 22°, etc.) J'ai du modifier un peu la structure du programme. Il y a maintenant deux méthodes pour calculer le % d'activité, et le dépassement du délai ne rend plus la température mesurée invalide. C'est pour ça que ça mérite quelques tests. HCM v520.16.lua

Bonjour Jojo, Non ce n'est pas du tout saugrenu. J'ai les mêmes messages que toi de temps en temps donc je comprends. Ta première suggestion est ajoutée dans le version ci-jointe. Ta deuxième suggestion est un peu compliquée à faire, donc j'ai pris une option plus simple: en cas d'absence de remontée, soit les radiateurs sont éteints, soient ils continuent à chauffer au rythme qui existait avant la perte de remontée. Pour basculer entre ces deux comportements, il faut utiliser l'option HMCF.turnOffNoTemp (à rajouter dans ton fichier config): HMCF.checkDelayTemp = true -- warn if temperature has not been updated for some time HMCF.maxDelayTemp = 8*60 -- max delay between 2 temperature updates (minutes) HMCF.turnOffNoTemp = true -- turn off heaters if max delay is exceeded Si HMCF.turnOffNoTemp = false, alors les radiateurs ne s'éteindront plus en cas d'absence de remontée. J'ai aussi augmenté le délai par défaut de 8h à 12h. Je n'ai pas eu le temps de bien tester, donc est-ce que tu peux tester la version jointe sur une pièce pendant quelques semaines stp ? HCM v520.16.lua

Il y a une solution toute simple, désolé j'aurais du y penser avant. Ce contrôle se fait uniquement au démarrage du QA, qui vérifie qu'il arrive à communiquer avec le FGS. Ça doit se produire pendant un reboot, alors que le réseau zwave n'est pas encore totalement rétabli (le programme attend 1 minute mais visiblement dans ton cas ce n'est pas toujours suffisant). La solution est de désactiver l'option HMCF.checkHeaters (remplacer true par false) dans le fichier config. Une fois que ta config est stable cette vérification n'est plus nécessaire. Ça devrait régler le pb une fois pour toutes. Et de mon côté je vais allonger le délai d'une minute avant de communiquer avec les modules en cas de reboot.

Hello jojo, Désolé pour le délai. Ce message signifie seulement que le FGS ne répondait pas aux commandes. Il y a du avoir une perturbation dans ton réseau qui visiblement a été temporaire. J'imagine que ça ne s'est pas reproduit depuis, sinon dis-moi.

Oui les deux sont acceptés. HM:addHeater({id=162, wakeUp=300}) est équivalent à : HM:addHeater({id=162}) HM:setRoomSensor({wakeUp=300}) En cas de conflit, addHeater est prioritaire.

1) Il faut juste que tu déplaces la ligne 34 avant le "end" de la ligne 33. Tous les paramètres doivent être insérés avant le "end". Je ne comprends pas pourquoi tu dois te caler sur les délais de GEA, mais on doit avoir une utilisation différente... Si tu veux absolument modifier minAction, je te conseille de fixer minCycle à 300 ou 600 (au lieu de 180). 2) Ça me rappelle ma femme qui met le thermostat à 24° dans la voiture en pensant que ça va chauffer plus vite . Que la consigne soit 28° ou 30°, le radiateur sera à fond jusqu'à que ce que la température dépasse les 27°. 3) tu peux mettre des groupes de GEA.add entre commentaires avec la syntaxe --[[ et --]]. Tu mets les 100 premiers en commentaires, et si c'est bon tu sais que c'est dans les 90 autres, sinon tu réactives les 50 premiers, et ainsi de suite. EDIT: Comme la structure du fichier config a été un peu modifiée, j'en ai profité pour mettre à jour ton fichier avec la nouvelle fonction setRoomSensor() (au cas ou tu en aies besoin un jour) PID_ConfigBureau.lua

Salut Jojo, 1) Le problème semble venir de ton fichier config, il doit y avoir une typo quelque part (autour de la ligne 34). Si tu le partage je pourrai probablement la trouver. Entre parenthèse, avec un minAction plus long tu vas perdre un peu en précision dans la régulation, surtout si tu as des cycles courts. Ex: si tu as un cycle PID de 3 minutes, un minAction de 60 secondes, et que le thermostat veut chauffer 20%, il va en fait chauffer 33% (1 minute sur 3) et donc surchauffer par rapport à ce qui est nécessaire. Si tu as un cycle PID de 15 minutes, c'est moins gênant. Il n'y a pas de paramètre pour une durée minimum de non activité pour l'instant. 2) Ça me semble être le fonctionnement normal. Pourquoi tu ne changes la limite globale à 30° ? Avant il n'y avait peut-être pas de message de warning et d'arrêt du QA, mais en pratique la valeur max de confort était bien limitée par la limite globale. Je ne comprends pas dans quelles circonstances tu veux avoir une consigne Confort à 30° et tu veux quand même une limite globale à 28°. tu peux expliquer ? Je peux enlever l'arrêt du QA mais le principe de fonctionnement est de vérifier la config en détail au démarrage et d'alerter l'utilisateur si il y a quelque chose de bizarre. Une fois la config validée c'est le contraire, le fonctionnement doit être robuste. 3) Si ça se produit au démarrage de GEA tu as ta réponse. Tu doit avoir une ligne de test cachée quelque part. Essaie de désactiver tes règles et de de les réactiver groupe par groupe pour voir d'où ça vient ?

Moi j'utilise ça: function QuickApp:onInit() self:debug("onInit") local uptime = os.time() - api.get("/settings/info")["serverStatus"] local delay = 0 if uptime < 60 then self:debug("HC3 reboot detected - QA start delayed by 1 minute ...") delay = 60 * 1000 -- millisecondes end setTimeout(function() run() end, delay) end

Ma box a planté pendant la nuit. Jamais eu ça avec les versions précédentes. Je l'ai redémarrée et j'attends de voir. Si ça se reproduit je rétrograde à la version 5.13.

Petite mise à jour: la version 5.20.14 permet de supprimer les avertissements "Radiateur a été modifié - vérifiez que seul HCM le contrôle" qui étaient affichés de temps en temps sans raison (faux positif).

Ça dépasse mes compétences, je ne savais pas qu'on pouvait le faire. Peut-être @Lazer ?

Le plus simple c'est la fonction tools:getVariable() Sinon voici un extrait du code qui devrait fonctionner: function getVariable(id, variable) device = api.get('/devices/' .. tostring(id)) if device and type(device.properties) == "table" and type(device.properties.quickAppVariables) == "table" then for _, v in ipairs(device.properties.quickAppVariables) do if v.name == variable then return v.value end end end end

Salut, C'était pour limiter le nb de variables, sachant que j'ai prévu d'en ajouter une autre pour sauvegarder le mode Manuel en cas de reboot. Pour lire la variable il faut juste un json.decode: modes = json.decode(variable) local confort = modes["Confort"] local eco = modes["Eco"] etc.