Quick App - Gestionnaire d'Événements Automatique - GEA pour HC3

[Fred.domotique]

Pour la partie GEA suspendu, c'est lié au fait que j'ai créer une instance de test du coup j'avais suspendu la principale et ré activer la test. Mais je confirme le défaut est présent.

Pour le lldebug effectivement je ne connaissais pas cette function, je n'avais mis que la fonction debug classique à true.

 

Ci dessous le lldebug de ma GEA test avec un déclenchement -1 positionné après ma commande et qui est donc non fonctionnel

 

ci dessous avec la fonction fonctionnel pour cause d'aucune instance -1 placé après.

 

[jojo]

merci @Lazer pour ces explications.

Je les ais inclues dans mon fichier config. En voici une copie pour mettre dans une prochaine version, afin qu'on ne te pose plus la question ...

function config(GEA)
	-- ===================================================
	-- Configuration générale
	-- ===================================================
	GEA.debug = false   -- |true
    -- affichage de messages basiques, pour aider l'utilisateur à comprendre le fonctionnement (ou non) de ses propres règles
    -- display basic messages to help end-user tp understand the (non-)working on his own rules
    GEA.lldebug = false -- |true
    -- (= Low-Level) : affichage de messages supplémentaires pour aider les développeurs à comprendre les bugs dans GEA
    -- (= Low-Level) : display additional messages to help GEA developpers to understand bugs in GEA
	GEA.portables = {}
end

 

[jojo]

Il y a 3 heures, Fred.domotique a dit :

Pour le lldebug effectivement je ne connaissais pas cette function, je n'avais mis que la fonction debug classique à true.

 

Ci dessous le lldebug de ma GEA test avec un déclenchement -1 positionné après ma commande et qui est donc non fonctionnel

plutôt que des mettre est copies d'écran, ce serait plus lisible sit tu faisait une copier/coller du  log en tant que code </> ici (c'est illisible pour moi, et sûrement très difficile pour @Lazer. Merci

Modifié le 28 mai 2022 par jojo

[Lazer]

Non pas de problème pour lire, j'ai un grand écran, et puis en fin de compte ça permet de garder la couleur et rend donc le log plus lisible qu'un copier/coller en mode texte qui n'est pas toujours simple à lire (même s'il présente d'autres avantages, comme la recherche textuelle)

(par contre, ta citation violente de l'intégralité du post pour écrire une petite ligne en dessous, elle est plutôt difficile à lire )

 

Quant au lldebug, si je ne l'ai pas documenté, c'est à raison, pour ne pas embrouiller les gens avec des options inutiles (sinon il faudrait documenter l'intégralité des options de GEA, et il y en a un paquet, surtout qu'il y en a quelques unes qui restent bien mystérieuses pour moi)

Quand j'en ai besoin, je demande aux gens de l'ajouter, ça va bien ainsi (après s'ils ne savent pas faire un copier/coller c'est un autre problème )

 

Bref, merci @Fred.domotique à première vue j'ai l'impression qu'il y a tout ce qu'il faut.

Il faudra que je me plonge dans l'analyse à l'occasion, mais très honnêtement ça ne sera pas pour tout de suite, car il faudra surement que je tente de reproduire chez moi.

En attendant, vu que tu as une solution qui fonctionne en décalant la règle, je te conseille de procéder ainsi.

[jojo]

il y a 33 minutes, Lazer a dit :

Non pas de problème pour lire, j'ai un grand écran,

cool; car moi sur mon 27", c'était flou ... Je voulais juste te faciliter la vie ...

 

il y a 34 minutes, Lazer a dit :

(par contre, ta citation violente de l'intégralité du post pour écrire une petite ligne en dessous, elle est plutôt difficile à lire )

j'édite mon post.

[Lazer]

C'est vrai que c'est flou.... mais j'arrive à lire en zoomant (32" ici, donc ça laisse de la marge)

 

Merci pour l'édit

[Fred.domotique]

Merci Lazer pour la prise en compte, je reste sur ma solution temporaire, il n'y a pas urgence. L'essentiel est l'avancement global sur GEA qui est vraiment Top pour notre Box.

[Fred.domotique]

Juste petite question sur la config GEA. Est ce que GEA.globalvariables = "GEA_Tasks" est toujours d'actualité sur la version 7 ? (Je précise je migre de l'ancienne GEA V6 sur ma HC2 vers la V7 sur HC3).

 

[Lazer]

Non globalvariables n'existe plus, c'était nécessaire sur HC2 mais inutile sur HC3.

[jojo]

Le 15/05/2022 à 22:21, Lazer a dit :

Oui ça va finir comme ça

Dans la prochaine mise à jour... (pas tout de suite)

La version en page 1 est-elle toujours d'actualité ?

Je peux alors faire les modifs ainsi que quelques fautes de typo (héritage du passé ?) que j'ai vues en commençant à lire (mais pas toutes, tu me connais)

[Lazer]

La version de quoi ?

De la doc de syntaxe ? Dans ce cas oui, c'est la dernière.

Oui il reste surement encore pas mal de fautes dedans, pourtant j'en ai déjà corrigé un certain nombre, mais vu la taille du fichier, je n'ai pas analysé ligne par ligne.

[jojo]

en effet, c'était de la version de la doc. As-tu trop bu ou quoi, que j'allais adapter la version LUA....

 

Ceci dit, tant qu'à faire des modifs dans la doc, je regardais à l'instruction {"Repeat"}, elle ne fonctionne pas avec l'action {"Inverse", #} (mais bien avec {"Inverse"}). Quand je ,dis ne fonctionne pas, c'est que GEA ne se met pas automatiquement en "Running: Yes" lors de la sauvegarde.

 

 

Est-ce que j'ajoute une remarque dans ce sens dans la doc ou tu regardes à corriger le bug ?

 

[Lazer]

Ah, tu as encore trouvé une particularité dont tu as le secret

Dans ce cas tu peux faire la remarque qui va bien dans la doc, si tu la juge pertinente.

Tu pourras lui donner le numéro de version 7.37 afin qu'elle corresponde à la dernière version de GEA en date.

Merci en tout cas.

 

il y a 27 minutes, jojo a dit :

As-tu trop bu ou quoi

Il était 18h24, donc non on contraire, je n'était pas dans mon état normal, l'apéro n'avait pas commencé

 

[Felig]

En parlant de typo, j'en ai trouvé une dans le code LUA de la v 7.37 (pour les rares qui utilisent la version anglaise): il faut remplacer les messages "doesn't exists" par "doesn't exist" (4 occurrences).

[Felig]

 @LazerJe crois qu'il y a un pb avec la fonction de contrôle de quickapp. La voici en développé: en cas d'id multiples, seule la première id est contrôlée (il y un return dans tous les cas après la première id):

 

control = function(id, method)
            if type(id) ~= "table" then id = {id} end
            for i=1, #id do
              local check, message = self.options.number.control(self:findDeviceId(id[i]))
              if check then
                return type(method) == "string", string.format(self.trad.not_string, method)
              else
                return check, message
              end
            end
          end,

Par contre, ça dépasse mes compétences de trouver la correction à apporter...

[Lazer]

En effet, c'est clair, seul le 1er ID est contrôlé.

Merci ça fera un autre correctif à apporter à la prochaine version.

Mais en attendant, je pense que c'est sans impact, tant que tes ID sont bons. Et quand bien même le 2nd (ou 3ème...) ID serait mauvais, ça serait sans impact sur le fonctionnement de GEA, vu que le mauvais ID n'existe pas, il demandera à la HC3 d'exécuter une fonction d'un QA qui n'existe pas, donc il ne se passera rien.

[jojo]

Je relis la doc ...

Je souhaiterait y ajout une précision : 

Quand on dit SUPERIEUR c'est "strictement supérieur" (>) ou "supérieur ou égal" (>=) ?

Idem pour INFERIEUR.

[jojo]

Pour ceci , l'exemple est-il correct ?

-- Je souhaite vérifier l'arrivée des enfants après l'école à midi et le soir. Comment faire au plus simple ?
--
-- Vous pouvez vérifier l'ouverture de la porte à des plages horaires et jours précis

		GEA.add({17, {"Days","Monday,Tuesday,Thursday,Friday"}, {"Time","11:30","13:30"}, {"Time","16:30","18:30"}}, -1, "Porte ouvertes le #date# à #time#")

car GEA exécute les action de conditions multiples si elles sont toute à true.,

or iciil faudrait que l'heure soit comprise entre 1:30 et 13:30 ainsi que entre 16:30 et 18:30, ce qui est impossible.

Je l'aurais fait en 2 lignes :

GEA.add({17, {"Days","Monday,Tuesday,Thursday,Friday"}, {"Time","11:30","13:30"}}, -1, "Porte ouvertes le #date# à #time#")
GEA.add({17, {"Days","Monday,Tuesday,Thursday,Friday"}, {"Time","16:30","18:30"}}, -1, "Porte ouvertes le #date# à #time#")

Mais comme celà vient de maître @Steven, il y a quelque chose que je dois avoir loupé ?

[Lazer]

Je viens de vérifier dans le code, et c'est strictement supérieur (>) et strictement inférieur (<)

 

Pour ton 1er exemple, c'est effectivement impossible, à cause des 2 conditions Time différentes.

La seconde écriture, avec les 2 règles distinctes, est donc correcte.

En alternative, on peut utiliser "Or", ce qui permet de tout écrire en 1 seule ligne :

GEA.add({17, {"(Days)","Monday,Tuesday,Thursday,Friday"}, {"(Or)", {"(Time)","11:30","13:30"}, {"(Time)","16:30","18:30"}}}, -1, "Porte ouvertes le #date# à #time#")

 

On notera que j'ai ajouté des parenthèses autour des conditions "Days", "Or" et "Time" afin de ne pas qu'elles soient considérées comme des triggers, du fait du mode de déclenchement instantané choisi pour cette règle (durée = -1)

Dans le cas présent c'est inutile car ces 3 conditions ne peuvent pas être utilisées comme Trigger, mais :

- il n'est pas exclu qu'elles le soient dans une prochaine version, ce qui pourrait provoquer des effets indésirables sur les règles existantes.

- c'est une bonne habitude à prendre pour écrire ses propres règles, trop de fois j'ai vu des gens se plaindre du comportement inattendu de GEA, car ils avaient un peu trop de triggers...

Exemple :

GEA.add({18, {"Value-", 19, 0}}, -1, "Ouverture fenêtre alors qu'il gêle dehors")

En réalité, cette règle se déclenchera lorsque la fenêtre est ouverte, mais également à chaque fois que le température change d'un dixième de degrés tout en restant sous les 0°C.... et cela même si la fenêtre est fermée.... ça va faire beaucoup de notifications !

Avec les parenthèses c'est OK :

GEA.add({18, {"(Value-)", 19, 0}}, -1, "Ouverture fenêtre alors qu'il gêle dehors")

 

Je pense que tu peux ajouter cette remarque sur les parenthèses et les déclencheurs instantanés dans la doc, car je ne suis pas certain que ça y figure déjà, et l'erreur est courante.

 

A noter que GEA sur HC2 fonctionnait déjà de la sorte, mais bien souvent le problème passait inaperçu car il fallait déclarer manuellement les triggers dans l'entête de la scène.

Ce n'est plus le cas sur HC3 car GEA détecte maintenant automatiquement les triggers, donc les parenthèses sont plus que jamais importantes.

 

Évidemment tout cela ne concerne par les règles classiques à déclenchement sur durée >= 0 (par exemple 30, 60, etc)

 

Modifié le 10 juin 2022 par Lazer

[jojo]

étant en pleine relecture de la doc/syntaxe GEA,

-- "Program" - "StartProgram" : Teste/démarre l'exécution d'un programme d'un module RGBW

	-- SYNTAXE :
	{"Program", <id_module>}
	{"Program+", <id_module>}
	{"Program-", <id_module>}
	{"Program!", <id_module>}
	{"Program", <id_module>, <id_program>}

	-- CONDITIONS :
	GEA.add( {"Program", 72}, 30, "", {ACTIONS} )             -- Retourne le programme en cours du RGB dont l'ID est 72

	-- ACTIONS :
	GEA.add( {CONDITIONS}, 30, "", {"Program", 72, 6} )       -- Démarre le programme 6 du RGB 72
	GEA.add( {CONDITIONS}, 30, "", {"Program", {72, 73}, 6} ) -- Démarre le programme 6 DES RGBS 72 ET 73

je ne vois pas d'exemple (et je n'ai pas de tel module sur ma HC3) pour

	{"Program+", <id_module>}
	{"Program-", <id_module>}
	{"Program!", <id_module>}

et je n'ai pas l'intuition de à quoi cela pourrait servir ...

 

Quelqu'un prut m'aider ?

[jojo]

il n'y a pas de turnOn ?

-- "Filters" : Exécute une action sur plusieurs modules

	-- SYNTAXE :
	{"Filters", "Lights|Blinds", "turnOff|Close|Open"}

et les valeurs TunOn et TurnOff sont-elles également acceptées (histoire d'être consistant avec les fonctions TurnOn et TurnOff ?

[jojo]

ces 2 fonctions ne sont-elles pas similaire (redondantes)

-- "Switch" : Allume ou éteint un module

	-- SYNTAXE :
	{"Switch", <id module>}

	-- CONDITIONS : Ne peut pas être utilisé comme CONDITION

	-- ACTIONS :
	GEA.add( {CONDITIONS}, 30, "", {"Switch", 73} )       -- Allume OU Éteint le module 73 en fonction de son état (si allumé, on éteint ; si éteint, on allume.) \\ TurnOn or TurnOff device 73 depending on the state of the device
	GEA.add( {CONDITIONS}, 30, "", {"Switch", {73, 74}} ) -- Allume OU Éteint le module 73 ET le module 74 en fonction de leur état (si allumé, on éteint ; si éteint, on allume.) \\ TurnOn or TurnOff deviceS 73 and 74 depending on the state of the devices


-- "OnOff" : Allume ou éteint un module selon son état

	-- SYNTAXE :
	{"OnOff", <id_module>}

	-- CONDITIONS :
	GEA.add( {"OnOff!", 73, ""}, 30, "Le module 73 est #value#", {ACTIONS}) -- Retourne si le module 73 est ON ou OFF selon son état\\ Return the state ON or OFF of the device 73

	-- ACTIONS :
	GEA.add( {CONDITIONS}, 30, "", {"OnOff", 73} )                          -- Allume ou éteint le module selon son état, ON ou OFF \\ Switch the device depend of his state (On or OFF)
	GEA.add( true  , 0, "",  {"Global", "ETAT_LUMIERE", {"OnOff", 73}})     -- Assigne ON ou OFF selon l"etat" du module 73 à la variable "ETAT_LUMIERE" \\ Assign On or OFF depend of the state of the deice 73 to the global variable

Ne faudrait-il pas merger les fonctions "Switch" et "OnOff" avec les fonctionnalités de "OnOff". et donc également mettre à jour le tableau initial

-- │ "Switch"                                           │           │         │   X    │ Allume ou éteint un module
-- │ "OnOff"                                            │     X     │         │   X    │ Allume ou éteint un module selon son état

et ainsi on garderait la rétrocompatibilité

[jojo]

ne maîtrisant pas parfaitement vette fonction, je n'ose pas changer la doc sans confirmation :

-- "Transpose" : Transpose les conditions

	-- SYNTAXE :
	{"Transpose", {"valeurs_sources"}, {"valeurs_attendues"}, {"Valeurs à transposer"}}

	-- CONDITIONS :
	GEA.add( {"Transpose!", {true, false}, {"allumée", "éteinte"}, {"TurnOn", 73}, ""}, 0, "La lampe est #value[1]#") -- Si 73 est true, le message retourné sera : "La lampe est allumée" // Si 73 est false, le message retourné sera : "La lampe est éteinte"

exemple à remplacer par ?

	-- CONDITIONS :
	GEA.add( {"Transpose", {true, false}, {"allumée", "éteinte"}, {"TurnOn", 73}, ""}, 0, "La lampe est #value[1]#") -- Si 73 est true, le message retourné sera : "La lampe est allumée" // Si 73 est false, le message retourné sera : "La lampe est éteinte"

 

[jojo]

quels sont les <keyAttribute> possibles ?

-- "CentralSceneEvent" : Utilisable en déclenchement instantané uniquement

	-- SYNTAXE :
	{"CentralSceneEvent", <id_module>, <keyID>, <keyAttribute>}

	-- CONDITIONS :
	GEA.add( {"CentralSceneEvent", 72, 1, "Pressed"}, -1, "", {ACTIONS} ) -- SI le CentralSceneEvent du module 72 a pour keyID : 1 et pour keyAttribute "Pressed"

 

[jojo]

je découvre cette super fonctionnalité :

-- "HeatingThermostatSetpoint" : Teste/modifie la température de consigne de chauffage d'un thermostat

	-- SYNTAXE :
	{"HeatingThermostatSetpoint", <id_thermostat>, <temperature>}

	-- CONDITIONS :
	GEA.add( {"HeatingThermostatSetpoint+", 72, 21}, -1, "Consigne #value# trop chaude", {ACTIONS} ) -- Vérifie si la température de consigne du thermostat 37 est supérieure à 21 degrés

ne faudrait-il pas (pour être exhaustif) ajouter ceci :

GEA.add( {"HeatingThermostatSetpoint", 72, 21}, -1, "Consigne #value#", {ACTIONS} ) -- Vérifie si la température de consigne du thermostat 37 est égale à 21 degrés
GEA.add( {"HeatingThermostatSetpoint+", 72, 21}, -1, "Consigne #value# trop chaude", {ACTIONS} ) -- Vérifie si la température de consigne du thermostat 37 est supérieure à 21 degrés
GEA.add( {"HeatingThermostatSetpoint-", 72, 21}, -1, "Consigne #value# trop froide", {ACTIONS} ) -- Vérifie si la température de consigne du thermostat 37 est inférieur à 21 degrés
GEA.add( {"HeatingThermostatSetpoint!", 72, 21}, -1, "Consigne #value# diffère de 21°C", {ACTIONS} ) -- Vérifie si la température de consigne du thermostat 37 est différente de 21 degrés

si ces fonctionnalités existent,  mais j'imagine que oui.

EDIT2 : 

idem pour : ?

-- "VariableQuickApp" - "VariableQA" : Teste/modifie une variable d'un QuickApp

EDIT1 :

du coup je me demand quelle est la différence entre ces 2 instructions :

-- "HeatingThermostatSetpoint" : Teste/modifie la température de consigne de chauffage d'un thermostat

-- "CoolingThermostatSetpoint" : Teste/modifie la température de consigne de climatisation d'un thermostat

et si on ne pourrait pas rajouter simplement

-- "ThermostatSetpoint" : Teste/modifie la température de consigne d'un thermostat

qui soit synonyme des 2 autres, car :

1. un thermostat n'a qu'un seul point de consigne (peut importe que ce soit un Heating ou Cooling thermostat)
2. c'est le thermostat lui-même (donc pas GEA) qui prend les actions nécessaires.
3. j'imagine que c'est le même code GEA
4. mettre en synonyme ne doit pas être si complexe que ça au niveau de GEA (ce sont "simplement" différentes façons d'appeler la même méthode/fonction.

Modifié le 5 juin 2022 par jojo