Support Gea

**Steven** · le 23 juillet 2015

Oui, tu devrais pouvoir remettre le tout dans une seule scène, mais vu que je n'ai pas non plus une grosse configuration, je ne peux pas te garantir que c'est un gain à 100%, seul tes tests pourrons nous répondre

Pour ta 2ème question, je suis partagé ... vaut-il mieux "écouter" un module ou allez vérifier son état toutes les 30 secondes, je dirais que la solution la plus optimum est les 2. Exemple :

"Si je veux savoir si une porte est ouverte depuis plus de 10 mn."

Rien ne sert d'aller vérifier toutes les 30s si cette dernière est fermée, mieux vaut "écouter" son ouverture et à ce moment là démarrer un compteur ... si les 10mn sont atteintes et qu'on a pas encore reçu de fermeture alors on fait son travail.

Dans le meilleur des mondes GEA ne devrait travailler QUE sur de l'écoute.

C'est ce que je cherche à réécrire mais j'ai n'y le temps, n'y le courage. Peut-être qu'a plusieurs ?

**Domodial** · le 24 juillet 2015

C'est ce que je cherche à réécrire mais j'ai n'y le temps, n'y le courage. Peut-être qu'a plusieurs ?

Je passe mon tour

En tout cas, bien content de te lire Steven !

Je m'y suis remis après des mois, ben je ne comprends plus rien (lol), heureusement que pepite était là

Tout va bien avec la dernière version, même les précédentes, les problèmes que j'ai eu venait de la mise a jour HC2.

Après plusieurs reboot et désinclusion/inclusion de modules (que la maj m'avait flingué), tout est rentré dans l'ordre.... jusqu'a ce que je tombe sur autre chose

Bonne journée a tous.

**pepite** · le 24 juillet 2015

@Steven : ce serait la soluce à plusieurs, entre les mains d'experts ;-) de ce cote la je ne peux pas aider malheureusement. suis sur qu'il va y avoir des clients ;-)

Le forum c'est le but.

De rien @domodial, ne t'inquiete aps,ca revient vite ;-)

**jojo** · le 24 juillet 2015

Pour ta 2ème question, je suis partagé ... vaut-il mieux "écouter" un module ou allez vérifier son état toutes les 30 secondes, je dirais que la solution la plus optimum est les 2. Exemple :

"Si je veux savoir si une porte est ouverte depuis plus de 10 mn."

Rien ne sert d'aller vérifier toutes les 30s si cette dernière est fermée, mieux vaut "écouter" son ouverture et à ce moment là démarrer un compteur ... si les 10mn sont atteintes et qu'on a pas encore reçu de fermeture alors on fait son travail.

Mais tel que GEA est construit actuellement, il fait de toute façon le check toutes les 30s, donc je souhaite éviter de lancer des instances supplémentaire en immédiat (-1), qui va dans la réalité refaire la totalité des actions GEA, et donc tous les tests. Donc il est ainsi possible que plusieurs instances tournent en simultané, et vu la complexité du moteur, il pourrait se mélanger les pinceaux.

**Steven** · le 24 juillet 2015

Avec la version actuelle de GEA, je suis tout àfait d'accord avec toi.

Par contre, en mode "immédiat", il ne refait pas tout les tests, il fonctionne ainsi :

Parcours des GEA.add, si un ID est égale àcelui qui a déclenché le script, alors on l'ajout dans la file de traitement, sinon on l'ignore.

En gros, quand tu fais un GEA.add on ajout ou non dans la file d'attente selon le type d'exécution. pour une exécution standard, on prend tout les GEA.add qui on un nombre de secondes > 0 et pour les "immédiat", on ne prend que ceux qui sont à-1 ET qui concerne cet ID.

Voili voilàencore une petite explication du fonctionnement de la bête :-)

**jojo** · le 24 juillet 2015

et pour le fonctionnement toutes les 30sec, il ne regarde pas ceux qui sont à -1 ?

Alors il faudrait utiliser le plus de -1 possible, pour optimiser les perf ?

**Steven** · le 24 juillet 2015

En effet, le scénario qui tourne toutes les 30 secondes ne regarde pas les -1

if (GEA.source["type"] == "autostart" and tonumber(entry[GEA.keys["SECONDES"]]) >= 0) then

Utiliser plus de -1 est-ce la solution, je ne pense pas car chaque -1 signifie déclenchement d'un nouveau scénario et cela est consommateur de mémoire et de temps (> 1700 lignes de code a charger).

Je pense pas qu'il y ait une réponse à ta question. Je pense que cela dépend de chaque configuration.

**pepite** · le 24 juillet 2015

Merci pour 'explication @steven.

A moi la petite question : quel est dans ce cas le fonctionnement du ALL du GEA.optimize ?

**Steven** · le 24 juillet 2015

Avec le "ALL", c'est tout GEA qui ne va plus chercher les Nom et Pièces des modules, c'est donc toutes les instances (autostart et immédiates) qui bénéficient de l'optimisation au détriment de ce qui sera affiché dans la console.

Dans le cas ou vous avez mis une exécution à 30s et que vous voyez que GEA met 20s, il devient intéressant de mettre le "ALL" afin de redéscendre à 3s d'exécution :-)

**jojo** · le 24 juillet 2015

Si j'ai bien compris le bazard, il ne va PAS rechercher les infos complémentaires en fonction de la valeur GEA.optimize.

donc, si

GEA.typeOptimize["NONE"] -- aucune optimisation (défaut)
C'est comme dans les versions précédentes de GEA
GEA.typeOptimize["IMEDIATE_ONLY"] -- optimisation uniquement des déclenchements immédiats
il ne va pas chercher les infos complémentaires, mais que pour les -1, pour les autres actions, il va les chercher.
GEA.typeOptimize["ALL"] -- optimisation de toutes les entrées GEA.add()
il ne va chercher aucune info complémentaire pour toutes les actions -1 et >0

[ 112 | n/a ] Add Property : ajout de la tache pour lancement instantané (ID:17)

**soulac** · le 24 juillet 2015

Bonjour Messieurs,

Il me semble que la question à déjà était posé mais je ne retrouve plus.

VOila ma question:

Je souhaiterais fermer mon volet à 50 % si mon détecteur de luminosité extérieur est > 1800 . sa OK ma ligne si dessous.

GEA.add({{"Value+",id["D_LUM_EXT"], 1800},{"Value+", id["VR_SAM"], 50},{"Value-", id["VR_SAM"],100}}, 10*60, "Fermeture VR SAM lum ext + 1800",{{"Time","11:50","19:00"},{"Dates","01/05","01/10"},{"Close",id["VR_SAM"],50}})

Maintenant je veux faire la même chose mais si la porte fenêtre est ouvert je ne ferme pas le volet. J'ai fait ceci

GEA.add({{id["OUVERTURE_SALON"], 30},{"Value+",id["D_LUM_EXT"], 1800},{"Value+", id["VR_SALON"], 50},{"Value-", id["VR_SALON"],100}}, 1*60, "Fermeture VR SALON lum ext + 1800 si baie fermé",{{"Inverse"},{"Time","11:50","19:00"},{"Dates","01/05","01/10"},{"Close",id["VR_SALON"],50}})

Mais sa na pas l'aire de marcher . J'ai pas d’erreur sur le GEA mais le volet ne ferme pas.

Une ptite idée SVP

**jojo** · le 24 juillet 2015

donc àton instruction actuelle tu dois juste rajouter la condition que ta porte fenêtre est fermée

GEA.add({{id["OUVERTURE_SALON"]},{"Value+",id["D_LUM_EXT"], 1800},{"Value+", id["VR_SAM"], 50},{"Value-", id["VR_SAM"],100}}, 10*60, "Fermeture VR SAM lum ext + 1800 si baie fermée",{{"Inverse"},{"Time","11:50","19:00"},{"Dates","01/05","01/10"},{"Close",id["VR_SAM"],50}})

le 24 juillet 2015

@Jojo ta compréhension du optimize et ta description 3 post plus haut est bonne

Envoyé de mon SM-G850F en utilisant Tapatalk

**jojo** · le 24 juillet 2015

super cette nouvelle version avec GEA.Apotimize : je suis passé de 4s à 1s pour l'exécution complète de mon GROS GEA entre la valeur NONE et ALL :60: :60:

et l'amélioration de la réactivité pour les scènes immédiates est significative.

Ou comment des "non-professionels" corrigent les erreurs des professionels. Merci Steven

**Sakkhho** · le 24 juillet 2015

tu as supprimé ta seconde instance du coup ?

j'avais fait 2 GEA, j'hesite à tout remettre en une seule, c'est plus propre

IMMEDIATE en anglais prends 2 m

EDIT : j'ai tout rassemblé :-)

**Fredric** · le 24 juillet 2015

Pareil pour moi, pas de soucis apparent et vraiment plus rapide.

je pense avoir trouvé la solution pour mon soucis d'allumage aléatoire:

  local lum_down = {"Value-",id["LUM_SM"], 17}
  GEA.add({"Value",id["Porte_GARAGE"],1}, -1, "", {{"Global", "P_Garage", "Open"}})
  GEA.add({{"Value",id["Porte_GARAGE"],0},{"Global", "P_Garage", "Open"},lum_down} , -1, "oups Garage", {{"turnOn", id["Chevet_Fred"]}})
  GEA.add({"Value",id["Porte_GARAGE"],0}, -1, "", {{"Global", "P_Garage", "Close"}})

j'ai fait un test différent sur chaque ouvrants même avec "Inverse" et la porte du garage avec le code ci-dessus est le seul qui à pas causé problème hier soir.

Alors ce soir, je mets le même code à tous, wait and see.....

**Steven** · le 24 juillet 2015

tu as supprimé ta seconde instance du coup ?

j'avais fait 2 GEA, j'hesite àtout remettre en une seule, c'est plus propre

IMMEDIATE en anglais prends 2 m

EDIT : j'ai tout rassemblé :-)

Pfffftt

**kioneoranga** · le 25 juillet 2015

Bonjour

J'ai mis en place la version 5.4 hier soir.

Il est clair qu'elle est plus réactive.

Personnellement j'ai conserver deux instances, l'une pour les déclenchements immédiat, et l'autre pour l'ensemble des autres actions.

Cependant, je viens de me rendre compte que je ne reçois plus les notifications lorsqu'un événement se produit, est ce lié àl'optimisation qui n'arrive plus àremonter les rooms et names des composants ?

**jojo** · le 25 juillet 2015

tu as supprimé ta seconde instance du coup ?

j'avais fait 2 GEA, j'hesite à tout remettre en une seule, c'est plus propre

IMMEDIATE en anglais prends 2 m

EDIT : j'ai tout rassemblé :-)

oui en effet, j'ai également tout re-rassemblé

@kioneoranga,

Mes notif continuent d'arriver normalement. Tu peux toujours essayer un restant de ta box, cela résout parfois ces problèmes

**kioneoranga** · le 25 juillet 2015

Finalement, un reboot de la box, et les notifs sont à nouveau actives

C'est étrange

Le simple fait de créer de nouvelles scènes et désactivités les anciennes de GEA, les notifs étaient KO.

Enfin l'essentiel c'est que cela soit revenu à la normal.

Désolé du dérangement :-)

Merci Steven pour cette optimisation (même si c'est un workaround) cela permet de récupérer la réactivité d'antan

**Titof_44** · le 25 juillet 2015

Bonjour

Ce code (Merci encore au showRoom GEA et tous les posteurs) marche en V5.33, V5.34 mais pas totalement en V5.40 : L'extinction ne se fait plus.

GEA.add(id["MOUVACUI"], -1, "L'arrière cuisine est allumé à #time#, le #date#",{{"If",{{"Value-", id["LUSTREACUI"],98}}},{"Function", function() fibaro:call(id["LUSTREACUI"], "setValue", "98") end},{"Portable",0}})
local malampeacui = GEA.add({"Value+", id["LUSTREACUI"],89}, 60, "",{{"Value", 55},{"Repeat"}})
local malampeacuidim = GEA.add({"Value-", id["LUSTREACUI"],60}, 2*60,"",{{"turnOff"},{"If", {{"Value+", id["LUSTREACUI"], 1}}}},{"Repeat"})
GEA.add(id["MOUVACUI"], -1, "", {{"RestartTask", malampeacui},{"RestartTask", malampeacuidim}})

Avez-vous une idée ?

Comment faites-vous les copier/coller de code LUA,, les miens sont moches

Merci.

**jojo** · le 25 juillet 2015

@Titof_44

Pour coller "joliment" ton code tu dois cliquer le le bouton "<>" qui se trouve sur la deuxième ligne de mise en forme des messages, juste en dessous de l'icône Smily.

Depuis la v5.40 j'ai également un soucis, le code ci-dessous qui fonctionnait parfaitement dans les version précédentes, n'éteint plus la lampe, malgré que je reçois bien le mail comme quoi elle est allumée

   -- Extinction de la lampe dans tous les cas après 10 min
   GEA.add ({DeviceID["ALARME_ACTIVE"], DeviceID["LUM_HALLENTREE"]}, 10*60, "Extinction du Hall Entrée, car allumée depuis #duration#", {{"Inverse"}, {"turnOff"}, {"Portable", MobileID["V_Nexus5"]}, {"Email", UserID["Vincent"], "ALERTE - Lumière Hall Entrée"}})

**jojo** · le 26 juillet 2015

je m'auto-réponds, il doit y avoir eu une motif entre 5.34 et 5.40 car avec ce code-ci cela fonctionne (j'ai précisé dans l'instruction "turnOff" le nom du device à éteindre)

   -- Extinction de la lampe dans tous les cas après 10 min
   GEA.add ({DeviceID["ALARME_ACTIVE"], DeviceID["LUM_HALLENTREE"]}, 10*60, "Extinction du Hall Entrée, car allumée depuis #duration#", {{"Inverse"}, {"turnOff", DeviceID["LUM_HALLENTREE"]}, {"Portable", MobileID["V_Nexus5"]}, {"Email", UserID["Vincent"], "ALERTE - Lumière Hall Entrée"}})

Question pour Steven :

Il semble que si on ne précise pas l'id du device pour "turnOff" (ou "turnOn"), cela ne fonctionne plus que si le device est le premier de la liste des conditions. S'agit-il d'une modification définitive (auquel cas je modifie mon GEA) ou d'un "bug" qui sera corrigé en 5.41.

Ceci fonctionne, mais alors j'ai perdu ma condition sur l'alarme décativée :

   -- Extinction de la lampe dans tous les cas après 10 min
   GEA.add ({DeviceID["LUM_HALLENTREE"]}, 1*60, "Extinction du Hall Entrée, car allumée depuis #duration#", {{"turnOff"}, {"Portable", MobileID["V_Nexus5"]}, {"Email", UserID["Vincent"], "ALERTE - Lumière Hall Entrée"}})

**pepite** · le 26 juillet 2015

@frederic : alors ?

et tu pourrais ecrire ton code plus simplement juste en mettant le nom de l'id en condition :

id["porte_garage"] pour un test sur ouverture

id["porte_garage"] ...{{"Inverse"} pour un test en fermeture ;-)

personnellement, j'ai encore gardé les 2 instances, je trouve ca pratique..mais je me dis qiand même qu'1 seule ...choix difficile

@jojo : ca doit venir du GEA.optimize alors, sans getname ni getroom, il ne doit pas le récuperer..c'est peut-etre pour cela qu'un turnOn non suivi de l'ID ne fonctionne pas. Je pense que Steven va nous confirmer ;-)

@Titoff : rajoute le nom du module après ton turnOff, d'après ce quqe vient de trouver @jojo, cela devrait fonctionner ;-)

**jojo** · le 26 juillet 2015

Pepite,

un turnOn ou turnOff sans ID fonctionne, A CONDITION que l'ID soit spécifié en premier dans les conditions. Il faudrait peut-être prendre l'habitude de systématiquement préciser l'ID.

J'interprète cela comme une optimisation supplémentaire (qui n'a rien àvoir avec gainent ou géronte) : il ne passe plus son temps àchercher parmi tous les ID des conditions lesquels supportent le turion, turnOff : cela simplifie le code et permet également d'optimiser les performances. Mais est-ce le cas pour toutes les options sans ID ? Si oui, merci àSteven de confirmer, je mettrai àjour le Wiki.

Support Gea

Messages recommandés

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

Steven

Steven

Steven

Images postées

Invité chris6783