OJC

Sinon pour exploiter sous format de variable table, essaie de faire une boucle pour voir ce qui sort : success = function(response) print ("Je suis dans response") local jsonTable = json.decode(response.data) for i, j in pairs(jsonTable) do fibaro:debug(tostring(i) .. " - " .. tostring(j)) end end,

@pepite dans l'exemple de @Steven, la valeur de response est : {"token":"ABCDEFG","result":"true","deviceStatus":"IDLE","data":{}} Donc, les points, c'est pour dégager les guillemets autour de ABCDEFG. Dans un pattern, ça désigne n'importe quel caractère. C'est la même chose que : local key = "token" print(response:match("\""..key.."\":\"(%w+)\""))

@Domodial Pas encore eu le temps... Dur de trouver un créneau WAF en dehors des heures de boulot pour down le réseau

Non il est ok mais j'ai pas pensé à faire un tuto mise à jour. My bad.

Ps : j'ai omis de préciser que les coefficients sont désormais à multiplier par 100 : donc la ou tu avais 0.6 tu mets 60 et 1 pour 0.01

Oui, juste ça. Pas besoin de mettre localP et local si tu utilise les valeurs par défaut. Pour fixer ces valeurs par défaut, c'est dans le VD Controller que ça se passe.

Non, fini ça La scène gère tout dans la même instance sans triggers. J'ai fait comme ça cas c'était trop galère de faire passer des infos d'une instance à l'autre de la scène puisqu'en cas de modification de la consigne, le programme ne se contente pas de couper ou démarrer les chauffage jusqu'à la fin du cycle, mais recalcule une commande de chauffe. Et il me fallait éviter que l'ancienne commande ne vienne foutre le bazar, donc lui transmettre l'info...

Pour ce qui est de la lenteur, j'ai constaté que l'interface était beaucoup plus réactive sous Safari version MacOS, ainsi que sous Google Chrome version Linux. Sous Firefox (Linux ou Windows sachant qu'en Windows je ne l'utilise qu'à distance via Fibaro ID), c'est juste la mort. Jamais tenté avec les navigateurs de Microsoft. Après, comme dit @Cardane, un VD ou une scène qui ne fait que du basique, il y a peu de chances qu'elle soit responsable. Tu peux commencer par cibler les VD et les scènes qui font les trucs les plus complexes, et voir ce que ça donne. En outre, vu le nombre scènes et VD que tu as, il y a peut être moyen d'optimiser ? J'imagine que tes 130 VD ne font pas tous un truc différent, pareil pour les scènes ? Rien que 130 VD avec leur main loop toutes les trois secondes, ça peut commencer à faire lourd pour la box...

@pepite Mais les VG Fibaro ne sont pas concernées par le backup ? Leur contenu, j'entends. Du coup, l'intérêt de stocker dans le VD est de pouvoir bénéficier d'une sauvegarde automatique avec le backup natif. La fonction d'apprentissage est setCoefficients. Pour le moment, elle est un peu basique puisqu'elle se contente d'incrémenter ou de décrémenter le coefficient si la moyenne des écarts en fin de cycle sur les 10 derniers cycles est supérieure à 0,1 ° C. Il faut que je la retravaille, mais autant j'arrive à me débrouiller pour ce qui est du codage, autant je patauge un peu pour ce qui concerne la chauffe proprement dite, et il n'est pas évident de trouver des infos détaillées sur le net. @Steven Effectivement, sur des chauffages très inertiels, la gestion des ouvrants et des absences temporaires n'a qu'un intérêt très limité, à plus forte raison s'il n'y a qu'un seul outil de chauffe pour toute l'habitation. Heating Manager est en fait plus un gestionnaire de température de consigne qu'un gestionnaire de chauffage...

Petite mise à jour avec pas mal de nouveautés : absence/présence forcée, mode hysteresis, apprentissage automatique, etc... Plus tout ce qui ne se voit pas au niveau de l'optimisation du code...

Non, ça ne me dérange pas Mais comme c'est toi qui a codé le truc, je me suis dit qu'il y avait sans doute un truc à apprendre !

Je ne parlais pas d'une variable globale 'Fibaro' mais d'une variable globale 'Lua' : if (not GEA) then GEA = {} [...] GEA.insert = function(entry) table.insert(GEA.todo, entry) --entry[GEA.keys["INDEX"]] = #GEA.todo return entry[GEA.keys["INDEX"]] end [...] end Ce qui signifie bien que les fonctions sont stockées dans la variable globale GEA. Ou alors j'ai vraiment rien compris A quoi sert la condition (not GEA) dans une scène puisque par définition, elle sera toujours à true ?

Donc pourquoi GEA est codé comme ça ? C'était un VD à l'origine ?

Bonjour, En regardant le code de GEA de @Steven, j'ai constaté que toutes les fonctions sont stockées dans une variable globale de type table, et que la scène contrôle avant de la créer si elle n'existe pas déjà. Si je comprends bien l'intérêt dans le main loop d'un VD, je vois moins l'intérêt dans une scène ? D'après ce que j'ai pu constater, une variable globale se conserve d'un loop sur l'autre dans le VD (comme si le code s'insérait en réalité dans un sleep ou un setTimeout), mais pas d'une instance à l'autre d'une scène.

@Steven Concrètement, ça se gère comment ? Hysteresis ?

Et si tu testes au lancement de la scène le nombre d'instance et que tu fais un fibaro:sleep(nb d'instance) ?

Voilà le code pour mieux comprendre mon propos : C'est la fonction StartOverrideManager() qui scanne en permanence le VD pour détecter un changement de la consigne et qui recalcule la commande de chauffe. Dans la fonction StartCycle() se trouve la fonction setTimeout qui se charge de couper le chauffage à la fin de la période de chauffe en vérifiant s'il a le droit de le faire.

@Krikroff Après tests, j'avais écarté le trigger sur la variable (je ne sais plus pourquoi, j'ai tellement tourné le truc dans tous les sens ) Mon problème était de recalculer la commande de chauffe à chaque modification de la consigne, plutôt que d'arrêter ou lancer le chauffage jusqu'à la fin du cycle en cours (ce que j'avais fait initialement et qui est une solution passable sur un cycle de 10' mais un peu bâtarde sur un cycle de 30' ou 45'), et ce en faisant en sorte que le setTimeout du cycle principal ne fasse pas sa life en coupant le chauffage selon la commande de chauffe précédente alors que la nouvelle imposerait de continuer à chauffer. Donc il me fallait faire passer l'info non seulement du VD à la scène, mais entre deux instances de la scène... Je me suis bien arraché les cheveux, et au final, j'ai utilisé setTimeout pour scanner en permanence non pas une variable mais le VD directement. Au final, c'est incomparablement plus simple et cela me permet, en plus, de virer tous les triggers et de n'avoir en permanence qu'une seule instance de la scène (au lieu d'une instance pour le cycle principal et d'une nouvelle instance de courte durée à chaque modification de la température de consigne). C'est le même code qui est utilisé dans les deux cas, avec juste un paramètre de plus pour éviter l'arrêt non désiré de la chauffe. Bref... J'imagine que c'est plus clair pour moi qui ai le nez dedans que pour vous...

Même après une fresh install, ça foire... Je vais essayer de récupérer un win 7 pour tester

@Lazer C'est exactement ça, dit bien mieux que je ne saurais le faire. Concrètement, je suis sur Heating Manager avec le cycle de chauffage qui est relancé à intervalles réguliers via setTimeout. Pour prendre en compte les changements de consigne de manière satisfaisante et pouvoir faire passer une information entre deux instances d'une scène, j'ai essayé de passer par une variable globale qui est scannée en permanence par une boucle while. Et pendant qu'elle tourne, le cycle n'est pas relancé...

C'était une HC2 perdue au fond du stock

Là, en l’occurrence, c'est pas passé du tout... Mais je réessaierai plus tard, avant d'aller me coucher

HC2-0419XX pour ma part, acquisition en octobre 2017. La CM est une Mitac International Corp. (d'après la Freebox )

Petite mise à jour pour rajouter le déclencheur onSolarNoon correspondant au midi solaire... J'en ai profité pour changer la logique initiale permettant à la scène de retrouver toute seule le module virtuel sans avoir à renseigner l'ID : chaque élément du programme (scène et module virtuel) se charge lui-même de mettre son ID dans une variable globale. Inutile d'aller le chercher via l'API... Du coup, le nom de la variable globale a changé (mais pas de soucis, la scène s'occupe de supprimer l'ancienne désormais inutile).

La moitié de l'installation, c'est le backup pré-update Après, je ne sais pas à quel moment de l'update la box a planté, vu qu'aucun log ne s'affiche...