Aller au contenu

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


Lazer

Messages recommandés

afin de garder la même logique dans les instructions pour

-- "PictureToEmail" - "PhotoToMail" : Envoi une capture d'une caméra à une adresse email

ne rajouterait-on pas les synonymes suivants (partout Mail ou Email)

-- "PictureToMail" - "PhotoToEmail" : Envoi une capture d'une caméra à une adresse email

 

Sorry, @Lazer, ma proposition initiale de relecture de la doc n'avait pas pour objectif d'allonger ta ToDo list ...

Lien vers le commentaire
Partager sur d’autres sites

action GEA à exécuter au démarrage de GEA (= démarrage box ou sauvegarde config GEA)

Je me posais la question de quelle était la signification d'une durée de 0.

Car dans la doc il est fait clairement mention que les durées doivent être :

  • >0 
  • -1 : si instantané

et je viens de lire cette particularité (similaire à la particularité -1)

	GEA.add( {"Weather" , "WeatherCondition", "Cloudy"}, 0, "#value#", {ACTIONS} ) -- Ne vérifie QUE si la météo indique "Cloudy" ET retourne la valeur de "Weather" au démarrage de GEA (durée :"0") \\ Check only if Weather is Cloudy and return the value of the Weather

si vous confirmez, je pense qu'il faudrait le préciser au début de la doc, là où on parle des durées -1

Lien vers le commentaire
Partager sur d’autres sites

comme il existe la possibilité d'envoyer une photo par mail à quelqu'un qui n'est pas défini comme utilisateur de la HC3, 
ne serait-il pas "facile" d'encore améliorer la fonction "Email" pour pouvoir y préciser une adresse mail à la place d'un id utilisateur ?

-- "Email" : Envoi un email à un utilisateur

	-- SYNTAXE :
	{"Email", <id_user>, <"Message du mail">}
	{"Email", <"nom_user">, <"Message du mail">}
	{"Email", <id_user>, <"Message du mail">, <"Sujet du mail">}
	{"Email", <"nom_user">, <"Message du mail">, <"Sujet du mail">}

si tu veux des idées, j'en aurai toujours ... :3:

Lien vers le commentaire
Partager sur d’autres sites

@MAM78, je relis toute la doc, pourrais-tu SVP  me fournir ce que je dois y inclure pour ta fonctionnalité ?

-- "StringToAlpha" : par MAM78

	-- SYNTAXE :
	{"StringToAlpha", "<condition>", "<value>"}

	-- CONDITIONS :

	-- ACTIONS : Ne peut pas être utilisé comme ACTION

 

Lien vers le commentaire
Partager sur d’autres sites

quelles sont les valeurs possibles/autorisées/interprétées pour <jours> ?

je voudrais mettre une liste exhautive dans la doc

-- "Days" : Teste le jour actuel de la semaine

	-- SYNTAXE :
	{"Days", <jours>}

	-- CONDITIONS :
	GEA.add( {"Days", "Monday"}        , 30, "", {ACTIONS} ) -- Ne vérifie QUE si nous sommes LUNDI \\ Check only if the DAY is Monday
	GEA.add( {"Days", "Monday, Friday"}, 30, "", {ACTIONS} ) -- Ne vérifie QUE si nous sommes LUNDI ET VENDREDI \\ Check only if the DAY is Monday and Friday
	GEA.add( {"Days", "WeekDays"}      , 30, "", {ACTIONS} ) -- Ne vérifie QUE pendant les jours de la semaine \\ Check only during the days of a the week
	GEA.add( {"Days", "WeekEnd"}       , 30, "", {ACTIONS} ) -- Ne vérifie QUE le WeekEnd \\ Chek Only during WeekEnd (Saturday, Sunday)

 

Lien vers le commentaire
Partager sur d’autres sites

Il y a 13 heures, Lazer a dit :

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.

je vais essayer d'écrire qqch dans ce sens, car

  • je ne suis pas sûr de tout comprendre à 100%
  • pourquoi notif si variation de temp ext (19) de 0.1°C même si fenêtre (18) fermée ? OK si fenêtre ouverte ...
  • il faut encore que j'intègre pourquoi on ne souhaite pas de trigger si on met -1.
  • le soucis actuel viendrait que les triggger fonctionnent comme des "A chaque fois que" la condition est remplie, alors que si c'était des trigger du type "Dès que" (et que donc pour qu'il soit à nouveau effectif, il faut d'abord que la condition ne soit plus remplie. (C'est une distinction dans le type de trigger qu'il fallait systématiquement indiquer dans la Lifedomus - elle avait aussi de bons côtés). Si cela est possible de faire au niveau du code GEA, alors on oublie les () et tous les problèmes actuels.

 

N.B. j'ai inclus ton exemple ave le "Or",sans les (), pour éviter des questionnements, tant que je n'ai pas une explication super claire à donner :

-- 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
    -- option 1 :
		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#")
	-- ou option 2 :
		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#")

Au niveau de la performance de GEA, est-ce mieux privilégier les -1 ou de mettre 30 (pour ce dont l'instantané n'est pas indispensable) ?

 

Modifié par jojo
Lien vers le commentaire
Partager sur d’autres sites

Il y a 10 heures, jojo a dit :

je ne suis pas sûr de tout comprendre à 100%

Dans ce cas fait un copier/coller de mon explications :)

 

Il y a 10 heures, jojo a dit :

pourquoi notif si variation de temp ext (19) de 0.1°C même si fenêtre (18) fermée ? OK si fenêtre ouverte ...

Parce que dans le 1er exemple, "Value" n'est pas entre parenthèses, donc c'est un trigger, donc cette condition fera un déclenchement instantané de GEA à chaque changement de la valeur du module (c'est à dire à chaque fois que la température varie de 0.1°C).

Rien de compliqué, c'est juste le fonctionnement de base de GEA en fait.

Il y a 10 heures, jojo a dit :

il faut encore que j'intègre pourquoi on ne souhaite pas de trigger si on met -1.

Parce que tu peux très bien vouloir déclencher une notification, une action, lorsqu'une des condition est le trigger, alors que les autres conditions ne sont que des ... conditions !

Typiquement dans mon exemple, la porte s'ouvre (c'est le trigger), selon si la température est négative (une simple condition, mais pas un trigger)

 

Je suis persuadé que quand tu avait tes 700 règles sur GEA pour HC2 tu avais des cas similaires, tellement c'est élémentaire.

 

Il y a 10 heures, jojo a dit :

le soucis actuel viendrait que les triggger fonctionnent comme des "A chaque fois que" la condition est remplie, alors que si c'était des trigger du type "Dès que" (et que donc pour qu'il soit à nouveau effectif, il faut d'abord que la condition ne soit plus remplie. (C'est une distinction dans le type de trigger qu'il fallait systématiquement indiquer dans la Lifedomus - elle avait aussi de bons côtés). Si cela est possible de faire au niveau du code GEA, alors on oublie les () et tous les problèmes actuels.

Pas sûr de comprendre, mais n'oublie pas les fondamentaux de GEA :

- durée >= 0 : les actions sont déclenchées quand toutes les conditions de la règles sont validées depuis X secondes (avec X >= 0 donc)... tout en n'oubliant pas que GEA fait un cycle de vérification toutes les 30 secondes.

- durée = -1 : les actions sont déclenchées instantanément lorsque le (ou les) trigger(s) change de valeur, et que toutes les autres conditions sont également valides

 

 

Il y a 10 heures, jojo a dit :

N.B. j'ai inclus ton exemple ave le "Or",sans les (), pour éviter des questionnements, tant que je n'ai pas une explication super claire à donner :

Bah c'est pas bon, tu as oublié les parenthèses justement.... cf mes explications, il faut prendre ce réflexe, sinon j'en connais qui vont avoir des mauvaises surprises lors des prochaines versions de GEA.

Donc puisque tu mets à jour la doc de syntaxe, autant aller jusqu'au bout de la logique, et écrire les choses correctement :)

Sinon on reviendra sans cesse dessus...

 

Il y a 10 heures, jojo a dit :

Au niveau de la performance de GEA, est-ce mieux privilégier les -1 ou de mettre 30 (pour ce dont l'instantané n'est pas indispensable) ?

Je ne comprend pas la question de la performance, les 2 modes de fonctionnement n'ont juste rien à voir, tu choisis la durée en fonction de tes besoins.

Si l'instantané n'est pas indispensable, dans ce cas tu as ta réponse dans tes question, utilise le mode par intervalle (appelé mode automatique par Steven)

  • Thanks 1
Lien vers le commentaire
Partager sur d’autres sites

merci pour tes très claires explications ; j'ai compris (enfin!) les () : je mettrai une remarque particulière en ce sens pour les modes de déclenchement -1. (et corrigerai l'exemple)

 

De ce que je comprends, il faut réserver le -1 à ce qui est indispensable de se déclencher immédiatement.

Quand je parlais de performance de GEA, je voulais limiter le comptage des cycles, en mettant -1

Lien vers le commentaire
Partager sur d’autres sites

"performance" c'est un terme générique qui ne veut pas dire grand chose si on ne précise pas le contexte.

 

2 exemples :

  • si on cherche à réduire l'utilisation CPU de la box, alors il vaut mieux ne pas utiliser de déclenchement instantané (avec durée = -1), car c'est plus ou moins l'équivalent de démarrer une nouvelle instance de GEA (un peu comme une nouvelle instance de scène à l'époque de la HC2), car il va relire la config, analyser les règles, etc...
    Mais attention je tiens à modérer mon propos, ce que je dis dans la phrase précédente est très théorique. La HC3 est vraiment très puissante, il ne faut surtout pas se prendre la tête pour ça, ce n'est pas l'ajout de règles dans GEA qui va changer quoi que ce soit à l'utilisation CPU de la box... il faudrait vraiment des milliers de règles pour commencer à ressentir quelque chose.
  • si on cherche à réduire la latence de déclenchement d'une action, évidemment la durée = -1 est à privilégier. Et c'est bien là que ce situe le choix. On veut réagir immédiatement à un événement (une fenêtre vient de s'ouvrir tandis que l'alarme est activée => alors déclenchement de la sirène), ou bien après un certains temps (une fenêtre est ouverte depuis 5 minutes tandis que le chauffage est allumé => alors extinction du chauffage).
    Donc ce n'est pas tant un problème de performance (terme qui n'a pas trop de sens ici), mais c'est la logique du scénario désiré qui prime sur la configuration, il ne faut pas se poser plus de question que ça.

Je pensais que c'était des notions que tu maitrisais déjà, ancien utilisateur de GEA sur HC2.

La logique générale n'a pas changée.

Lien vers le commentaire
Partager sur d’autres sites

@jojo j'ai déplacé tous tes messages ici, et non pas sur le topic du Support GEA, car je considère que ce sont des questions d'intérêt général liées à la rédaction de la documentation de GEA.

Je répondrai à celles qui sont pertinentes et/ou pour lesquelles j'ai une réponse à apporter.

Les questions du type "à quoi sert cette option" seront ignorées, en principe du bon vieux "si tu ne sais pas ce que c'est, alors c'est que tu n'en as pas besoin" ;)

 

  • Thanks 1
Lien vers le commentaire
Partager sur d’autres sites

Il y a 16 heures, Lazer a dit :

Les questions du type "à quoi sert cette option" seront ignorées, en principe du bon vieux "si tu ne sais pas ce que c'est, alors c'est que tu n'en as pas besoin" ;)

 

En effet, si je me pose la question "à quoi sert cette option", c'est que en effet je n'en ai pas besoin.

Mais ma méthode de revoir la doc est, si je comprends, quelqu'un de plus compétent que moi comprendra également. Sinon il faut apporter d'autres explications.

Mais peut-être que ici également j'en faits trop (crfr ma question sur les "performances", qui était plus une question sur les meilleures pratiques pour éviter de surcharger GEA/la box. (mais j'ai compris qu'"elle peut là-contre" (comme on dit dans ma région))

 

Pour rebenir sur les triggers et (), si on met une durée à -1, ne faut-il pas au min 1 condition sans (), sinon il y aurait un problème ?

 

 

Modifié par jojo
Lien vers le commentaire
Partager sur d’autres sites

Il faut bien comprendre que plusieurs options ont été créées par Steven à la demande des utilisateurs... donc parfois une option a été utilisée par une seule personne, et qui a peut-être quitté le forum entre temps.

Lors du portage sur HC3 je me suis efforcé de garder le maximum d'options par souci de rétrocompatibilité, mais ça ne veut pas dire que c'est utile. Les rares options qui ont disparu, sont celles spécifiques à la HC2 et qui n'ont plus lieu d'être sur HC3. Ou bien elle ont été remplacé par un équivalent adapté à la HC3. La 1ère page du topic résume ces changements.

 

Bref, si tu veux vraiment te pencher sur l'utilité et les cas d'usage de chaque option, il faudra que tu fouilles le forum, tu trouveras les réponses dans les profondeurs des quelques sujets dédiés à GEA. C'est le cas de la fonction StringToAlpha de MAM78, mais aussi de OnOff, etc... perso je ne les ai jamais utilisé.

 

il y a 33 minutes, jojo a dit :

Pour rebenir sur les triggers et (), si on met une durée à -1, ne faut-il pas au min 1 condition sans (), sinon il y aurait un problème ?

Oui évidemment, sinon il ne se passera jamais rien.

 

Lien vers le commentaire
Partager sur d’autres sites

je vais donc arrêter de me prendre la tête avec ce qui n'est pas limpide à mes yeux, donc arrêter d''être plus catholique que le pêpe".

 

Merci de ta confirmation poue les triggers,  j'ai enfin compris à 100%. Il n'y a plus qu'à traduire cela dans la doc.

Lien vers le commentaire
Partager sur d’autres sites

Bonjour à vous,

Juste pour vous remercier pour le super boulot que vous effectuez sur GEA 7

Cela me permet en tant que novice de chez novice de continuer cette magnifique aventure commencée sur ma HC2.

Encore Merci   :77:

 

  • Like 1
  • Thanks 1
Lien vers le commentaire
Partager sur d’autres sites

Le 05/06/2022 à 12:29, jojo a dit :

é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 ?

En fait les exemples sont complets, il n'y a rien de plus à ajouter.
Le paramètre est juste un nombre, qui donne le numéro du programme à exécuter.

 

On les retrouve dans l'API JSON du module :

image.png.07da25f34d895b224314d7fadcb33bc0.png

 

Ou bien plus simplement dans l'interface Web, dans l'ordre :

image.png.4f919b2f45d70a4af61463803052b586.png

 

Par exemple le programme n°5 c'est la police, ça fait son petit effet en cas d'intrusion :D

 

Lien vers le commentaire
Partager sur d’autres sites

Le 05/06/2022 à 12:48, jojo a dit :

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 ?

 

Les filtres possibles sont ceux de la box Fibaro, donc il faut être très rigoureux dans la syntaxe.

En théorie je suppose qu'on peut ajouter turnOn, tu devrais le tester avant de l'ajouter dans la doc.

Mais attention, pas TurnOn et TurnOff (à cause de la majuscule)

 

Voilà typiquement une option que je n'ai jamais utilisé...

Lien vers le commentaire
Partager sur d’autres sites

Le 05/06/2022 à 13:00, jojo a dit :

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

Vu que ces 2 options sont codées différemment en LUA, elles doivent avoir des différences... probablement assez subtiles.

Je m'abstiens donc de les fusionner.

Si tu es curieux tu peux regarder le code de GEA, dans le fichier main du QuickApp.

 

Et voilà encore 2 options que je n'ai jamais utilisé !

Lien vers le commentaire
Partager sur d’autres sites

Le 05/06/2022 à 13:11, jojo a dit :

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

Donc ne la change pas.

 

Perso je ne la maitrise tout simplement pas du tout... encore une de plus !

Lien vers le commentaire
Partager sur d’autres sites

Le 05/06/2022 à 13:18, jojo a dit :

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"

 

ça dépend de la télécommande utilisée.

 

Par exemple sur une Remotec ZRC90 j'utilise les keyAttribute suivants :

  • Pressed
  • Pressed2
  • HeldDown

Les noms parlent d'eux même.

 

Comme souvent pour connaitre les valeurs disponible, il faut aller voir le JSON du module via l'API :

		"centralSceneSupport": [
			{
				"keyAttributes": [
					"Pressed",
					"Released",
					"HeldDown",
					"Pressed2"
				],
				"keyId": 1
			},
			{
				"keyAttributes": [
					"Pressed",
					"Released",
					"HeldDown",
					"Pressed2"
				],
				"keyId": 2
			},

On voit bien les valeurs possibles pour chaque bouton keyId de la télécommande, autant qu'il y a de boutons.

 

Lien vers le commentaire
Partager sur d’autres sites

Le 05/06/2022 à 14:49, jojo a dit :

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, mais est-ce pertinent ?

Alourdir la doc de trucs évidents ce n'est pas forcément pertinent... sinon tu vas devoir le faire pour l'ensemble des options qui proposent de comparer la valeur avec les paramètres + - et !

Une fois qu'on a compris et décrit le principe avec l'option la plus utilisée "Value", "Value+", "Value-", "Value!", c'est bon, les gens ont saisit la logique.

 

 

Le 05/06/2022 à 14:49, jojo a dit :

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

Crée des QuickApp thermostats dans la HC3 et tu vas comprendre la différence entre les 2.

Heating et Cooling sont les opposés, l'un pour chauffer, l'autre pour climatiser.

Tout ça en coordination avec le panneau de climat (qui n'a plus grand chose à voir avec le panneau de chauffage que tu as connu sur HC2)

 

Le 05/06/2022 à 14:49, jojo a dit :

et si on ne pourrait pas rajouter simplement


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

Non parce que justement il faut spécifier si on parle de la consigne de chauffage ou de climatisation.


Cela correspond à des types de modules bien spécifiques, avec des propriétés différentes.

 

Le 05/06/2022 à 14:49, jojo a dit :

un thermostat n'a qu'un seul point de consigne (peut importe que ce soit un Heating ou Cooling thermostat) 

Et bien non justement, en vertu de ce que j'ai écris au dessus.

 

Il faut que tu prennes le temps de créer plein de QA bidons, de chaque type, regarder leurs propriétés (JSON), tu verras les différences et tout ce que ça implique.

Les différents types de thermostats sont particulièrement intéressants, ça n'a plus rien à voir avec ce qu'on a connu sur la HC2.... c'était tout pourri en comparaison. Disons plus "limité" (c'est moins politiquement incorrect)

 

 

  • Thanks 1
Lien vers le commentaire
Partager sur d’autres sites

Il y a 17 heures, Lazer a dit :

En fait les exemples sont complets, il n'y a rien de plus à ajouter.
Le paramètre est juste un nombre, qui donne le numéro du programme à exécuter.

 

On les retrouve dans l'API JSON du module :

 

 

Ou bien plus simplement dans l'interface Web, dans l'ordre :

 

 

Par exemple le programme n°5 c'est la police, ça fait son petit effet en cas d'intrusion :D

 

j'ai adapté ainsi la doc

-- "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>, <id_program>}
	{"Program", <id_module>, <id_program>}

	-- CONDITIONS :
	GEA.add( {"Program", 72}, 30, "", {ACTIONS} )             -- Retourne le programme en cours du RGB dont l'ID est 72
	GEA.add( {"Program!", 72, 3}, 30, "", {ACTIONS} )         -- Vérifie si le programme 3 est 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

 

Lien vers le commentaire
Partager sur d’autres sites

Il y a 17 heures, Lazer a dit :

 

Les filtres possibles sont veux de la box Fibaro, donc il faut être très rigoureux dans la syntaxe.

En théorie je suppose qu'on peut ajouter turnOn, tu devrais le tester avant de l'ajouter dans la doc.

Mais attention, pas TurnOn et TurnOff (à cause de la majuscule)

 

Voilà typiquement une option que je n'ai jamais utilisé...

Il faut être un peu égoïste : je n'ai jamais utilisé cette option, donc je ne change rien, et si question d'un utilisateur, on avisera

Lien vers le commentaire
Partager sur d’autres sites

Pour "Program" :

Je te suggère de supprimer les 2 lignes suivantes de la syntaxe :

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

Qui sont techniquement possibles, mais n'ont aucun intérêt en pratique... qui aurait le cas d'usage d'aller comparer si le programme n°X est supérieur/inférieur à la valeur Y.... ça n'a juste aucun sens.... ça n'est pas comme comparer une Value (de luminosité, de température, de puissance, etc)

 

Lien vers le commentaire
Partager sur d’autres sites

Il y a 17 heures, Lazer a dit :

ça dépend de la télécommande utilisée.

 

Par exemple sur une Remotec ZRC90 j'utilise les keyAttribute suivants :

  • Pressed
  • Pressed2
  • HeldDown

Les noms parlent d'eux même.

 

Comme souvent pour connaitre les valeurs disponible, il faut aller voir le JSON du module via l'API :

On voit bien les valeurs possibles pour chaque bouton keyId de la télécommande, autant qu'il y a de boutons.

 

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

	-- SYNTAXE :
	{"CentralSceneEvent", <id_module>, <keyID>, <keyAttribute>}
	-- les <keyAttribute> possibles dépendent du module.
	-- pour connaître les valeurs possibles (pour chaque <keyID>), voir le JSON du module

 

  • Upvote 1
Lien vers le commentaire
Partager sur d’autres sites

×
×
  • Créer...