jojo
-
Compteur de contenus
14 553 -
Inscription
-
Dernière visite
-
Jours gagnés
185
Tout ce qui a été posté par jojo
-
NOOOON , bravo à TOI ! (pour le GEA et ce truc)
-
voici donc ce que j'ai, et qui évidemment fonctionne (c'est super logique) GEA.add (true , 0, "", {"VariableCache", "BUREAU_TMP", 0}) GEA.add ({"VariableCache!", "BUREAU_TMP", {"Value", id["BUREAU_TMP"]}}, 0, "", {{"QuickApp", id["GESTION_CHAUFFAGE"], "Label", "Bureau"}, {"VariableCache" , "BUREAU_TMP", {"Value", id["BUREAU_TMP"]}}}) et après on s'étonnera que je suis fan de GEA (déjà 190 GEA.add)
- 12 153 réponses
-
- 1
-
-
- support
- script lua
- (et 1 en plus)
-
ah ok, très bonne idée. j'essaie
-
j'ai essayé ceci sans succès. Pour les deux tests j'initialise ma variable cacche GEA.add (true , 0, "", {"VariableCache", "BUREAU_TMP", 0}) et voici les 2 tests que j'ai fait : Test1 : GEA.add ({"VariableCache!", "BUREAU_TMP", id["BUREAU_TMP"]}, 0, "", {"QuickApp", id["GESTION_CHAUFFAGE"], "Label", "Bureau"}) et test 2 : GEA.add ({"VariableCache!", "BUREAU_TMP", {"Value", id["BUREAU_TMP"]}}, 0, "", {"QuickApp", id["GESTION_CHAUFFAGE"], "Label", "Bureau"}) donc il y a 2 possibilités : 1) soit je n'ai pas bien compris/ou implémenté ton conseil 2) soit c'est ok, et en fait je n'y croyais pas trop , car je ne vois pas la différence avec "Value!" Comment j'interprète le "Value!" : si la valeur mesurée est <> alors faire l'action. La première fois elle est <> donc ok . Au prochain changement elle est toujours <> (SANS entre temps être redevenue =); donc pas d'action. Idem pour le "Value+" (ou "Value-") est-ce qu'il agit à chaque modification de la valeur si elle est > (ou <) à la consigne ou uniquement la première fois ?
-
j'avais fait les tests de fonctionnement à côté de ma HC3. Et puis comme j'ai réussi à refaire fonctionner ma multiprise z-wave, j'ai retourné la zigbee
-
et quelle est la commande http vers ton Doorbird pour commander le relais1 ?
-
je souhaite exécuter une action par GEA à chaque changement de la température mesurée: j'ai mis ce code GEA.add ({"Value!", id["SDBRDC_TMP"], 0}, 0, "", blablabla ...) ça fonctionne au save du QA, puis plus rien ... Une idée de l'instruction à utiliser ?
-
j'ai réussi à te poser une colle ! Je n'ai pas dit qu'on savait le faire, mais juste que j'aimerais le faire ... Je me demande si avec F12, on ne pourrait pas voir ce qui se passe, mais je ne sais plus comment l'utiliser ...
-
bonjour, je souhaiterais lancer le QA (le preview, où je peux cliquer sur les différents boutons) depuis une bouton d'un au QA.. Quelle méthode dois-je appeler ? hub.call(id["CHAUF_BUREAU_PID"], "quelle méthode ?")
-
et j'oubliais le plus important : Merci pour le partage !
-
nooo stress. Merci pour tes réponses, je l'adapterai donc à mes besoins...
-
un interrupteur, donc avec des fils, pour commander par exemple une lampe ou une télécommande (sur piles) ?
-
Salut, GENIAL ce développement, enfin un backup lisible... J'ai (comme d'hab) une question : - à quoi correspond/sert l'action <Abandon> ? et propositions d'évolution : 1) actuellement, la variable <$dirSaveHc3> coreespond à un sous-répertoire d'où est installé le php. sur mon NAS Synology, cela correspond à /volume1/web/SaveHc3/SaveHc3 Les backup de Lazer sont sauvés dans un sous répertoire de /volume1/Domo_Fibaro Ne serait-il pas possible que la variable <$dirSaveHc3> fasse référence à une destination absolue (au lieu de relative) ? 2) Après l'exécution de l'action, serait-il possible d'affficher une confirmation comme quoi tout s'est bien passé ? (car comme je ne voyais rien, j'ai fait plusieurs sauvegardes ...) Merci !
-
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
