Aller au contenu

Messages recommandés

Posté(e) (modifié)
Le 29/05/2023 à 01:53, jojo a dit :

pourquoi l'action Property, si elle ne sert à rien

Il y a des tonnes de conditions et d'actions dans GEA qui "ne servent à rien".... mais si elles existent, c'est qu'à un moment donné, elles ont servi à au moins une personne. Tu peux relire les 482 messages de ce topic, ainsi que ceux dédiés au développement de GEA sur HC2 puis HC3 pour retrouver l'historique complet de la genèse de GEA.
Bon courage :D

 

Le 28/05/2023 à 15:15, jluc2808 a dit :

du côté action :
hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setRingsLightMode', "on")
hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setProperty', "ringUpperColor","green")
hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setProperty', "ringBottomColor","green")

 

Intéressant... même si je trouve ça étrange comme façon de procéder.

Donc tu as vu, il enchaine 3 actions.
Essaye de reproduire à l'identique dans GEA, avec 1 appel de "Call", puis 2 appels de "Property", tout ça dans les actions de la même règle GEA.
GEA exécute les actions d'une règle séquentiellement, dans l'ordre dans laquelle elles sont données.

 

Et bien sûr, avec 1 seul ID, vu que "Call" ne supporte qu'un seul ID.

 

Modifié par Lazer
Posté(e)
Le 30/05/2023 à 13:04, Lazer a dit :

Il y a des tonnes de conditions et d'actions dans GEA qui "ne servent à rien".... mais si elles existent, c'est qu'à un moment donné, elles ont servi à au moins une personne. Tu peux relire les 482 messages de ce topic, ainsi que ceux dédiés au développement de GEA sur HC2 puis HC3 pour retrouver l'historique complet de la genèse de GEA.
Bon courage :D

 

Intéressant... même si je trouve ça étrange comme façon de procéder.

Donc tu as vu, il enchaine 3 actions.
Essaye de reproduire à l'identique dans GEA, avec 1 appel de "Call", puis 2 appels de "Property", tout ça dans les actions de la même règle GEA.
GEA exécute les actions d'une règle séquentiellement, dans l'ordre dans laquelle elles sont données.

 

Et bien sûr, avec 1 seul ID, vu que "Call" ne supporte qu'un seul ID.

 

comme ça fonctionne correctement avec les scènes et que j'ai un autre sujet plus épineux , je vais laisser en l'état (des scènes) et je reprendrais quand j'aurais réglé le sujet lui plus embêtant que je poste après.

 

Posté(e)

bonjour, je voudrais votre retour sur ce code

    -- test pour bso 
-- si appui 1x sur bouton haut id=521 inter fenêtre dressing, alors ouvre le BSO id=148 BSO dressing
GEA.add({"Property", 521, "centralSceneEvent", "keyId=1", "Pressed"},-1,"ouverture du BSO dressing",{"Open", 148})
-- si appui 1x sur bouton bas id=521 inter fenêtre dressing, alors ferme le BSO id=148 BSO dressing
GEA.add({"Property", 521, "centralSceneEvent", "keyId=2", "Pressed"},-1,"fermeture du BSO dressing",{"Close", 148})
-- si appui 2x sur bouton haut ou bas id=521 inter fenêtre dressing, alors stop le BSO id=148 BSO dressing
GEA.add({"Property", 521, "centralSceneEvent", "keyId=1", "Pressed2"},-1,"stop du BSO dressing",{"Stop", 148})
GEA.add({"Property", 521, "centralSceneEvent", "keyId=2", "Pressed2"},-1,"stop du BSO dressing",{"Stop", 148})
-- si appui long sur bouton haut id=521 inter fenêtre dressing, alors ouvre les lamelles du BSO id=148 BSO dressing
GEA.add({"Property", 521, "centralSceneEvent", "keyId=1", "HeldDown"},-1,"ouverture lamelle du BSO dressing",{"Value2", 148, 99})
-- si appui long sur bouton bas id=521 inter fenêtre dressing, alors ouvre les lamelles du BSO id=148 BSO dressing
GEA.add({"Property", 521, "centralSceneEvent", "keyId=2", "HeldDown"},-1,"fermeture lamelle du BSO dressing",{"Value2", 148, 1})
    -- fin test bso

Pour l'instant j'ai mis 2 clics pour faire un stop, ce qui n'est pas très intuitif pour l'utilisateur, mon objectif serait de n'avoir qu'un clic pour ouvrir (bouton haut) ou fermer (bouton bas) et si en court de mouvement le même clic fait un stop

pour faire cela je pensais ajouter une variable avec l'état "ATTENTE" qui change d'état si il y a déjà eu 1 clic (haut ou bas) "MOUVEMENT", dans ce cas je ne sais pas comment remettre la variable à "ATTENTE" parce que le retour d'état/position du BSO n'est pas fiable et surtout met un certains temps aléatoire avant d'être remonté, quand c'est remonté, donc je peux pas m'en servir pour repasser la variable à "ATTENTE"

débutant avec GEA j'aurais besoin de votre aide pour ce sujet.

 

NOTA:  le BSO est géré par un FGR223 au tableau électrique et les boutons sont des Walli controller sur secteur dans les plots d'encastrement dans les murs, je n'ai pas la possibilité de lier l'inter avec les commandes en filaire et avec la fonction association directe zwave ça ne fonctionne pas correctement.

Posté(e) (modifié)

Bonjour, 

Petite bizarrerie, je  ne reçois plus depuis qques jours les notifs envoyées depuis GEA, je ne comprend pas ce qui pourrait occasionner cela.

Une petite idée ?

 

J'ai même l'impression que les commandes ou il y a une notification ne s'exécutent plus ????

Merci

Modifié par cseb62
Posté(e)

Tu as fait la dernière mise à jour beta ?

Ou autre modification sur ta box, ou bien ton téléphone ?

Est-ce que les notifications provenant de la box elle-même, d'autres QuickApps, ou bien de Scène fonctionnent toujours ?

Bref il faut isoler le problème, car en l'état, je n'ai pas d'idée... car chezmoiçamarche !

 

Le 02/06/2023 à 07:20, jluc2808 a dit :

...je pensais ajouter une variable avec l'état "ATTENTE"...

Tu peux faire ça avec "VariableCache".
Après pour ton scénario, désolé c'est trop compliqué pour toi... mais ce n'est pas tant un problème de GEA que de logique.

Une fois que tu auras la logique dans ta tête, il suffit de le transposer dans GEA en conditions+actions.

 

(j'ai beaucoup de règles GEA (environ 200), mais elles sont globalement assez simples, j'ai évité les scénarios trop complexes)

Posté(e)

bon pour l'instant avec le code déjà en place je n'ai pas de déclenchement

-- si appui 1x sur bouton haut id=521 inter fenêtre dressing, alors ouvre le BSO id=148 BSO dressing
GEA.add({"Property", 521, "centralSceneEvent", "keyId=1", "Pressed"},-1,"ouverture du BSO dressing",{"Open", 148})

déjà cette partie ne fonctionne pas, je ne vois aucun déclenchement sur appui court de l'inter en question via la console. c'est donc que mon code n'est pas bon.

j'ai essayé de transposer en GEA  une scène qui fonctionne

{
  conditions = { {
      id = 521,
      isTrigger = true,
      operator = "==",
      property = "centralSceneEvent",
      type = "device",
      value = {
        keyAttribute = "Pressed",
        keyId = 1
      }
    } },
  operator = "all"
}

 

Posté(e)

OK donc quand tu mets le doigt sur le problème c'est plus simple :D

Essaye la condition comme ceci (ça fonctionne chez moi).... d'ailleurs tu devrais commencer par regarder la doc de syntaxe car il y a également des exemples identiques :

{"CentralSceneEvent", 521, 1, "Pressed"}

là normalement tu devrais avoir un déclenchement.

 

Et pour info la condition "Property" ne peut pas être utilisé dans ce cas, car "centralSceneEvent" n'est pas une propriété du device, tu peux vérifier dans son JSON.

Attention à ne pas confondre le JSON du module, et la syntaxe des triggers dans les scènes.... ça se ressemble... mais c'est différent.... trompeur !

Posté(e)
Le 29/05/2023 à 01:53, jojo a dit :

Oui, merci du rappel.

Mais donc je reste toujours avec ma question : pourquoi l'action Property, si elle ne sert à rien (sauf à modifier les propriétés "pour faire joli")

 

Je suis bien d'accord que cela n'a rien à voir avec GEA, mais c'est juste pour mourir moins bête ...

Je viens de penser à toi :wub:

Je suis tombé par hasard (c'est pas un vrai hasard, c'est grâce à la question de jluc2808) sur certaines de mes règles GEA, oubliées depuis bien longtemps car elles fonctionnent depuis .... pfiou... au moins tout ce temps.... qui utilisent "Property", voici 2 exemples :

-- Extinction de l'ampli lorsque la lecture d'une source est terminée
GEA.add({{"Property", id["QA_YAMAHA"], "state", "stop"}}, 5*60, "Lecture terminée => Ampli OFF", {{"TurnOff", id["QA_YAMAHA"]}}, "Lecture terminée => Ampli OFF")

-- Si on sonne et que Kodi est allumé, affiche la caméra
GEA.add({id["SONNETTE"], {"(Property)", id["QA_KODI"], "power", true}}, -1, "", {{"QuickApp", id["QA_KODI"], "camera", 3}}, "Sonnette Kodi Caméra")

 

Posté(e) (modifié)
Il y a 3 heures, Lazer a dit :

Tu as fait la dernière mise à jour beta ?

Ou autre modification sur ta box, ou bien ton téléphone ?

Est-ce que les notifications provenant de la box elle-même, d'autres QuickApps, ou bien de Scène fonctionnent toujours ?

Bref il faut isoler le problème, car en l'état, je n'ai pas d'idée... car chezmoiçamarche !

 

Tu peux faire ça avec "VariableCache".
Après pour ton scénario, désolé c'est trop compliqué pour toi... mais ce n'est pas tant un problème de GEA que de logique.

Une fois que tu auras la logique dans ta tête, il suffit de le transposer dans GEA en conditions+actions.

 

(j'ai beaucoup de règles GEA (environ 200), mais elles sont globalement assez simples, j'ai éviter les scénarios trop complexes)

Alors les notifs natives a la box fonctionnent

Mais celle de gea plus rien... Par exemple même la notifs de démarrage de gea je ne la reçois plus... 

Pourtant je n'ai pas changer de tel... Et rien fait de spécial.... 

Je suis en version 5.140.17. 

Modifié par cseb62
Posté(e)
Il y a 15 heures, Lazer a dit :

OK donc quand tu mets le doigt sur le problème c'est plus simple :D

Essaye la condition comme ceci (ça fonctionne chez moi).... d'ailleurs tu devrais commencer par regarder la doc de syntaxe car il y a également des exemples identiques :


{"CentralSceneEvent", 521, 1, "Pressed"}

là normalement tu devrais avoir un déclenchement.

 

Et pour info la condition "Property" ne peut pas être utilisé dans ce cas, car "centralSceneEvent" n'est pas une propriété du device, tu peux vérifier dans son JSON.

Attention à ne pas confondre le JSON du module, et la syntaxe des triggers dans les scènes.... ça se ressemble... mais c'est différent.... trompeur !

ce qui m'a induit en erreur c'est que dans le json on trouve "CentralSceneSupport" et pas "CentralSceneEvent" et que le LUA met "Property=CentralSceneEvent", comme tu le dis trompeur!

merci de cette rectification.

 

Posté(e)
Il y a 16 heures, Lazer a dit :

Tu as fait la dernière mise à jour beta ?

Ou autre modification sur ta box, ou bien ton téléphone ?

Est-ce que les notifications provenant de la box elle-même, d'autres QuickApps, ou bien de Scène fonctionnent toujours ?

Bref il faut isoler le problème, car en l'état, je n'ai pas d'idée... car chezmoiçamarche !

 

Tu peux faire ça avec "VariableCache".
Après pour ton scénario, désolé c'est trop compliqué pour toi... mais ce n'est pas tant un problème de GEA que de logique.

Une fois que tu auras la logique dans ta tête, il suffit de le transposer dans GEA en conditions+actions.

 

(j'ai beaucoup de règles GEA (environ 200), mais elles sont globalement assez simples, j'ai éviter les scénarios trop complexes)

OK, la logique sera la suivante

Pour la variable

- une variable "statut_bso_dressing" qui va prendre les valeurs "ATTENTE" par défaut

- qui prendra la valeur "MOUVEMENT" si on fait 1 clic haut ou bas sur l'interrupteur si sa valeur était ATTENTE

- qui repassera dans tous les cas à "ATTENTE" après la valeur en seconde du temps de montée (paramètre 156 du BSO)

 

Pour les actions

- si 1 clic haut sur inter et valeur de statut_bso_dressing = ATTENTE alors on déclenche l'action "Open" et on passe la variable statut_bso_dressing à "MOUVEMENT"

- si 1 clic haut sur inter et valeur de statut_bso_dressing = MOUVEMENT alors on déclenche l'action "Stop" et on passe la variable statut_bso_dressing à "ATTENTE"

 

- si 1 clic bas sur inter et valeur de statut_bso_dressing = ATTENTE alors on déclenche l'action "Close" et on passe la variable statut_bso_dressing à "MOUVEMENT"

- si 1 clic bas sur inter et valeur de statut_bso_dressing = MOUVEMENT alors on déclenche l'action "Stop" et on passe la variable statut_bso_dressing à "ATTENTE"

 

- si 1 clic long haut sur inter et valeur de statut_bso_dressing = ATTENTE alors on déclenche l'action "Value2 (position des lamelles)" à 99 (ouverte) et on passe la variable statut_bso_dressing à "ATTENTE"

- si 1 clic long bas sur inter et valeur de statut_bso_dressing = ATTENTE alors on déclenche l'action "Value2 (position des lamelles)" à 0 (fermée) et on passe la variable statut_bso_dressing à "ATTENTE"

 

 

sur la base de cette logique (merci de me dire si j'ai omis quelque chose ou fait une erreur)

@lazer me propose d"utiliser VariableCache pour la variable  - même en regardant la documentation j'ai un doute sur comment déclarer cette VariableCache  ?

pour déclarer la variable est-ce que je dois mettre 
GEA.add("VariableCache", "statut_bso_dressing", "ATTENTE") 

ou 

GEA.add(true, -1, "déclaration VariableCache statut_bso_dressing", {"VariableCache", "statut_bso_dressing", "ATTENTE"})

ou tout simplement 

local statut_bso_dressing = "ATTENTE"
et ensuite utiliser 
GEA.add({"VariableCache", "statut_bso_dressing", "ATTENTE"}, -1, "", {Action})

dans tous les cas est-ce que ma variable repassera à ATTENTE toutes les 30 secondes ? (cycle GEA) 

désolé si tout cela est trivial pour vous et d'avance merci pour vos réponses

Posté(e)
Il y a 18 heures, Lazer a dit :

Je viens de penser à toi :wub:

Je suis tombé par hasard (c'est pas un vrai hasard, c'est grâce à la question de jluc2808) sur certaines de mes règles GEA, oubliées depuis bien longtemps car elles fonctionnent depuis .... pfiou... au moins tout ce temps.... qui utilisent "Property", voici 2 exemples :



 

Merci,

mais je ne vois ici que des conditions (et ok pour les conditions)

Mais on parlait des actions (et tu m'avais répondu ensuite pour les actions)

Posté(e)

Si tu as besoin d'initialiser ta variable cache au démarrage de GEA, tu peux utiliser cette règle (inspirée de celle proposée dans la config par défaut) :

GEA.add(true, 0, "déclaration VariableCache statut_bso_dressing", {"VariableCache", "statut_bso_dressing", "ATTENTE"}, "Démarrage GEA")

Note la durée = 0 et non pas -1, à part cela c'est similaire à ta 2nde proposition.

 

C'est une règle qui ne sera exécutée qu'une seule fois au démarrage de GEA.

 

 

Il y a 15 heures, cseb62 a dit :

Alors les notifs natives a la box fonctionnent

Mais celle de gea plus rien... Par exemple même la notifs de démarrage de gea je ne la reçois plus... 

Pourtant je n'ai pas changer de tel... Et rien fait de spécial.... 

Je suis en version 5.140.17.  

Très étrange.... il doit y avoir quelque chose qui a changé quelque part sur ta config, car GEA ne peut pas décider du jour au lendemain d'arrêter d'envoyer les notifications.

Au cas où, vérifie l'ID ou le nom de ton téléphone que tu as déclaré dans GEA.portables

Posté(e)

@jluc2808, ta question initiale pour l'utilisation de GEA n'é†ait pas de surveiller certains modules critiques, s'ils n'étaient pas morts ? 

Posté(e)
il y a 36 minutes, Lazer a dit :

Si tu as besoin d'initialiser ta variable cache au démarrage de GEA, tu peux utiliser cette règle (inspirée de celle proposée dans la config par défaut) :


GEA.add(true, 0, "déclaration VariableCache statut_bso_dressing", {"VariableCache", "statut_bso_dressing", "ATTENTE"}, "Démarrage GEA")

Note la durée = 0 et non pas -1, à part cela c'est similaire à ta 2nde proposition.

 

C'est une règle qui ne sera exécutée qu'une seule fois au démarrage de GEA.

 

 

Très étrange.... il doit y avoir quelque chose qui a changé quelque part sur ta config, car GEA ne peut pas décider du jour au lendemain d'arrêter d'envoyer les notifications.

Au cas où, vérifie l'ID ou le nom de ton téléphone que tu as déclaré dans GEA.portables

Bon j'ai restauré ma dernière sauvegarde... Tout refonctionne... Très étrange effectivement. 

Posté(e)

oui, mais avais-tu vérifié avant le restore que cette ligne existait toujours (car tu aurais pu l'avoir détruite sans le savoir)

	GEA.portables = {"OnePlus 9 Pro",}
    -- list of devices via /api/iosDevices/

 

Posté(e)
Il y a 20 heures, jojo a dit :

@jluc2808, ta question initiale pour l'utilisation de GEA n'é†ait pas de surveiller certains modules critiques, s'ils n'étaient pas morts ? 

@jojo oui c'est exact, j'ai implémenté au début avec

 

 GEA.add({"Deads"}, 30, "test de tous les modules pour savoir s'il y a un qui est mort", {"Deads"})

j'en ai régulièrement 1 qui se retrouve dans cette situation, j'ai mis une notification spécifique sur ce module. Il s'agit d'un FGS223 en limite du réseau zwave et qui ressort (via l'appli z-wave_network_hc3_correct.php) comme n'ayant pas de lien avec le reste (ce qui me semble bizarre) puisque une fois que j'ai pu le "reconnecter" il fonctionne, mais visiblement pas bien , puisque je le retrouve dans les Dead de temps en temps. 

Posté(e)
Il y a 20 heures, cseb62 a dit :

Si tu as besoin d'initialiser ta variable cache au démarrage de GEA, tu peux utiliser cette règle (inspirée de celle proposée dans la config par défaut) :


GEA.add(true, 0, "déclaration VariableCache statut_bso_dressing", {"VariableCache", "statut_bso_dressing", "ATTENTE"}, "Démarrage GEA")

Note la durée = 0 et non pas -1, à part cela c'est similaire à ta 2nde proposition.

 

C'est une règle qui ne sera exécutée qu'une seule fois au démarrage de GEA.

merci de cette syntaxe, pour ma gouverne

- sera-t-il mieux ou plus efficace d'utiliser (comme suggéré) une VariableCache qu'une variable dite locale ?

- si je ne veux pas que ma variable soit réinitialisée à chaque démarrage de GEA et si je veux conserver sa valeur dans tous les cas, dois-je plutôt utiliser une variable Globale ?

 

dans la doc (très bien faite - merci @Lazer) il est mentionné la structure de GEA.add(condition , durée, notification, action) avec 4 arguments, alors je n'ai pas compris le 5ème argument "Démarrage GEA"

 

En terme de performance et de réactivité, vaut-il mieux utiliser des scènes (j'en aurai 5 + 1 variable pour faire la gestion du BSO) ou le passage par GEA sera-t-il plus efficace (moins consommateur de ressource, plus réactif, plus fiable en exécution, ...) ? 

Posté(e)

Tu ne peux pas utiliser de variable locale (au sens LUA du terme) dans GEA, car les règles ne sont lues et analysées qu'une seule fois, au démarrage de GEA.

Ensuite, à chaque cycle de 30s, tout se passe dans la mémoire de GEA, la fonction utilisateur setEvents() n'est pas re-exécutée.

C'est pour cela que les variables caches ont été créées.
C'est une façon indirecte de manipuler des variables locales dans GEA.

 

Effectivement si tu as besoin de persistance entre 2 redémarrage de GEA, il faut passer par un mécanisme de stockage dans la DB de la HC3 (= sur disque).
Donc variables globales, ou bien encore propriété des modules (physiques Z-Wave ou virtuel QuickApps)

 

Rendons à César ce qui appartient à César, je ne suis pas à l'origine de la doc (ni de GEA d'ailleurs), je crois bien que c'est @pepite qui a fait les premières versions, à l'époque de GEA pour HC2.

 

Le 5ème argument (optionnel) c'est juste un texte pour donner un nom à la règle.

ça ne sert à rien d'autre qu'à faire joli dans le log de GEA... disons que c'est plus lisible pour un humain de voir le nom de la règle que la liste des conditions avec des ID numériques.
 

En ce qui concerne la performance et la réactivité... difficile de répondre... car ça va fortement dépendre de la façon dont c'est codé (à la fois en règles GEA, mais aussi en LUA dans les scènes).

Si c'est important pour toi, il faut tester les 2 cas de figure... ensuite tu pourras mesurer en terme de ressenti utilisateur (délai d'action sur les BSO), et aussi monitorer l'utilisation processeur de la box (avec DomoCharts par exemple)

Une fois tout bien optimisé, il est probable que ça soit plus efficace avec des scènes.... mais perso je ne suis pas fan des scènes, je trouve que c'est plus complexe à maintenir.
Je préfère GEA, car dans mon Notepad++, dans un seul fichier, j'ai l'ensemble de tous mes scénarios sur la box. Avec les fonctions recherche et la mise en surbrillance il est facile de retrouver les règles qui concernent tel ou tel module, profile, zone de chauffage, etc.

Au final, j'ai environ 200 règles GEA, et seulement 3 scènes (pour des utilisations très spécifiques : alarme, sonnette, et réveil)

Pour autant, je vois que le forum officiel que certains ont des centaines de scènes, donc ça dépend des habitudes :)

 

Posté(e)

@Lazer merci de ces explications

pour les variables avec ton explication je pensais utiliser une variable 'locale' pour mettre:

- donner un nom aux id plutôt que les id eux même, c'est plus parlant

- stocker les valeurs de temps de montée des BSO

et utiliser les VariableCache pour les changements d'état, après réflexion, le risque que la valeur 'MOUVEMENT' soit transformer en 'ATTENTE' si redémarrage de GEA en cours de mouvement d'un volet avec une action stop au milieu est suffisamment faible pour tester avec ce mécanisme.

 

je verrais comment tester la différence entre scène et GEA, surtout sur la partie réactivité qui est le point end-user le plus sensible.

 

Posté(e)

Alors oui pour le tableau d'ID tu peux utiliser une variable locale (c'est le cas dans le fichier exemple fourni avec GEA), car ces ID ne sont lus qu'une seule fois au démarrage de GEA, lors de l'analyse initiale des règles.
A ce moment, l'interpréteur LUA remplace les noms des variables par leur contenu (= valeur numérique), et c'est bien cette valeur numérique qui restera dans la mémoire de GEA pendant toute son exécution, puisque par principe, les ID des modules ne changent pas.

 

Pareil pour tes temps de monté de BSO.

 

Et effectivement, utiliser VariableCache pour les valeurs qui vont changer dans le temps, entre différents cycles de GEA.

 

Quant à la réactivité ressentie par l'humain, il est probable que tu ne fasses pas de différence entre GEA et une scène, on parle de millisecondes là...

Par contre la façon dont tu vas utiliser GEA va avoir une influence considérable. Entre un déclenchement instantané (durée = -1) et un déclenchement automatique (cycle de 30s), là forcément, ça change tout.
Il faut bien sûr utiliser -1 si tu as besoin de réactivité, et le cycle habituel (0, 30, 60, etc) sinon.

Exemples basiques :

- détection de mouvement => allumage lumière : évidemment on utilise le déclenchement instantané avec durée = -1

- il fait nuit et la porte du garage est restée ouverte => notification : là une durée de plusieurs minutes est pertinent.

 

Posté(e)

bonsoir,

C'est la cata pour moi : mon GEA ne fait plus ses cycles de vérif tputes les 30s

or sur mon GEA de test j'ai bien

[13.06.2023] [22:12:03] [DEBUG] [QA_GEA_850]: ... vérification en cours #172 @5160s...
[13.06.2023] [22:12:33] [DEBUG] [QA_GEA_850]: ... vérification en cours #173 @5190s...
[13.06.2023] [22:13:03] [DEBUG] [QA_GEA_850]: ... vérification en cours #174 @5220s...

mais rien de tout çca sur mon GEA de prod.

Une piste ? (ce ne sont que 200règle qui ne fonctionnent plus :1:

Et pourtant, il affiche Running : Oui (et le débug affiche qqch quand je fais OFF / ON)

 

 

r

Posté(e)

je viens à l'instant de trouver : j'ai désactivé 2 règles qui me semblaient bonnes (puisqu'il me mettait Running oui - et que quand je fais une faute de frappe, il me met non)

Je n'avais pas mis le log, car il aurait été bcp trop long.

Mais maintenant que j'ai identifié la règle (j'ai juste désactivé en désespoir de cause les 2 que j'avais créées hier soir), je ferai un log plus précis pour comprendre où est l'erreur (il ne devrait pas afficher Ruuning oui)

Maintenant bonne nuit !

×
×
  • Créer...