Lazer Posté(e) le 2 août 2021 Auteur Signaler Posté(e) le 2 août 2021 Oui le Swagger, très pratique ça y est, la tempête de goutes d'eau est arrivée, la HC3 est donc en avance sur son temps
ggpublic Posté(e) le 2 septembre 2021 Signaler Posté(e) le 2 septembre 2021 Bonjour à tous, j'ai un petit souci avec une commande que j'utilise pour toute ma maison: globalement je veux que les lumières s'éteignent automatiquement après un certain délai s'il n'y personne dans la pièce. Plutôt simple et je faisais ça avec un code similaire avec une HC2 mais là ça coince sur HC3. Ma commande est la suivante, avec 204 = détecteur de mouvement, 288 le QA qui gère les ampoules Hue de la pièce avec test sur un label qui indique si la lumière est allumée ou non. GEA.add({204,{"Label",288,"lblState","State: 1 - On"}},10*60,"Extinction automatique Buanderie (10min)",{{"Inverse"},{"RoomLights", "Buanderie", "turnOff"}}) Cela fonctionne au début mais après un certain moment, cela ne fonctionne plus et les lumières restent allumées alors qu'il n'y a plus eu de mouvement pendant longtemps (et j'ai bien vérifié, la condition sur la label du QA 288 n'est pas en cause). Est-ce que je dois mettre un {repeat} qqpart ? ou bien est-ce que le {inverse} sur la détection de mouvement pose pb ? y a t'il un moyen plus simple de faire ça ? merci bcp pour vos réponses.
ced600f Posté(e) le 2 septembre 2021 Signaler Posté(e) le 2 septembre 2021 Il y a 4 heures, ggpublic a dit : Bonjour à tous, j'ai un petit souci avec une commande que j'utilise pour toute ma maison: globalement je veux que les lumières s'éteignent automatiquement après un certain délai s'il n'y personne dans la pièce. Plutôt simple et je faisais ça avec un code similaire avec une HC2 mais là ça coince sur HC3. Ma commande est la suivante, avec 204 = détecteur de mouvement, 288 le QA qui gère les ampoules Hue de la pièce avec test sur un label qui indique si la lumière est allumée ou non. GEA.add({204,{"Label",288,"lblState","State: 1 - On"}},10*60,"Extinction automatique Buanderie (10min)",{{"Inverse"},{"RoomLights", "Buanderie", "turnOff"}}) Cela fonctionne au début mais après un certain moment, cela ne fonctionne plus et les lumières restent allumées alors qu'il n'y a plus eu de mouvement pendant longtemps (et j'ai bien vérifié, la condition sur la label du QA 288 n'est pas en cause). Est-ce que je dois mettre un {repeat} qqpart ? ou bien est-ce que le {inverse} sur la détection de mouvement pose pb ? y a t'il un moyen plus simple de faire ça ? merci bcp pour vos réponses. Tiens, je remarque un problème similaire....de mon côté, parfois GEA redémarre et cela refonctionne. Pour ma part, les règles sont celles-ci: local task5 = GEA.add(id["LAMPE_SALON"] , 20*60, "", {{"turnOff"}}) GEA.add(id["DETECTEUR_SALON"], -1, "", {{"RestartTask", task5}})
Lazer Posté(e) le 2 septembre 2021 Auteur Signaler Posté(e) le 2 septembre 2021 Je mettrais un "Repeat" oui.... car le problème avec les détecteurs de mouvement, c'est que s'il se déclenche et s'arrête entre 2 boucles de GEA (toutes les 60s), alors GEA rate des mouvements. Je sais que ça m'arrive sur certains de mes scénarios, depuis la HC2. Donc le Repeat devrait permettre de contourner ce problème. 1
ggpublic Posté(e) le 3 septembre 2021 Signaler Posté(e) le 3 septembre 2021 Merci pour ton retour @Lazer, je vais mettre des {repeat} et voir ce que ça donne. A sujet de ce que disais @ced600f , je constate un peu la même chose, j'ai l'impression que mon GEA tourne sur trois pattes parfois. Il redémarre tout seul (sans reboot de box) et, après un certain temps, certaines tâches ne sont pas exécutées comme dans ce code simple d'allumage d'un sèche serviette tous les jours de semaine le matin à ~7h GEA.add(true,60,"Allumage sèche serviette semaine pour 1h", {{"turnOn",454,60*60},{"Time", "07:00", "07:05"},{"Days","Weekday"}}) parfois rien n'est déclenché, parfois je trouve le radiateur allumé toute la journée malgré la sécurité suivante qui tourne en parallèle et est censé arrêter tout au pire au bout de 2h : GEA.add(454,120*60,"Arret auto du seche serviette de la Salle de bain du haut après 2h!",{{"turnOff",454}}) suis-je le seul à constater des comportements erratiques ? a moins que j'ai manqué qqch mais le code là est on ne peut plus simple
Lazer Posté(e) le 3 septembre 2021 Auteur Signaler Posté(e) le 3 septembre 2021 Si GEA redémarre tout seul, il faudra me donner les logs au moment du redémarrage, sans ça impossible de deviner le problème. Par ailleurs, mettez bien une règle qui vous envoie une notification au redémarrage de GEA (comme dans l'exemple fourni), ça évitera les "impressions" et vous aurez des certitudes sur le redémarrage (ou non) de GEA. Personnellement ça ne m'est jamais arrivé depuis 3 mois que mon GEA tourne en production, avec 150 règles environ (par contre j'ai eu quelques redémarrages de la box) Par ailleurs, est-ce que ça ne serait pas un problème plus général sur la box ? Avec des freeze ou une saturation de la RAM ? Sujet plusieurs fois abordé sur le forum. Si vous avez Domocharts, regardez les graph CPU et RAM. Perso j'en ai assez rarement des freeze, mais ça semble arriver plus souvent à @jjacques68 notamment. Parce qu'un freeze de 1, 2, 3 minutes, voire plus, ça peut expliquer les actions manquées telles que l'allumage du sèche serviette de ton exemple. Mais ça n'expliquerait pas la règle d'extinction du sèche serviette, qui n'a pas de référence horaire. Quand ça arrive, dans la HC3, le module 454, il est bien ON ? Il faut analyser les causes des comportements erratiques, sinon tu ne trouveras jamais.
jjacques68 Posté(e) le 3 septembre 2021 Signaler Posté(e) le 3 septembre 2021 Il y a 4 heures, Lazer a dit : mais ça semble arriver plus souvent à @jjacques68 notamment. je confirme, tous les soirs entre 20h45 et 21h30, pendant 3 min. On s'en rend compte que si qqch aurait du se passer pendant ce temps là. Et avec un suivi de l'utilisation des CPU. (ou tout autre forme de bit de vie). La dernière mise à jour de la HC3 n'a rien amélioré.
Lazer Posté(e) le 3 septembre 2021 Auteur Signaler Posté(e) le 3 septembre 2021 Et bien... suffisait d'en parler, ça vient de m'arriver, à 18h. Je me suis rendu compte que GEA n'avait pas exécuté une action à cette heure là (action simple, sans autre condition que l'heure) Je regarde la courbe CPU de DomoCharts, et je constaste un affreux pic à cette heure là.... donc forcément, GEA n'a pas pu exécuter l'action à l'heure dite. La solution de contournement, tant que Fibaro n'aura pas travaillé sur ce problème de freeze, c'est d'allonger les plages horaires "Time" qu'on utilise dans GEA.... Là où je suis inquiet, c'est que personne, à part toi et moi, ne semble avoir relevé ces freeze (faut dire que c'est pas évident à détecter).... et encore moins remonté sur le forum officiel, donc Fibaro n'est pas prêt de travailler sur ce sujet... D'ailleurs, c'est très étonnant que ça soit tous les jours à la même heure chez toi, car chez moi c'est assez rare. Plutôt tous les 15 jours, à des horaires variables.
jjacques68 Posté(e) le 3 septembre 2021 Signaler Posté(e) le 3 septembre 2021 il y a une heure, Lazer a dit : c'est très étonnant que ça soit tous les jours à la même heure chez toi Je sais, et quand cela arrive, j'ai pas forcément d'actions en cours... donc c'est pas un script qui déconne. Par contre chez moi j'ai pas de pic de CPU, mais bien 0 (sur les 4). enfin plutôt : le soft (windev) qui fait la requête (http) n'a pas eu de réponse de la HC3 pendant ces 3 minutes. J'ai une fois réussi à être devant au moment de ces 3 minutes, tout est figé, interface de la box, application mobile, les capteurs qui réagissent plus, ... Avec ta solution de plage horaire, au lieu d'une heure précise, avec gestion d'un flag, fonctionne très bien, c'est juste lourdo de devoir faire ça... Et faut pas devoir aller aux toilettes avec un éclairage automatique, par ce que ce sera fait à côté
Lazer Posté(e) le 3 septembre 2021 Auteur Signaler Posté(e) le 3 septembre 2021 Tu calcules surement ta charge CPU de façon différente, moi je le fais avec DomoCharts, qui calcule ça en interne dans le QA avant d'exporter vers la DB. Du coup le pic CPU est visible uniquement à la fin du Freeze. La box figée, je l'ai déjà constaté, mais uniquement durant quelques secondes, lorsque j'ai trop d'onglets ouverts en même temps (plus de 4, ça empire si on ouvre 5 ou 6 onglets), et que j'enregistre un QA en cours d'édition. C'est ce qui m'avait fait dire à un moment que c'est le process d'écriture dans la DB qui fige les autres I/O, donc la box qui se met en attente de la disponibilité de la DB. Je ne sais pas si le freeze long a le même origine, les I/O. Il faudrait peut être vacciner la box pour réduire les risques de freeze long
jjacques68 Posté(e) le 3 septembre 2021 Signaler Posté(e) le 3 septembre 2021 il y a 1 minute, Lazer a dit : Il faudrait peut être vacciner la box pour réduire les risques de freeze long 1
Lazer Posté(e) le 6 septembre 2021 Auteur Signaler Posté(e) le 6 septembre 2021 Voici GEA version 7.34 : Corrige la syntaxe abrégée de "Weather" qui utilise la propriété "WeatherCondition" par défaut. Remarque : je ne conseille pas l'écriture abrégée, préférer l'écriture complète. Le document de syntaxe a été mis à jour dans ce sens. Corrige l'option "VariableCache" quand on lui affecte la valeur booléenne false Copier/coller le contenu du fichier LUA téléchargé par dessus le fichier main dans le QuickApp (ou bien télécharger le QuickApp complet disponible en 1ère page) GEA v7.34.lua 2
971jmd Posté(e) le 7 septembre 2021 Signaler Posté(e) le 7 septembre 2021 Salut @Lazer J'aurais souhaité si possible faire une suggestion d'une fonction ou une amélioration de la fonction StopTask StopTask Arrête une tâche mai pas un tâche en cours Petit Test La ligne numéro 2 est censé stopper la tache de la ligne 1 en cours, mais ça ne fonctionne pas je reçois toujours la notification "tache1" local tache1 = GEA.add(true, 30, "tache1") GEA.add(true, 0 , "STOP tache1 dans 10S" , {{"Sleep", 10, {"StopTask", tache1} }})
Lazer Posté(e) le 7 septembre 2021 Auteur Signaler Posté(e) le 7 septembre 2021 Alors, je ne maitrise pas du tout l'usage de StopTask.... je ne sais pas si ta proposition est faisable, il faudrait que je me penche sur la question. Je ne sais pas à quels autres cas d'usages tu penses ? Car pour cet exemple précis tu n'as pas besoin de StopTask. Il te suffit de mettre une VariableCache à une certaine valeur dans les actions de ta seconde ligne, et tester la valeur de cette VariableCache dans les conditions de la première règle.
971jmd Posté(e) le 7 septembre 2021 Signaler Posté(e) le 7 septembre 2021 dans mon cas la solution VariableCache ne vas pas fonctionné il faudrai trouver une solution pour agir directement sur le temps entouré en rouge On pourrait imaginer différentes manières: Encapsuler la valeur temps dans une variable afin que cette dernière soit modifiable: exemple: 30, 5*60.... , -1 , 0 etc la stoppé
Lazer Posté(e) le 8 septembre 2021 Auteur Signaler Posté(e) le 8 septembre 2021 Alors là je ne sais pas faire. Pire, ce que tu veux faire va à l'encontre même du principe de base de GEA.... Du coup je me demande si tu n'aurais pas mieux faire, pour ce scénario précis, de l'écrire à la main en LUA et de le mettre dans une scène dédiée.
971jmd Posté(e) le 8 septembre 2021 Signaler Posté(e) le 8 septembre 2021 C'était juste une idée, ok je comprend. mais il est vrai que pour le moment le StopTask ne stop pas une tâche en cours
Dragoniacs Posté(e) le 9 septembre 2021 Signaler Posté(e) le 9 septembre 2021 Je ne sais pas ce que tu as changé dans la gestion de "VariableCache", mais mes lignes qui les utilisent ne fonctionnent plus. J'ai fait un test très simple, et je constate qu'il ne se passe absolument rien: Code : GEA.add(true,0,"",{"VariableCache","TEST","NON"}) GEA.add({{"Time","09:00","20:00"},{"VariableCache","TEST","NON"}},90,"",{"Global","Pushover","&0&TEST OK"}) Debug : La ligne s'initialise au lancement : [09.09.2021] [11:47:37] [DEBUG] [QA_GEA_26]: Ajout auto #94 : [true] => ["VariableCache",["TEST","NON"]] [09.09.2021] [11:47:37] [DEBUG] [QA_GEA_26]: Ajout auto #95 : ["VariableCache",["TEST","NON"]] ["Time",["09:00","20:00"]] => ["Global",["Pushover","&0&TEST OK"]] Le 0s passe aussi : [09.09.2021] [11:47:38] [DEBUG] [QA_GEA_26]: @0s [Validation*] #94 : [true] => ["VariableCache",["TEST","NON"]] [09.09.2021] [11:47:38] [DEBUG] [QA_GEA_26]: [Démarrage] #94 : [true] => ["VariableCache",["TEST","NON"]] [09.09.2021] [11:47:38] [DEBUG] [QA_GEA_26]: [action] ["VariableCache",["TEST","NON"]] [09.09.2021] [11:47:38] [DEBUG] [QA_GEA_26]: @0s [Validation] #95 : ["VariableCache",["TEST","NON"]] ["Time",["09:00","20:00"]] => ["Global",["Pushover","&0&TEST OK"]] Mais au 90s: [09.09.2021] [11:49:08] [DEBUG] [QA_GEA_26]: @90s [Validation] #95 : ["VariableCache",["TEST","NON"]] ["Time",["09:00","20:00"]] => ["Global",["Pushover","&0&TEST OK"]] Idem à 120s.......
Dragoniacs Posté(e) le 9 septembre 2021 Signaler Posté(e) le 9 septembre 2021 Nouveau test... Ceci fonctionne parfaitement (si ce n'est que l'action Pushover n'est lancée qu'à 120s) GEA.add(true,0,"",{"VariableCache","TEST",true}) GEA.add({"VariableCache","TEST",true},30,"",{"VariableCache","TEST",false}) GEA.add({{"Time","09:00","20:00"},{"VariableCache","TEST",false}},90,"",{"Global","Pushover","&0&TEST OK"}) Je crois comprendre que VariableCache ne tient plus compte que des valeurs booléennes. Si tu souhaite que cela reste comme cela, pas de soucis, j'arrange mon code, mais il faut mettre la notice à jour
Lazer Posté(e) le 9 septembre 2021 Auteur Signaler Posté(e) le 9 septembre 2021 (modifié) Punaise le méga-boulet. Désolé pour ce bug.... qui ne touchait, pour être précis, que les VariableCache de type "string". Les boolean et number n'étaient pas affectés. Voici donc GEA version 7.35 : Corrige le bug des VariableCache de type string. GEA v7.35.lua Remarque en passant, et puisque ça parle pas mal de performances du code LUA ces derniers temps sur le forum. En informatique, manipuler un boolean (true/false), c'est comme manipuler un nombre entier, le test (comparaison de 2 valeurs) est effectué hyper rapidement en un seul cycle de CPU. A l'inverse, manipuler une chaine de caractère, nécessite de faire appel à une fonction (donc déjà plusieurs cycles de CPU) qui va faire une boucle pour comparer octet par octet tous les caractères. Du coup, c'est genre 1000x plus long que la manipulation du booléen. Bon, sur les milliers d'opérations (entrainant des millions de cycles CPU) que fait GEA, ce n'est pas la comparaison qu'une chaine de caractère dans une règle avec VariableCache qui va changer grand chose à la durée d'exécution, mais bon.... je suis formaté informaticien alors moi j'utilise des booléens quand c'est possible. Cela étant dit, pour un humain, il est plus lisible de lire une chaine de caractère contenant "OUI" ou "NON" que de voir un booléen indiquant true/false. Fait comme c'est mieux pour toi. Tout le monde n'a pas la chance d'être geek ascendant nerd Voilà, c'est tout EDIT : ce n'est pas vrai en LUA, voir plus bas Modifié le 9 septembre 2021 par Lazer 2
Fredmas Posté(e) le 9 septembre 2021 Signaler Posté(e) le 9 septembre 2021 Ca je ne le savais pas, et comme lire "oui" ou "non" dans mes variables je m'en cogne pas mal, le but étant que ça fonctionne tout seul de toute façon, par principe "de mieux" coder je vais regarder comment modifier les variables de mes QA quand je le peux Merci @Lazer
jang Posté(e) le 9 septembre 2021 Signaler Posté(e) le 9 septembre 2021 (modifié) il y a 33 minutes, Lazer a dit : Pushpin the mega-ball. Sorry for this bug .... which only affected, to be precise, the VariableCache of type "string". The boolean and number were not affected. Here is GEA version 7.35 : Corrects the bug of VariableCache of type string. GEA v7.35.lua Note in passing, and since it talks a lot about the performance of the LUA code lately on the forum. In computer science, handling a boolean (true / false) is like handling an integer, the test (comparison of 2 values) is performed extremely quickly in a single CPU cycle. Conversely, handling a character string requires calling a function (therefore already several CPU cycles) which will make a loop to compare all the characters byte by byte. So, it's like 1000x longer than the manipulation of the boolean. Well, out of the thousands of operations (resulting in millions of CPU cycles) that GEA does, it is not the comparison that a character string in a rule with VariableCache will change a lot at runtime, but hey .... I am formatted as a computer scientist so I use booleans when possible. That being said, for a human, it is more readable to read a string containing "YES" or "NO" than to see a boolean indicating true / false. Do what is best for you. Not everyone is lucky enough to be an ascendant geek nerd That's it that's all In Lua, all strings created, in code and that are read in, are "interned" which means that there are only one version of the same string stored. This makes comparing if two strings are equal as fast as comparing if 2 integers are equal. The drawback is that it takes a little longer to create strings as they need to be interned (usually put in an efficient hash table and references replaced by the hash value). Java, Lisp and many other languages use the same concept. This is the reason why it's much more efficient to add strings to a table and then do table.concat, or often better to do a string.format than multiple ... concats that creates intermediate strings. It's also a reason why Lua's table lookup is so fast, all strings have a pre-computed hash-value already associated with them. Modifié le 9 septembre 2021 par jang 4
Lazer Posté(e) le 9 septembre 2021 Auteur Signaler Posté(e) le 9 septembre 2021 Very interesting, I didn't knew about interned string. Thank you for the lesson Bon bah du coup vous pouvez continuer à utiliser des string, c'est plus lisible 2
Dragoniacs Posté(e) le 9 septembre 2021 Signaler Posté(e) le 9 septembre 2021 Donc, je garde mes strings, pas besoin d'opter pour les culottes Merci pour le correctif ! Super rapide Envoyé de mon RMX1993 en utilisant Tapatalk 2
triossrf Posté(e) le 17 octobre 2021 Signaler Posté(e) le 17 octobre 2021 Salut, Je me permets de poser une question concernant les boutons Walli et G.E.A. Est-il prévu d'intégrer la gestion des couleurs (led autour du bouton walli) dans une future mise à jour G.E.A? Cela permettrait de ne pas créer de nombreuse scènes (1 scène par bouton) afin de gérer les couleurs. Merci de la réponse. +++
Messages recommandés