jojo
-
Compteur de contenus
14 825 -
Inscription
-
Dernière visite
-
Jours gagnés
197
Tout ce qui a été posté par jojo
-
merci ! je vois qu'il y a également pleins de tests de robustesse en fait, le QA est tellement puissant que j'ai trouvé comment faire ce que je voulais sans devoir lire les consignes ...
-
merci beaucoup, c'était l'idée que j'avais, mais merci pour le bout de code, je ne dois pas chercher pour le faire. Et tant qu'à faire, aurais-tu le code pour récupérer une variable d'un QA (ici Modes) depuis un autre QA (mon perso de Gestion Chauffage) ?
-
salut, j4ai finit (enfin presque) la migration de tous mes régulateurs. Dans les versions précédentes du code, il y avait une variable (numérique) pour la consigne de température des différents modes. Cela était donc facilement exploitable, par exemple, dans GEA. Maintenant tout est dans une variable Modes Y a-t-il une raison particulière ? Serait-ce envisageable de revenir en arrière ? (ou dois-je développer qqch pour le lire ?)
-
ourf, si j'avais pris le temps de le lire en détail, j'aurais gagné bcp de temps !
-
je suis quelqu'un de têtu, et j'ai fini par trouver le paramètre (qui me permet de ne pas devoir modifier le codeà, HMCF.range._global = { 1, 99} -- {min, max} limits applicable to ALL modes and calls
-
j'ai trouvé plus bas dans le code, comment le faire mieux : -- vjo 19/02/2023 for ECS -- _global = { 1, 28}, -- {min, max} limits applicable to ALL modes and calls _global = { 1,100}, -- {min, max} limits applicable to ALL modes and calls je suis sûr qu'il est possible de le mettre dans les user settings ... je continue de chercher. En tout cas, à la lecture de ce code c'est une vraie machine de guerre ...
-
en fait, je n'ai "résolu" qu'une partie du problème. Car malgré que j'ai défini un range de 60 à 80, Il ne voit qu'un range de 60 à 28 ... et je n'arrive donc pas à mettre une consigne de confor de 70 °C ....
-
NON : si (et ça arrive souvent en été) mon ballon ECS (2500 L) est à 90°C et que ma piscine est déjà bien chaude (>29°C), mes panneaux solqires thermique s'arrêtent (pour que mo ECS ne boue pas), alors, pour éviter une surchauffe des panneaux, je continue de chauffer la piscine. je viens de trouver à l'instant une moyen (non propre) de bypasse cette vérification dans le code : -- vjo 19/02/2023 for ECS -- local min = math.max(range[mode][1], range["_global"][1]) -- local max = math.min(range[mode][2], range["_global"][2]) local min = 0 local max = 100 if min > max or (mode=="Manuel" and min==max) then self:abort("isNotValidRange",mode,min,max) end if min < max then table.insert(self.editable, mode) end self.modes[mode] = modes[mode] or math.max(min, max - 1) en attendant une solution propre proposée par le maître
-
bonjour, J'ai encore une exception : Jz migre tous mes thermostats vers le PID. J'avais un thermostat pour la gestion de mon ECS que, en mode "confort", a une consigne à 60°C. Or ce n'est pas autorisé par le programme : Mode Confort : Les valeurs Min-Max [60-28] sont invalides les infos dans le message d'erreur ne sont pas 100% exactes, car voici ma config HMCF.range.Confort = {60, 80} -- {min, max} values for mode Comfort Je n'y ai pas encore réfléchi, mais je pense que j'aurai un problème similaire avec le thermostat de ma piscine, que je chauffe si mes panneaux solaires sont trops chauds (délestage) Existe-t-il un paramètre pour permettre d'avoir des ranges non habituels ?
-
??? tu m'as perdu là ... Il y a une consigne de température unique pour le QA. Il ne peut donc qu'y avoir qu'une sonde de température ...
-
ça marche beaucoup mieux comme ça ! => c'est une vrai tuerie ce développement, tout a été prévu. J'ai tout de même une question : pourquoi faut-il rajouter ce paramètre au niveau du radiateur (et quid si plusieurs radiateurs), alors qu'il se rapporte à la sonde de température ? (j'aurais imaginé un paramètre HCMF.temperatureWakeup
-
Je commence ma migration, mais je tombe sur un os imprévu : le temps de réveil. J'ai un Aeotec Tri sensor, et dans le json, j'ai bien la propriété "wakeUpTime": 28800, or, d'après la doc, le paramètre 23 permet de définir le temps (en sec) entre chque remontée de température. { "id": 23, "lastReportedValue": 600, "lastSetValue": 600, "size": 2, "value": 600 } La température est bien remontée à la box toutes les 10 min, mais comme le wakeupTime existe et n'a pas été modifié le programme refuse de démarrer (j'ai 5 pièces à réguler avec cette son de température) => Que faire ? (y a-t-il moyen de forcer une valeur ?) Avec le paramètre HMCF.minCycle=600, ça ne va pas mieux, car le programme reçoit une information erronée du wakeupTime
-
ok, grace à la lecture détaillée des logs, j'ai trouvé que l'erreur lors du reboot provenait de mon mastodonte de QA de gestion du chauffage qui n'était pas encore compplètement migr. Une de ses complexité provient du fait qu'il devait être compatible avec les 2 modes de gestion des radiateurs. Ce WE, je bascule tout sur ton PID (ce donnera une petite touche d'amaigrissement à mon GEA, et une groose à mon QA de gestion du chauffage)
-
Excuse ma trop longue absence ... Merci pour la prise en compte de mes demandes, et jje vois que tu viens d'inclure la possibilité d'envoyer des mails J'avais déjà fait un premier test de reboot, et le chauffage de mon bureau repassait à Manuel : donc si cela proviendrait d'une instruction de mon GEA ou d'un QA chez moi (ce dont je doute fort, car rien de programmé pour activer le mode Manuel (ok pour Confort ou Eco), mais en tout cas pas avec un délais de 1 min. je voulais donc remettre une toute "vielle" version de HCM pour comparer, mais maintenant je recommencerai tous mes tests avec cette dernière version. A+
-
juste, mais je ne l'avais pas envisagée, car les notifs sont merdiques. Ne serait-il pas possible d'avoir une option similaire HMCF.mail, où on préciserait l'id de l'utilisateur à qui envoyer les mails. Je pense que ta dernière version va régler bcp des problèmes de reboot. Je commence les tests.
-
je viens de faire le test avec le script de backup, j'ai exactement le même comportement qu"avec un restart via l'interface WEB. Je n'ai donc pas réussi à reproduire l'erreur de config que le programme a détectée, et qui a mis le thermostat sur Off. Peut-être cela dépend-il du moment où le stop de la box se fait par rapport à où en est le programme / lr cycle ??? Si une telle erreur est détectée, serait-il possible de forcer une sauvegarde du QA 51 ou 2 fois max)? et d'envoyer un mail de notification qu'il y a eu une erreur ?
-
pour savoir si on est en mode chauffe ou réfrigération. De toute façon tu as le prochain (zzz) si 0% et l'éclair si > 0% ok, voici le résultat : pour le Cool, il est revenu en mode confort. pour le Heat, pas de changement, il a redémarré avec la consigne en Manuel (vraiment comme si on avait appuyé sur le bouton) j'ai ensuite refait le test dans l'autre sens : mise en commentaire du paramètre <HMCF.checkHeaters = false> et reboot (via interface Web) : => exactement comme juste avant. => c'est un problème avec le Heat. Je vais refaire un test de backup avec le script de @Lazer. comprends pas, car c'est juste un FGS-224, et personne ne sait ce qu'il y a derrière.
-
regarde dans la doc GEA de la HC2, s'il n'y a pas une fonction dans GEA qui ferait un reboot de la box, style (pour la HC3, mais qui nz fonctionne plus suite ç une modif d'un firmware) -- "RebootHC3" : Redémarre la box HomeCenter -- SYNTAXE : {"RebootHC3"} -- CONDITIONS : Ne peut pas être utilisé comme CONDITION -- ACTIONS : GEA.add( {CONDITIONS}, 30, "", {"RebootHC3"} ) -- Redémarrage de la box HomeCenter
-
j'utilise une extension sur mon browser, qui fait ce job dès qu'il détecte un json (j'n avais presqu'oublié que le json était une TRES longue ligne illisible...)
-
UI : je viens d'obser qqch : il y a le flocon (si on est en cool) ou la flamme (si on est en heat) mais si on est en régulation manuelle ET que le régulateur ne demande rien, alors l'émoji qui dit si on est en Heat ou Cool disparait : (je t'avais prévenu que je pouvais être ch... pour des détails d'UI)
-
cette nuit, il y a eu un gros soucis avec l'airco de la cave à vins : voir graphe Voici ce que m'affiche l'interface et malheureusement, le log est vide ... Le problème est apparut à 3h00 du matin, lors d'un restart automatique de la box par le script de backup de @Lazer Pour mémoire je te joins ma config, qui n'a pas changé. Config.txt En ressauvant manuellement le QA (j'ai ajouté un espace à la fin d'une ligne de commentaire du fichier config), tout est reparti ... Et pour le PID du chauffage de mon bureau, pas de spucis => lié au Cool ??? (ou le fait que la consigne a été modifiée à 9h00 correspondrait à un save du QA ?) Je fais le test suivant : reboot de la box via l'interface Web : à nouveau même erreur pour le Cool : un save du QA l'a fait repartir comme il faut. Voici le log du reboot : PID_Log.Reboot.Cool.txt U.I. : comme le thermostat est sur Off, ce serait bien que cette info soit également affichée dans le set mode du QA (on verrait ainsi immédiatement que sur Off, sans devoir rentrer dans le QA) et pour le Heat : il est passé en Manuel. Voici le log : PID_Log.Reboot.Heat.txtet évidemment les 2 QA sont à la dernière version 5.20.10b J'espère avoir été le plus complet possible dans mon analyse. Merci de ton aide
-
je ne comprends pas non plus. Mais que cherches-tu à faire ?
-
et pourquoi ne pas faire ceci tout simplement ? GEA.add({"value", id["ZONE_1"] , true} , -1, "", {"TurnOn", id["ECL_ZONE1"]}) GEA.add({"TurnOn", id["ECL_ZONE1"]}, 5*60 , "", {"turnOff", id["ECL_ZONE1"]})
-
MERCI pour : le partage de ton travail ta proposition d'aide en fait pour les icônes, TOUT se passe ici
-
il faut vraiment que je lise jusqu'au bout avant de répondre ...
