Lazer

C'est ce qu'il faut faire, c'est facile à faire avec une boucle for _, parameter in ipairs(...parameters) do Puis tu testes chaque élément : if parameter.id == 13 then ... end J'ai pas le courage d'écrire le code, et je préfère pas le donner car ça ne sera pas formateur, mais avec les indices que je viens de donner tu vas trouver facilement.

Et bien, quelle est la difficulté ? Tu n'as pas partagé ta règle GEA, donc c'est difficile de t'aider (comme je disais plus haut, je ne suis pas devin) Mais il te suffit d'appeler la fonction ON24_S1_C1 si j'en crois ta capture d'écran.

Ici c'est la section pour se présenter. Par ailleurs il faudra te créer un compte et ne pas rester en invité. Ensuite tu pourras aller dans la section Portiers ou participer directement au fil du Dahua

Hum... mais du coup, pourquoi tu n'encodes pas ta chaine de caractère avant de la mettre dans ta règle GEA ? Tu peux utiliser un service en ligne tel que https://www.urlencoder.org/ Tu y colles ta phrase complète avec les espaces, tu récupère la version encodée, que tu peux coller dans ta règle GEA, à la suite de msg=...

Je pense que c'est possible mais je n'ai jamais essayé. Dans le JSON du module, on voit qu'il y a des bornes min et max : Tu peux tenter de mettre cette ligne dans le onInit() de ton QuickApp pour tester si ça fonctionne : self:updateView("slider1", "min", "0") self:updateView("slider1", "max", "200") Évidemment tu remplaces le nom du "slider1" par le nom de ton slider, et les valeurs des bornes min max que tu veux.

L'affichage se fait au format JSON, donc effectivement peu lisible si tu n'est pas habitué. Affiché plus proprement (= formaté pour un humain), ton exemple donne : "event": { "deviceId": 502, "elementName": "slider", "values": [ 64 ], "eventType": "onChanged" } Le champ "values" de la table est un peu particulier, car c'est lui-même une table (indiquée par la présence de crochets), qui contient une seule valeur non indexée : 64 Comme cette valeur n'a pas d'index nommé, on y accède par un index numérique, 1, que l'on place entre crochets. Cela donne donc : event.values[1] => on prend le 1er élément de la table values dans la table event

Alors là je ne sais pas...

Au sens Fibaro ça n'a aucune importance, c'est juste ma tambouille interne. J'ai trouvé logique d'avoir : - une variable version sous forme de "number", car il est facile de comparer cette valeur lors du démarrage du QA et ainsi vérifier la bonne version de la librairie (oui parce qu'en fait j'utilise ce principe dans toutes mes librairies dépendantes) - une variable _VERSION sous forme de "string", car il est plus facile à afficher à l'écran lors d'un self:debug(), sans avoir besoin de mettre en forme avec string.format()... d'ailleurs, doit-on afficher avec le formatage 2.10 ou 2.1 ? Avec une string, pas de question à se poser. Surtout si demain je décide de créer la version 2.125 par exemple (sur 3 digits donc) Pour en revenir au sens Fibaro, même si ça n'a aucune importance, je n'ai quand même par sorti ça de nul part, je me suis inspiré de ce que Fibaro a fait. Voir sur le topic suivant : _VERSION = "Lua 5.3" json._VERSION = "1.3.4" => ce sont des strings.

@jang a parfaitement répondu (qui en aurait douté ) Quant à ta phrase, je l'aurais plutôt écrite comme ceci : "La position de la déclaration de ta variable locale a de l'importance finalement." C'est en quelques sorte de la sémantique du langage.... notre langage d'humain

Tu peux faire la somme de la puissance de tes 6 ampoules pour en être certain, car le Dimmer v2 est effectivement limité à 250W. Si tu veux les conserver, tu peux limiter la puissance d'éclairage avec le paramètre 2 (par exemple 50%.... ça va dépendre de la puissance cumulée de tes ampoules) Et tu peux également augmenter le paramètre 39 à la valeur maxi (350W) Le Cos phi des ampoules LED n'est jamais indiqué, sauf peut être chez les marques pro. Mais en pratique tu t'en moques un peu. Le Bypass est indispensable en cas d'utilisation sans neutre... si tu as le neutre, ça dépend ! Donc il faut tester sans, puis avec, car c'est tellement dépendant des ampoules LED, c'est vraiment la loterie.

Ah on avance... MAIS : - tu n'as pas mis GEA.debug = true comme je te l'ai demandé - je vois pas mal de lignes qui n'ont apparemment rien à voir avec ton problème => donc STP fait le ménage, et ne laisse que la ligne qui te pose problème avec l'action "httpGet" => ça simplifiera l'analyse des logs sinon on ne s'en sortira pas.

C'est impressionnant quand même, tu n'as donc que ça a faire de tourner autour du problème plutôt que d'aller droit au but et de partager ton log ? Et aucune considération pour le temps que tu me faire perdre par la même occasion ? Des exemples tu en as dans la doc de syntaxe... De toute façon ta syntaxe me semble OK, sauf peut être l'appel de la fonction urlencode() car je ne suis pas certain qu'elle existe en LUA Si je te demande de partager tes logs depuis tout à l'heure, c'est par pour rien quand même, c'est incroyable ça. (et oui, le ton est énervé, il y a de quoi...)

Impossible ça voudrait dire que ta condition n'est pas remplie, hors c'est impossible puisque tu as mis true. Donc ta condition est forcément valide, la règle est forcément exécutée, donc tu as forcément un affichage dans le log.

Certes .... mais quel message d'erreur tu as sur GEA ? Sans message d'erreur, difficile de deviner.... en tout cas perso je ne suis pas devin, malheureusement Copie/colle le log ici, c'est simple. Et n'oublie pas de mettre debug = true comme toujours.

" cela ne marche pas " ne signifie rien en informatique. D'ailleurs ça ne signifie rien tout court. C'est comme si tu allais chez ton docteur et que tu disais "je suis malade". Il sera bien avancé pour te soigner... Bref, quel est ton message d'erreur, le comportement observé, etc.... toute information utile pour aider à la résolution de ton problème.

event, c'est un paramètre de la fonction. Quand la fonction est appelée, cette variable event est passée en paramètre de la fonction, et elle contient des informations utiles. Il s'agit d'une table, c'est pour cela qu'il faut utiliser [1] pour accéder à l'un de ses indices. Si tu veux voir le contenu complet de cette variable, tu peux par exemple faire ceci dans ta fonction QuickApp:testSlider(event) : self:debug("event :", json.encode(event)) Ainsi tu verras tous les champs de cette table.

Pour gérer des lumières non, mais mon QuickApp pour Yahama MusicCast déjà partagé sur le forum exploite un Slider (pour le volume). Mais la partie purement gestion du slider est ultra basique, c'est basé sur la doc officielle, tu as juste une fonction qui est appelée lorsque l'utilisateur clique sur le slider, exactement comme pour un bouton en fait. La seule particularité, c'est qu'il faut récupérer la nouvelle valeur du slider, puisque c'est cette valeur que tu vas affecter à ta lumière avec fibaro.call()

Je pense que de leur côté, les salariés Fibaro ne s'en servent pas du tout, du coup si on s'arrête aux captures d'écrans de présentation, elle a l'air top. Juste l'air.

Pas de tuto pour les slider des QuickApp sur HC3 à ma connaissance sur le forum... Il y a le manuel officiel, même si un peu léger, il explique ce qu'il y a à savoir sur les Sliders : https://manuals.fibaro.com/home-center-3-quick-apps/ Notamment comment créer une fonction d'un QuickApp qui réagit aux changements du slider. Tu récupères la valeur, puis tu l'affectes à ton module Walli (via fibaro.call() comme tu l'as déjà identifié) Est-ce que tu as besoin d'autre chose ?

Autant l'équipe de dev de la HC3 est réactive et à l'écoute des utilisateurs sur le forum et prend en compte des problèmes, autant l'équipe de dev de l'application mobile est aux abonnés absente. C'est bien dommage... y'a qu'à voir le nombre de problèmes remontés sur le forum officiel sans réponse...

La base : GEA.add(condition, durée, notification, actions)

@fastvd please use French, or at least English, because Russian is way to complicated for us...

Non j'ai pas encore craqué.... j'ai déjà le modèle précédent... que je n'ai toujours pas installé pourtant ! A vrai dire que je ne vois aucun bénéfice au nouveau modèle, aucune nouvelle fonctionnalité à priori. Le changement de la puce série 700 c'est juste dans l'ère du temps, un simple rafraichissement du produit au gout du jour, ça ne justifie aucunement le changement quand on a déjà l'ancien modèle. J'ai surtout créé le topic par anticipation, car ce genre de module (et cette marque) est populaire, donc ça évitera les questions/réponses qui trainent n'importe où sur le forum... hop directement au bon endroit, ici

Aeotec ZWA024 MultiSensor 7 Z-Wave 700 Détecteur multifonctions 6 en 1 Remplace le ZW100 MultiSensor 6 Z-Wave 500 FONCTIONS : Détecteur 6 en 1: mouvements, température, humidité, lumière, UV, vibration Petit, discret et esthétique IP20 - utilisation intérieure/extérieure Mise à jour du firmware possible Portée de l'antenne optimisée Alimentation sur piles ou adaptateur USB 5VDC Sécurité de la communication radio via le chiffrement AES-128 Intègre la puce Z-Wave série 700 Supporte les technologies S2 et Smart Start Optimisation de l'antenne, portée 150 mètres Fait office de répéteur si alimenté par USB Bouton pour inclure/exclure le détecteur Détection pile faible Facilité d'utilisation et d'installation CARACTERISTIQUES TECHNIQUES : Type de module : Émetteur Z-Wave Alimentation : 2 piles CR123A 3V 1500mAh (fournies) ou adaptateur USB 5VDC Durée de vie des piles : 3 ans Fréquence: 868.42 MHz Distance de transmission : jusqu'à 150m en extérieur Capteur de température : Gamme de mesure : -10°C à 50°C Précision : ±1°C Capteur d'humidité : Gamme de mesure : 20% à 90% Précision : ±5% Capteur de luminosité : 0 – 30000 LUX Capteur UV : Index UV de 0 à 11 Sensibilité de détection de mouvement : jusqu'à 12m Dimensions : 45 x 45 x 35 mm Poids : 65g Affichage : LED Protection IP : IP20 Disponibilité : Novembre 2021

Ah oui fibaro:getModificationTime() c'était donc sur la HC2 uniquement.... possible en effet.