Dgille

Bonjour, merci. Comme convenu, voici le QA dasn la version en production chez moi, version 4.1, je n'ai pas pu intégrer les modifications de @Felig vu mon état, je vous laisse donc maintenant le faire évoluer à votre convenance. Je n'assurerai aucun support de ce QA pour les mêmes raisons, désolé. Bonne continuation à tous. QA_Heating_Manager_4.1_sans_conf.fqa

Bonjour, je suis toujours très malade, mais je vais publier le QA ds ma version stable dans quelques jours. je vous laisse le faire évoluer ensuite, il n’y aura pas de nouvelles versions de mon côté. merci

Merci, je corrigerai dès que possible , je suis hospitalisé pour le moment.

Essaye de supprimer la VG , elle est peut être corrompue.

Oui, effectivement, les tores renvoient directement un index, donc pas besoin de conversion. Cela passe avec un Get/S, sur le sous-poste, voire le poste directement. Merci !!!

Autre question, je quelques tores connectés au RT pour mesurer la conso sur les grands postes (Chauffage, ECS et bientôt PAC). J'ai donc créé la config suivante pour tester. {device = {name = "Pince Chauffage" , type = "EnergyMeter" }, value = {command = "Index", argument = "T" , pin = "Index_TORE_Cons1", type = "X400-CT-100A"}}, {device = {name = "Pince ECS" , type = "PowerSensor" }, value = {command = "Index", argument = "T" , pin = "Index_TORE_Dist2", type = "X400-CT-50A"}}, Avec les 2 types pour voir la différence. Les enfants sont bien là: Pas d'affichage sur la pince Chauffage, normal, mais le swagger indique que "Value" contient bien l'index. Par contre, sur le pince ECS, je ne sais d'ou vient la valeur (en VA convertie??) et pas d'affichage en W. La requête Index=T donne Je dois inverser le sens du tore 2 (car je suis en Dist), mais au delà de cela, l'absence de conso est W est normale ou pas ? Merci !

Super boulot. Pour le TEMPO, le tarif en cours remonte bien sur la VG. Au niveau du child TéléInfo, la puissance apparente en V.A. remonte bien, mais pas la puissance en Wh/h. Pour cela, j'ai modifié la ligne 733 du fichier GCE par celle-ci : local energykWh = ((tonumber(response.BASE) or 0) + (tonumber(response.HCHP) or 0) + (tonumber(response.HCHC) or 0) + (tonumber(response.BBRHPJB) or 0) + (tonumber(response.BBRHCJB) or 0) + (tonumber(response.BBRHPJW) or 0) + (tonumber(response.BBRHCJW) or 0) + (tonumber(response.BBRHPJR) or 0) + (tonumber(response.BBRHCJR) or 0 ) + (tonumber(response.EJPHN) or 0 ) + (tonumber(response.EJPHPM) or 0 )) / 1000 Pour tenir compte de TEMPO voire EJP. Pour les FP, ce qui serait bien, c'est de pouvoir faire un bête ON/OFF (donc Confort/Arrêt) sur un binary Switch, quand les radiateurs sont pilotés par un thermostat externe (ou QA Heating Manager à venir :)) ou les 6 ordres. Ce qui est dommage, c'est que l'API GCE ne place pas les ordres FP dans l'ordre ( 0 pour confort, 1 pour Eco, 2 pour Hors Gel, 3 pour Arrêt, 4 pour Confort -1 et 5 pour Confort -2 ), il faudra donc un bout de code si l'on veut le même comportement que les Qubino. Est il possible d'ajouter des boutons sur les childs ? Il me semble que non pour le moment.

Super, je teste ce soir, je viens juste de remplacer mes Qubino par un RT plus module FP. il supporte la tarification TEMPO ?

Oui, mais il pose une dérogation sur le panneau et pas sur le QA thermostat. La confusion vient que l'appli propose un simili thermostat qui agit sur les panneaux et pas sur les QA thermostat.

Pas d'accord, après quelques tests, les panneaux de chauffages sont bien liés au thermostat (ce n'est pas un scoop), donc dépendance. L'application mobile positionne bien les dérogations sur les panneaux de chauffage. Les profils positionnent bien les dérogations sur les panneaux de chauffage. Au final, ce sont les dérogations positionnées sur les thermostats qui ne créent pas de dérogation sur les panneaux. Cela me paraissait surprenant, mais en y réfléchissant, c'est logique. Il faut considérer les QA thermostats comme des versions virtuelles des thermostats physiques, en charge de faire le lien avec les équipements de chauffe. Donc soit on est dans un logique de piloter les dérogations via les panneaux, interface WEB et appli mobile font le job. Soit on dispose d'un thermostat physique ou virtuel et on pilote les dérogations via ce dispositif. Il faut juste ne pas faire les deux en même temps, car conflit. La priorité dépend de l'usage que l'on en fait derrière: - au thermostat, si le QA thermostat pilote effectivement le chauffage (via FP par exemple), ou le thermostat physique une chaudière), - au panneau s'il n'est que support à une scène ou un autre QA qui lui, pilote effectivement le dispositif. En résumé, avec ces éléments, il faut bien réfléchir en amont à la manière dont on souhaite gérer tout cela. EDIT: les QA Thermostats sont affichés, mais sans possibilité d'interagir sur l'appli mobile, probablement à venir dans une prochaine version.

Oui, pour positionner une dérogation de x minutes, ou travailler sur le thermostat. La hiérarchie des dérogations n est pas 100% claire pour moi sur la HC3.

J utilise le Heating Manager pour déroger aux panneaux, mais Cool, on vient de lister presque toutes les solutions possibles pour les FP...

GEA dans ce cas....

Une autre solution est , a partir d un QA thermostat classique, mettre en correspondance les ordres FP et les températures issues du panneau de chauffage, 19 = confort, 18 = confort -1, 15= eco, etc...., ainsi tu profites des panneaux et des thermostats de l’appli mobile. pas de régulation fine , mais c est pratique d utilisation.

Un bug que j'ai remarqué sur la fonction setTimeout sur HC3, dans les QA, c'est que si tu calcules le temps en millesecondes manuellement, et donc que ce n'est pas un entier, la fonction considère que la valeur vaut 0, donc un appel du style: function f1() blablabla setTimeout(f1(),1000.01) end f1() est appelée non stop, avec 100% de CPU à la clef. même un bête 0.5*1000 peut conduire à un 500.0000001, je fais donc systématiquement un math.floor() lorsque le délai est calculé.