Lazer

Oui tout à fait, la charge des batteries NiMh c'est hyper simple, d'où l'intérêt de bien choisir son chargeur. Les Lacrosse sont super pour ça, quand tu branches, il commence immédiatement une charge lente, avec détection de fin de charge, c'est parfait pour les accus. Il n'y a rien à faire. Après en 2 ou 3 clicks, tu accèdes aux modes intéressant, comme le changement de cycle (décharge puis charge, refresh, etc), ou un courant de charge plus important. Tu peux avoir un courant important, mais ça fait chauffer les accus, donc ça les use plus vite. Exactement comme pour les batteries Li-ion, la charge rapide est une ânerie inventée par les services marketing des fabricants de smartphones pour compenser l'absence de progrès technologique sur les batteries elles-mêmes. Déjà que le Li-ion vieillit relativement mal (comparé au Ni-Mh), mais si en plus tu le charges en rapide, la durée de vie est encore raccourcie. Et après on nous parle d'écologie et de développement durable... bref En tout cas tu pourras nous faire un retour d'expérience pour ces "piles" Li-ion rechargeable au format AA, car ça fait pas mal de temps que j'en vois, mais aucun retour d'expérience sur la durée. Évidemment que ça fonctionne bien quand c'est neuf, je m'interroge surtout sur l'utilisation réelle.

Mais justement @jjacques68 j'avais longuement détaillé mes expériences sur l'autre sujet. Aucun souci de performance. Pour l'instant j'ai 3 QA (GEA, Velux, Porte garage) sur ma box de production qui exploitent cette API, et ça tourne nickel depuis 2 mois. Je pense même en ajouter un 4ème prochainement, quand j'aurai le temps de m'y mettre (réécrire le QA Evénements pour utiliser /refreshStates à la place de /events/history)

@Massalia@jjacques68 merci en effet j'avais oublié cet outil

C'est quoi HC3 download ? Il te dit que tu as 2 modules injoignables, c'est ça ? Ils sont surement trop loin... après, à regarder la liste des tes modules, je ne suis guère surpris, je ne vois quasiment que des modules sur piles. Tu aurais dû commencer par inclure les modules sur secteur, afin de créer un bon maillage, avant d'ajouter les modules sur batterie. Bon c'est pas trop tard, tu peux ajouter des modules sur secteur, ça va créer le maillage, auquel pourront se raccrocher les modules éloignés qui n'ont pas de communication directe avec la HC3.

Tiens merci, Varta Industrial je n'ai jamais testé, je garde en tête. Intéressant tes durées avec les accus rechargeables sur les FGMS et ST814, donc à priori tu as des durées de vie environ 2 fois plus courtes qu'avec des piles (je tiens largement 3 ans, voire plus, avec les FGMS, et plus de 2 an avec ST814) Après les accus NiMh, même après 5 ans, ça tiens encore, c'est normal, c'est une techno qui vieilli mieux que le Li-ion, j'ai constaté ça même avec mes très vieux accus, s'ils sont correctement entretenus (= pas laissés complètement déchargés... je me suis fait avoir pour 2 jeux que j'ai oublié, ils sont morts) Le Li-ion a ceci de pénible, qu'on l'utilise ou non, il vieilli tout seul.

En LR6, donc taille standard, je te recommande à 100% Eneloop, elles sont à milles lieux de toutes les autres marques. C'est THE référence en accus rechargeables. Les anciennes étaient déjà pas mal, avec un faible taux d'autocharge. Les derniers modèles ont carrément un taux ultra faible... ce qui les rend exploitables dans les appareils à très faible consommation d'énergie comme nos modules domotiques. Ils annoncent 70% de charge restante au bout de 10 ans. Même une Alcaline ne fait pas ça. Reste les autres problèmes évoqués : tension 1.2V et courbe de décharge non linéaire. Comme je disais, les accus rechargeables c'est toujours une histoire de compromis, aucun modèle n'est parfait. Autre chose, au moins aussi important que le choix de l'accu, c'est le choix du chargeur. Les chargeurs basiques tuent les accus, donc c'est pas la peine. Dans le domaine, les chargeurs Lacrosse font figure de référence, même s'il existe d'autres bons modèles, de marques plus ou moins connus. Ce qui est important, c'est la détection de fin de charge, et le choix du courant de charge. Comme pour toutes les batteries du monde (téléphone, voiture, etc), plus on charge lentement, mieux c'est. La charge rapide est à bannir et à réserver aux situation d'urgence. Certains chargeurs ont un contrôle de température intégré, ainsi qu'une ventilation forcée, c'est encore mieux. Option sympa aussi, c'est la programmation du cycle complet de décharge avant la recharge, pour luter conter l'effet mémoire pour lequel les accus NiMh sont encore partiellement soumis, contrairement aux Li-Ion. Et le cycle de refresh (charge/décharge plusieurs fois de suite) pour régénérer un accu qui a dormi un peu trop longtemps dans un tiroir. Je n'ai jamais essayé les accus Li-Ion comme ceux de ton exemple. Le Li-Ion est une techno bien plus complexe, qui explose, les amateurs de modélisme le savent bien. Là je vois sur tes modèles que le chargeur est intégré dans l'accu, il suffit de brancher le cordon USB pour l'alimentation. Sans expérience, je ne sais pas comment ils vieillissent.... j'imagine que comme la plupart des batteries Li-Ion grand public, au bout de 3 ans il te reste 50% de la capacité... pas top.

Vieux sujet oui... C'est toujours les mêmes problèmes avec les batteries (accus) rechargeables : - la tension nominale est souvent de 1.2V et non 1.5V, donc même chargé à bloc, le module va croire que la pile est déjà partiellement déchargée - la courbe de tension ne décroit pas linéairement dans le temps, mais elle reste relativement stable, puis s'effondre d'un coup. Si bien que le module n'étant pas calibré pour ça, ne va pas voir venir la chute de tension, n'aura pas le temps de prévenir que la batterie est faible, et va cesser de communiquer - la plupart des batteries ont un taux d'auto-décharge plus élevé que les piles alcalines, donc sur un appareil pour lequel la durée de vie de la pile est longue (1 an ou plus), alors la batterie se videra plus vite toute seule que par le consommation du module lui-même.... pas très optimal tout ça. La technologie de batterie parfaite n'existe pas. Les fabricants arrivent à répondre à l'un des points évoqués ci-dessus, ou l'autre, mais jamais tous en même temps. Perso je conserve des piles dans mes modules domotique (et alarme, encore plus critique). En les achetant par lots (sur Amazon), ça coute 10x moins cher qu'au supermarché. En prenant des piles de qualité (en Alcaline j'aime bien les Duracell Ultrapower), ça dure assez longtemps. Ce dont je suis certain, c'est que les piles les moins couteuses reviennent le plus cher. Comme souvent, "le pas cher coute cher". Sans même compter le désagrément du remplacement des piles sans arrêt... Et les FGK, de 1ère génération, il faut s'en débarrasser. Le FGDW est juste magique en comparaison. Tous les autres modules Fibaro tiennent très bien, y compris les FGMS (série 300 et 500 inclus), facilement 3 ans avec la bonne config. Tu dois avoir un souci de config. Les Aeotec sont bien aussi. Si tu as des problèmes, il faut te débarrasser des vieux modules, typiquement les Z-Wave chipset v300, qui n'étaient pas optimisés du tout... technologie d'il y a 10 ans quand même.

Et pourquoi ne pas regarder les capteurs "à basculement mécanique" (désolé je ne connais pas le terme). J'ai ça sur ma pompe immergée de puits. Quand le niveau baisse, le capteur (qui est 100% étanche et flotte) descend, ça active un contact mécanique, qui coupe le circuit. Bête et méchant, mais efficace.

De mon coté je n'ai jamais eu de déclenchement. Et tant mieux Tu n'aurais pas des problèmes de plomberie ? Mais là tu compares des choses qui n'ont rien à voir, une utilisation au sol, c'est le cas normal prévu par le fabricant, le module a été conçu en ce sens. Une utilisation en extérieur, dans un skimmer, ça n'a rien à voir, je veux bien croire que ça ne donne pas du tout satisfaction.

Peut être le nouveau Sensative Strips Drip 700 https://www.domotique-store.fr/domotique/usages/domotique-alarme-securite/inondation-fuite-eau-coupure-automatique/1538-sensative-strips-drip-700-detecteur-d-inondation-extra-plat-z-wave-compatible-exterieur-avec-puce-z-wave-v2-serie-700.html Il est indiqué compatible extérieur et certifié IP 44 Mais ça reste de la domotique, donc probablement pas plus fiable que le Fibaro Flood Sensor, attention si tu veux faire un scénario de pilotage automatique du remplissage. Mais pour une notification et un contrôle manuel, ça doit faire le job.

Oui je suis d'accord, si j'ai bien compris ta question, alors il faut utiliser "Or" pour mettre plusieurs profils en conditions.

Mais justement, tu n'as pas saisis l'intérêt du QuickApp Évidemment que je n'utilise pas non plus un Roller Shutter pour piloter ma porte de garage, puisqu'aucune porte de garage ne peut être pilotée avec un FGR. C'est toujours du contact sec. J'utilise un contact d'un IPX800 en série avec un FGS (double sécurité, je ne veux pas que la porte s'ouvre toute seule... bon malgré tout ce n'est toujours pas câblé comme dis précédemment). Mais avec un FGS-224 comme le tient ça serait pareil. C'est le QA qui est de type Roller Shutter, pour apparaitre proprement dans l'interface Fibaro (web et mobile). Et laisser la box gérer les icônes toutes seules, selon son pourcentage d'ouverture. Dans la pratique, comme j'ai 2 capteurs (bas et haut), je peux déterminer 3 positions (complètement fermé, complètement ouvert, et intermédiaire). Comme toi. Donc dans la propriété value du QA RollerShutter, ça se traduit par 0, 50 et 99, comme tu peux le voir dans le code LUA. Bref, vu le code ci-dessus, ça permet de remonter l'état de la porte de garage dans la box. Et il reste à écrire les lignes dans la fonction QuickApp:setValue(value) pour agir sur la porte. EDIT:

Dans l'immédiat, tu peux déjà faire le minimum syndical, c'est à dire un pilotage en tout ou rien, ON/OFF, avec un module relai type FGS-214 Après, je pense qu'il n'est pas très recommandé de couper sa ventilation, et d'ailleurs ce n'est pas la température qu'il faut surveiller, mais d'autres paramètres : l'humidité principalement, et éventuellement d'autres tels que le CO2 ou les COV.... mais ces capteurs sont plus rares, et chers. On en trouve chez MCO Home par exemple, avec écran à fixer au mur.

oui mais le clearTimeout() c'est pour interrompre un timeout en attente dans un process (instance) de scène/QA en cours d'exécution. Si le process/instance est tué parce que la scène/QA a été redémarré, alors peu importe le cleartimeout, puisque de toute façon le process précédent n'existe plus, et avec lui le timeout en attente.

Qu'est-ce que tu veux faire avec un transfo 12-24V ? C'est un moteur 230V, si tu l'alimentes en 12V ou 24V, il ne se passera rien du tout, le moteur ne bougera pas du tout. Pour la sonde de température, il y a le nouveau minuscule module Aeotec Aërq sur batterie qui est pas mal du tout, il y a un topic dédié à son sujet sur le forum

Oui centraliser les ID des modules quelques part est une bonne approche. Perso c'est un peu différent, car 99% de mes scénarios sont ensemble : dans GEA. Du coup c'est une simple table LUA au début du script qu'il me suffit de maintenir à jour, juste avant le long listing des différentes règles. Les rares exceptions en fin de compte, c'est une scène Alarme, qui est autonome, et fait clignoter les éclairages et envoie des snapshots des caméras. Là les ID sont aussi codée en dur dans une tableau LUA au début de la scène. Ainsi elle reste le plus légère possible et fonctionne en toute circonstance sans dépendre d'une variable globale externe. Et puis de toute façon, les ID de mes éclairages ne changent jamais. Comme tu dis, le jour où on passe sur le moteur Z-Wave v3 et que les ID changent, je n'aurai que 2 endroits à modifier, très simple. Exactement ccomme ce qui s'est passé quand j'ai basculé de HC2 à HC3, la bascule a été très simple (c'était la réécriture préalable des QA qui a été longue)

Le vendeur est... un vendeur justement ! On ne lui demande pas de connaitre le fonctionnement de son produit, juste d'en vendre. Ce qu'il a réussi visiblement, donc il est bon. Bon dans son métier de vendeur. Dans mon métier (technique) je travaille avec des commerciaux tous les jours, chacun son rôle, et ça fonctionne bien. Et non, rien à voir avec l'électricité ou la domotique. Si tu viens sur un forum, c'est pour avoir des avis techniques éclairés que ton vendeur n'est pas capable de t'apporter. Certes sur les forums, les gens peuvent aussi se tromper, on est là pour discuter, échanger des avis, expérimenter, et apporter des retours d'expérience. Bon là il n'y a aucun doute, la variation de fréquence ce n'est pas possible. Là ton expérience va consister à tester avec un dimmer, normalement prévu pour un éclairage, et de regarder comment se comporte le moteur. Comme je te l'ai indiqué, ça devrait fonctionner, mais pas sûr à 100%. Normalement, le moteur ne démarrera pas en dessous d'une certaine tension moyenne (correspondant à un certain pourcentage de variation du dimmer) Il risque aussi de grésiller, ce qui va l'user prématurément. Là où tu vas avoir un souci, c'est si tu utilises le FGD-212, car il force une calibration au démarrage pour détecter le type d'éclairage, et adapter en conséquence (leading ou trailling edge, 2 façons de hacher la sinusoïde, je te laisse chercher sur Google si tu veux approfondir). Mais il risque de ne pas aimer quand il va "voir" le moteur, ou plutôt ne pas comprendre à quel type de charge il a affaire. Donc il faudra que tu modifies le paramètres qui va bien (regarde le numéro dans la doc) pour désactiver la calibration automatique. Ou alors utiliser le dimmer v1, le FGD-211, si tu arrives encore à en trouver d'occasion, qui sera surement plus adapté : pas de calibration automatique, et supporte une plus grande puissance (500W versus 250W pour le FGD-212)

tu as vu ça où ? Relis bien ce que j'ai écris au dessus. Si ce n'est pas clair, le web regorge d'informations, avec des schémas qui seront plus parlants. De plus, dans la doc de ton moteur, c'est quand même clairement indiqué : moteur monophasé 50 Hz, vitesse variable par dévoltage (NDLR : ouh là là, quel vilain anglisme) Je ne sais pas pourquoi tu t'obstines à vouloir faire varier la fréquence....

Précision : le setTimeout ne fonctionne pas dans un Thread autonome, car tous les QA et Scènes sont mono-threadés sur la HC3 (comme sur la HC2) Le setTimeout fait donc partie du process de la scène en cours d'exécution. Quand une nouvelle instance de scéne démarre, c'est à dire un nouveau processus (au sens Linux) est démarré, donc le précédent est tué, afin de ne pas laisser plusieurs instances (= processus) de scènes s'exécuter en parallèle. Et ça c'est une différence fondamentale avec la HC2, sur laquelle on pouvait avoir jusqu'à 10 instances (processus) de scènes s'exécuter en parallèle.

Euh.... il sort d'où ton extracteur d'air monophasé ? C'est une technologie extra-terrestre ? Un moteur électrique dont on fait varier la fréquence, perso, je ne connais pas... même pas certain que ça existe. Peut être à la NASA ? Bref, ton moteur il fonctionne en 50 Hz, soit la fréquence du réseau électrique en Europe, point final. Je pense que tu confonds la fréquence électrique et la vitesse de rotation, car c'est bien cette vitesse de rotation que tu veux faire varier pour ton application Pour faire varier la vitesse de rotation d'un moteur, on utilise généralement un hacheur. Un hacheur de la sinusoïde électrique, qui reste toujours à la fréquence de 50 Hz. Et autre confusion de ta part, les variateurs Z-Wave ne sont ni des variateurs d'intensité, ni de tension. Ce sont justement des hacheurs. Même si au final, puisque la sinusoïde est tronquée, alors la tension moyenne est réduite, d'où l'impression d'une variation de tension. Et puisque la résistance de la charge est constante (dans le cas d'une ampoule lumineuse), alors le courant aussi varie à la baisse, puisque U=RI. Pour un moteur, c'est à peu près pareil, plusieurs utilisateurs ont rapporté qu'ils avaient réussi à faire varier la vitesse de leur moteur de VMC avec un simple gradateur (=dimmer en anglais) Z-Wave. Donc tu peux tester un FGD. Cela dit, je n'ai jamais testé personnellement (je n'ai pas de VMC), mais j'imagine que ça ne va pas forcément bien fonctionner avec tous les moteurs. Certains n'aiment pas trop, cela peut les faire grésiller par exemple. A tester donc.

La lecture n'use pas la Flash En ce qui concerne les opérations de lecture/écriture, que ça soit dans une variable globale, une variable de QA ou de scène, une propriété d'un module, etc... au final ça ne change pas grand chose, ça arrive toujours dans la même DB, donc l'usure est sensiblement identique. Reste les questions d'organisation, où stocker la donnée, chacun fait comme il veut. Cela dit, un script (QA ou scène, peu importe), qui va lire des données dans une variable (globale/QA/Scène) à chaque passage de boucle, ira chercher dans la DB, donc c'est plus lent et consommateur de CPU. Probablement sans impact dans la majorité des cas. Mais sur un système chargé, avec une boucle un peu trop agressive (par exemple chaque seconde), l'impact sur les performances deviendra sensible. A l'inverse, un tableau défini au début du code LUA, comme dans l'exemple donné plus haut sur cette page, sera infiniment plus rapide, car ce tableau, une fois chargé en RAM lors du démarrage de la scène/QA, va y rester, donc accessible par le processeur en quelques nanosecondes. Donc pour résumer, si vous souhaitez utiliser souvent une donnée, elle doit rester dans la mémoire du script LUA. Dans ce cas, le script qui exploite une variable "externe", pourra aller la lire une première fois dans la DB au moment au démarrage du script, puis la conserver dans une variable dans le code LUA. Ainsi la donnée reste en RAM, et on n'a plus de problème de performance. Si vous regardez tous mes QuickApps que j'ai partagé sur le forum, c'est ce qui se passe : les variables du QA sont chargées en RAM au démarrage (dans onInit()), puis elles y restent. Bref, la lecture n'est pas un problème d'usure de la mémoire Flash, mais de performance.

Je n'utilise que très peu les scènes, mais la réponse à ta question semble être ce paramètre : Autoriser le redémarrage de la scène en cours d'exécution: Oui/Non Donc si tu choisis "Oui", alors la scène sera redémarrée de force, donc l'instance précédente stoppée (et donc forcément l'éventuel setTimeout qui était dedans)

Il faut utiliser /api/refreshStates Il y a une discussion sur ce sujet sur le forum, sur comment le mettre en œuvre, et son impact (très modéré) sur les performances. Il se trouve que j'ai un QuickApp qui fait exactement pareil, de type rollerShutter, et qui surveille 2 contacts d'ouverture haut et bas, comme toi. Je ne l'ai pas partagé parce que je pensais être le seul dans ce cas de figure. Voici le code, il faut mettre les ID des 2 détecteurs dans l'onglet Variables du QA. Ce QA fait une double vérification de l'état de la porte (c'est critique... sécurité oblige) : boucle avec setTimeout, et détection instantané avec refreshStates : ---------------------------------------------------------------------------------------------------- -- QuickApp : Porte garage -- Author : Lazer -- Version : 1.00 -- Date : May 2021 ---------------------------------------------------------------------------------------------------- -- -- System variables -- __TAG = "QA_PORTEGARAGE_" .. plugin.mainDeviceId QuickApp.version = 1.00 QuickApp._VERSION = "1.00" local id_bas, id_haut local garbageExecTime local intervalLoop -- -- Constructor -- function QuickApp:onInit() -- Initialize self:trace("") self:trace("QuickApp Porte de garage - Initialisation") self:trace("") -- Check if QuickApp device is enabled if not api.get("/devices/"..tostring(self.id)).enabled then self:updateProperty("log", "Désactivé") self:warning("Le module", self.name, "est désactivé => QuickApp arrêté") return end -- Get QuickApp variables id_bas = tonumber(self:getVariable("ID_Bas")) id_haut = tonumber(self:getVariable("ID_Haut")) if not id_bas or not id_haut then self:error("ID haut ou bas invalide") self:updateProperty("log", "Erreur") return end local refreshInterval = tonumber(self:getVariable("Refresh")) or 60 -- Update main device properties self:updateProperty("manufacturer", "Lazer") self:updateProperty("model", "Porte garage") self:updateProperty("log", "") -- Display debug information self:debug("<font color=teal>Capteur porte basse : #<b>" .. tostring(id_bas), fibaro.getName(id_bas), "</b> =>", fibaro.getType(id_bas), "</font>") self:debug("<font color=teal>Capteur porte haute : #<b>" .. tostring(id_haut), fibaro.getName(id_haut), "</b> =>", fibaro.getType(id_haut), "</font>") self:debug("<font color=teal>Intervalle de rafraîchissement : <b>" .. tostring(refreshInterval) .. "</b> secondes", "</font>") -- Initialize internal variables local lastRefresh = 0 -- Performance optimization local http = net.HTTPClient() local http_request = http.request local json_decode = json.decode local pcall = pcall local type = type local setTimeout = setTimeout -- -- Boucle d'attente d'événements instantanés -- local function instantLoop() local status, err = pcall(function() local stat, res = http_request(http, "http://127.0.0.1:11111/api/refreshStates?last=" .. lastRefresh, { success = function(res) local status, states = pcall(function() return json_decode(res.data) end) if status then if type(states) == "table" then lastRefresh = states.last or 0 local events = states.events local nbEvents = #(events or {}) for i = 1, nbEvents do local event = events[i] if event.type == "DevicePropertyUpdatedEvent" then local data = event.data if data and data.property == "value" then local id = data.id if id == id_bas then if data.newValue then self:trace("Porte basse", data.newValue and "ouverte" or "fermée", "=> Porte ouverte à 50 %") self:updateProperty("value", 50) else self:trace("Porte basse", data.newValue and "ouverte" or "fermée", "=> Porte ouverte à 0 %") self:updateProperty("value", 0) end elseif id == id_haut then if data.newValue then self:trace("Porte haute", data.newValue and "ouverte" or "fermée", "=> Porte ouverte à 99 %") self:updateProperty("value", 99) else self:trace("Porte haute", data.newValue and "ouverte" or "fermée", "=> Porte ouverte à 50 %") self:updateProperty("value", 50) end end end end end else self:error("Invalid states :", type(states)) end else self:error(states or "json.decode() failed") end setTimeout(instantLoop, 250) end, error = function(res) self:error("Error : API refreshStates :", res) setTimeout(instantLoop, 5000) end, }) end) if not status then self:error(err) setTimeout(instantLoop, 5000) end end -- Start both loops fibaro.setTimeout(1000, function() intervalLoop(self, refreshInterval) end) fibaro.setTimeout(1500, instantLoop) end -- -- Main loop -- intervalLoop = function(self, refreshInterval) -- Display LUA memory consumption every 5 minutes if not garbageExecTime then garbageExecTime = os.time() else local elapsedTime = os.difftime(os.time(), garbageExecTime or 0) if elapsedTime >= 300 then self:debug(string.format("<font color=gray>Total memory in use by Lua : %.2f KB</font>", collectgarbage("count"))) garbageExecTime = os.time() end end -- Check local newValue if fibaro.getValue(id_haut, "value") then newValue = 99 elseif not fibaro.getValue(id_bas, "value") then newValue = 0 else newValue = 50 end if newValue ~= self.properties.value then self:warning("Porte ouverte à", newValue, "%") self:updateProperty("value", newValue) end -- Wait if refreshInterval and refreshInterval > 0 then fibaro.setTimeout(math.floor(refreshInterval*1000), function() intervalLoop(self, refreshInterval) end) end end -- -- Actions -- function QuickApp:open() self:setValue(99) end function QuickApp:close() self:setValue(0) end function QuickApp:stop() end -- Value is type of integer (0-99) function QuickApp:setValue(value) -- TODO -- Gestion du double clic -- Appel de l'API GCE IPX800 et du FGS --self:trace("Ouverture porte à", value, "%") --self:updateProperty("value", value) end On constate tout en cas que j'ai prévu les actions open, close, et setValue, auxquelles doit pouvoir réagir un QA de type RollerShutter. Sauf que je n'ai pas encore câblé cela sur la porte de garage, donc pour l'instant c'est inactif.

Je ne pense pas que tes syntaxes de fibaro.call avec plusieurs id dans une table soient correctes. En tout cas je n'ai jamais vu ça. Tu peux soit les décomposer en autant de ligne qu'il y a d'ID... mais c'est un peu fastidieux. Ou bien faire une petite boucle : local IDs = {71, 86, 66, 76} for _, id in ipairs(IDs) do fibaro.call(id, 'setValue', 60) end Sinon il y a peut être moyen avec fibaro.callGroupAction() mais la syntaxe est un peu particulière, car elle permet de filtrer sur les modules existants : https://manuals.fibaro.com/home-center-3-lua-scenes/

Je ne sais pas... Je ne saurais pas te répondre, je n'utilise aucun scénario en mode bloc, j'utilise exclusivement GEA pour tous mes scénarios. Si tu ne connais pas GEA, c'est un script dispo sur le forum pour gérer des scénarios, du plus simple au plus complexe. Pas évident à prendre en main, mais ça permet de tout faire sans connaitre LUA, donc assez pratique au final. Mais si quelqu'un utilise le mode bloc, il saura peut être te répondre. Alors là, il faudra partager ton code, et préciser si tu le fais tourner dans un QuickApp ou une Scène, le comportement est assez différent.