OJC

C'est sûr que ce serait mieux, mais je n'ai pas de HC2 fonctionnelle disponible en ce moment, et même si cette correction ne suffit pas, elle ne peut pas faire de mal

J'ai mis à jour le premier post en intégrant la remarque de @pepite. Merci à toi

Le problème semble venir de la MàJ 4.560 à en juger par ce post sur le forum Fibaro... Du coup, une solution serait de tester la valeur récupérée avec _f:getGlobalValue et d'enclencher une boucle While string.len(y_yeelight_) == 0 en exécutant à nouveau _f:getGlobalValue jusqu'à récupérer le contenu de la variable, et ensuite seulement exécuter json.decode. Un truc du style : local y_yeelight_raw = _f:getGlobalValue('y_yeelight_' .. _yid) while string.len(y_yeelight_raw or '') == 0 do y_yeelight_raw = _f:getGlobalValue('y_yeelight_' .. _yid) end local y_yeelight_ = json.decode(_f:getGlobalValue('y_yeelight_'.._yid))

C'est curieux par ce que la ligne 114 : local y_yeelight_ = json.decode(_f:getGlobalValue('y_yeelight_'.._yid)) est précédée plus haut par cette instruction : if not _f:getGlobalValue('y_yeelight_'.._yid) then api.post('/globalVariables', {name='y_yeelight_'.._yid, isEnum=0}) end qui est bien exécutée puisque le Debug affiche "Checking global Variable etc". Je n'ai pas de HC2 fonctionnelle sous la main en ce moment. Essaie de remplacer les lignes 79 à 81 du code du mainloop par celles-ci, et poste le résultat : if not _f:getGlobalValue('y_yeelight_'.._yid) then log('Variable y_yeelight_'.._yid .. ' inexistante') api.post('/globalVariables', {name='y_yeelight_'.._yid, isEnum=0}) end local y_yeelight = _f:getGlobalValue('y_yeelight'.._yid) Log('Valeur de la variable (1) : ' .. y_yeelight) if string.len(y_yeelight or '') == 0 then _f:setGlobal('y_yeelight_'.._yid, '{"properties":{},"last":{}}') end y_yeelight = _f:getGlobalValue('y_yeelight'.._yid) Log('Valeur de la variable (2) : ' .. y_yeelight)

@MAM78 Le souci, c'est que je n'ai pas de message d'erreur et que la scène ne plante pas, puisque la boucle qui contrôle l'usage de la mémoire continue de tourner sans problème... C'est un peu à s'arracher les cheveux : comme si à un moment donné, pour une raison qui m'échappe, la boucle setTimeout du mode proportionnel (c'est celui que j'utilise) n'est pas relancée...

@MAM78 Oui, le mode de régulation par hysteresis est compatible avec le mode événementiel.

PS : La boucle principale de la scène vient encore de planter Je vais faire des tests un peu plus poussés pour comprendre pourquoi... Jamais eu aucun problème l'hiver dernier, ce doit être lié à une des mises à jour intervenues depuis lors...

@MAM78 C'est exactement comme cela que ça fonctionne, à ceci près qu'en cas d'événement, la température de consigne appliquée est celle définie dans l'événement. Donc, pas forcément comfort ou eco, tout dépend de la configuration. Pour ce qui est du codage du test, comme je te dis, c'est trash. Donc un code un peu merdique. Il aurait effectivement été beaucoup plus simple et logique de tester directement la valeur des variables comfort et eco, sans même coder la valeur mais en faisant directement référence à la variable. Bien que ça commence à dater un peu, il me semble que c'était justifié à un moment, et qu'après diverses modifications rendant le test inutile, cette partie du code est passée au travers de l'optimisation... Je devais être un peu fatigué

@MAM78 C'est juste une bidouille un peu trash pour savoir si la température de consigne par défaut est la température de confort ou la température éco. Si tu regardes dans le bloc de déclarations des variables au début du code, la variable comfort est égale à 7000 et la variable eco est égale à 6000. Si event.setpoint est supérieur à 1000 (valeur arbitraire nécessairement supérieure à toute température de consigne pouvant raisonnablement être paramétrée) et inférieur à 6500 (donc on est par défaut sur le mode eco), alors la scène va chercher la valeur paramétrée dans le VD Thermostat de la pièce. S'il est inférieur à 7500, on est en mode confort. Et à défaut, la scène prend la valeur paramétrée. Le test n'a de sens que pour le fonctionnement en mode événementiel, puisque le principe de ce mode est de toujours appliquer une température de consigne sauf si un événement vient la modifier (à la différence de la planification où le principe est une variation de la température de consigne en fonction de l'horaire). Il y avait sûrement plus élégant pour faire ça...

@MAM78 Le VD Thermostat n'affiche pas la température actuellement mesurée. Ce n'est pas un oubli, c'est juste que l'info existe ailleurs. Mais je reconnais après coup que ce serait utile d'avoir l'information à cet endroit-là. En revanche, ce VD n'est pas conçu pour être utilisé quand Heating Manager fonctionne en utilisant une planification, il est conçu pour fonctionner avec le mode événementiel.

Essaie de supprimer la variable globale HeatingManager, le script a peut-être enregistré des données faussées (je n'ai pas la box à portée de main pour faire des tests moi-même).

Dans la fonction HM:getDefaultConfiguration, ajoute : if isnil(self.HMCF.kP.data) then self.HMCF.kP.data = {} end après cette ligne de code : self.HMCF.kP.start = isnil(self.HMCF.kP.data) PS : A première vue, ta modification ne me semble pas utile puisque les tests que tu as ajoutés lorsque origin = "addHeater" sont réalisés par la fonction checkDevice.

@MAM78 Dans les formules de configuration, il faut remplacer le nom des paramètres par leur valeur. Je vois aussi que tu n'as pas défini le mode de chauffage que tu veux utiliser : régulation proportionnelle ou via hysteresis ? En mode proportionnel, essaie ça : --GENERAL CONFIGURATION--------------------------------------------------------------------- self:setConfiguration(true, 180, true, false, {289}, false, true) self:setProportionalMode(60, true, 1, 15, 1, comfort) --HEATERS CONFIGURATION--------------------------------------------------------------------- self:addHeater(7, {411, "turnOn", "turnOff", "0"}, {359, "lblTemp"}) --SETPOINT SOURCES CONFIGURATION------------------------------------------------------------ self:setSetpoint(7, 192) --INDOOR TEMPERATURE SONDES DECLARATIONS---------------------------------------------------- self:setIndoorSonde(7, {359, "lblTemp"}) --OUTDOOR TEMPERATURE SONDE DECLARATION----------------------------------------------------- self:setOutdoorSonde({355, "lblTemp"}) Pour que ça fonctionne, il faut mettre un VD Thermostat dans la pièce ID 7.

Je n'ai pas encore fait de tests poussés. Et si, c'est ça le plus bizarre, la scène continue à tourner puisque j'ai l'affichage de la mémoire utilisée dans les logs toutes les 5 ou 10 minutes. Ce n'est pas la scène dans son ensemble qui plante...

@pepite Plus précisément, dans ma configuration, c'est la boucle HM:startProportionalManager qui ne tourne plus. Comme si le setTimeout cessait à un moment de repartir

@pepite Tu me diras ce que ça donne en terme de stabilité. Je suis en version 4.510 et mon script plante régulièrement, je n'arrive pas à comprendre pourquoi. La boucle qui gère le déclenchement des radiateurs cesse tout simplement de fonctionner, alors que celle qui s'occupe d'afficher toutes les 10 minutes la mémoire utilisée par la scène continue de fonctionner sans problème. Je ne vois pas de messages d'erreurs... A s'arracher les cheveux qui me restent

@pepite Ok J'essaierai de répondre le plus rapidement possible, mais je te préviens que je suis complètement sous l'eau à tous les niveaux en ce moment.

@J3R3M Je n'ai pas de script en Lua, il est en bash sur mon serveur Linux.

@Tomsauy Désolé pour le retard de cette réponse, beaucoup de travail en ce moment ! Heating Manager peut fonctionner en mode de planification 'basique', mais est surtout conçu pour fonctionner sur une base événementielle, étant précisé que le VD Thermostat ne fonctionne que dans ce mode là. Le mode événementiel peut cependant être utilisé avec une planification basique où l'évènement contrôlé à chaque itération est une plage horaire. Je ne sais pas si je suis très clair :/ Pour ce qui est de la deuxième question, la réponse est négative. J'avais commencé à étudier le truc, mais j'ai au final laissé tomber dans la mesure où je n'ai pu trouver suffisamment de matière fiable quant aux équations à utiliser, et où j'ai orienté le développement du programme sur un fonctionnement événementiel où la définition de la température de consigne ne dépend pas au premier chef d'une planification, mais de ce qui se passe dans la maison. Or, s'il est concevable d'anticiper un événement fixe, ce qu'est un horaire déterminé, cela me semble impossible s'agissant d'événements aléatoires.

Bah... Suffit d'un p'tit script qui check l'adresse IP et envoie un message si elle a changé...

@Gandalf Je pense que c'est normal et lié à l'ajout dans l'API de fonctions permettant d'agir sur le réseau Z-Wave. Je pense que cela existait déjà avant, mais en l'absence d'API, il n'y avait pas de retour d'infos sur l'interface.

Tu n'as pas de sauvegarde des scènes et VD en dehors de la HC ?

my bad...

C'est un truc pour les installateurs professionnels, en fait...

Il me vient quand même une question avec ce nouveau mode de sauvegarde... Si ma HC2 rend l'âme et que j'en prends une autre, je peux donc télécharger ma sauvegarde. MAIS si j'ai bien compris le principe du Z-Wave, mes modules sont appariés avec la carte Z-Wave et pas avec le logiciel. Donc il faut quand même se taper la réinclusion de tous les modules. J'ai bon ?