Lazer

Tu as vu qu'avec les paramètres 40 et 41 tu peux choisir les événements de scènes déclenchés (simple clic, etc) ? Sinon, une solution de contournement, une fois que tu as asservi les sorties aux entrées, plutôt que de déclencher sur l'événement de changement d'état de l'entrée, pourquoi ne pas déclencher sur le changement d'état de la sortie ?

Bienvenue sur le forum Et j'adore ton projet

Welcome to the forum Now you have full access to the forum so you can post your questions in the right subsection.

Je pense que tu avais posté au bon endroit, car ton problème semble lié au volet non supporté par le module (5 fils, ça sort d'où ???). Il faudrait déjà savoir à quoi servent chacun de ces 5 fils. A voir si tu trouves la doc du moteur. Bon après, c'est probable aussi que ça vienne de Jeedom, les premières versions de ce module, (sans firmware à jour) ne fonctionnaient pas avec Jeedom. Donc 2nd conseil : vérifier le firmware et fait la mise à jour (avec une box Fibaro) Lien vers le sujet pour référence :

Presque, mais maintenant ta syntaxe n'est plus correcte, car il faut regrouper toutes tes conditions dans un même tableau (délimité par des accolades). Quelque chose dans ce genre là je pense : GEA.add({estTravail, {"Time", "09:29", "09:30"}}, 1*30, "", {{"Close",id["Volet_Bureau_R1"],100}})

Cela dit ta condition Time est toujours mal placée, elle ne devrait pas être avec les actions (tu utilises la vieille syntaxe de GEA)

Bienvenue sur le forum

peut être mettre tes conditions.... dans les conditions justement ! (et non pas dans les actions) A la place de true.

ouaip, rien de tel pour perturber le maillage et se créer des problèmes de transmission Pas du tout conseillé.....

que tu as remplacé par ta domotique, cela t'économise un salaire

Yes i know about "DeviceRemovedEvent" in /api/refreshStates, but I'm afraid that monitoring this API from multiple QuickApps may slow down the system. I also know your webhook QD, but sorry I don't want to use it for now, as I want to share standalone QuickApps on this forum, that do not depend on another external QA. I already store extra information in each child instance. But I don't want to browse self.childDevices on every loop, because if a child has been removed from UI, then it will simply does not show when browsing this table using pairs(). And my mapping table will still references this deleted child, thus will trying to update it. I will do some tests with QuickApp:actionHandler() tonight to check if it performs well...

OK mais là tu viens de me montrer une situation où ça c'est correctement comporté ? Je veux dire un ON à 12:24:39, puis un OFF à 12:24:58 donc 19 secondes plus tard. Ce qu'il faut c'est bien le log quand ça bug. Peut être pas facile à reproduire si ça n'arrive qu’occasionnellement....

Ah oui OK, 24 = doubleclic Mais alors si je comprends bien, c'est comme si GEA interprétait 2 doubles-clics consécutifs.... mais je ne comprends pas pourquoi ! Il faudrait que tu actives le mode GEA.debug=true, puis que tu tentes de reproduire le problème.... ça m'aidera à comprendre.

C'est étrange ta latence concernant le SceneActivation.... il faudrait que je fasse des tests complémentaires, mais il y a actuellement tellement peu de modules Z-Wave sur le réseau de ma HC3 de développement, que ma box n'est pas représentative d'une activité normale. C'est de quel ordre cette latence par rapport à la scène bloc ? 1 seconde... ou plus ? Pour ton constat n°2 avec le OnOff, c'est normal non ? Je veux dire si tu cliques 2 fois sur l'interrupteur, ça allume puis éteint tout de suite la lampe, non ? Ou alors je n'ai pas bien compris ce qu'est censée faire ta ligne GEA.

Thanks, API is OK, the problem is about GEA LUA code. It is not my own development, it's from @Steven and I had (and still have) hard time understanding the code. By the way, I have already added (but commented) the LUA code to find ID from name in latest GEA version, for example : -- -------------------------------------------------------------------------------- -- Retourne l'ID d'une partition d'alarme selon son nom -- -------------------------------------------------------------------------------- --[[ function GEA:findAlarmId(alarmId) -- Lazer if tonumber(alarmId) then return tonumber(alarmId) else local partitions = api.get("/alarms/v1/partitions") local partitionId = nil for _, partition in pairs(partitions) do if partition.name == alarmId then partitionId = partition.id break end end assert(tonumber(partitionId), string.format(self.trad.partition_missing, alarmId)) return partitionId end end --]] So I have no problem to perform action on profile/alarm based on their names. But for conditions and triggering, it's a bit more complicated, because the whole GEA structure is meant to detect changes to devices, not to profile/alarm/whatever. So I must find exactly where I should add extra lines of code to manage alarm and profile's names. I have an idea, so there's hope

J'aimerais bien aussi.... tout comme les partitions d'alarme.... mais je n'ai pas encore réussi... c'est pas faute d'avoir essayé. Je n'abandonne pas pour autant, je finirai bien par trouver un moyen.

OK thank's I have a mapping table for my child devices. This table is quite heavy to build, as it stores a lot of information. To speed up execution, instead of rebuilding this table on every loop (every 60 seconds or less), I think it's more efficient to rebuild this table only on special occasions : upon Quickapp startup, child creation (when user clicks on dedicated button), or child removal (when user removes them in the HC3's devices panel) This last case is out of scope of QuickApp events, so by being able to catch them, the QuickApp will know when to rebuild the mapping table. You're absolutely right about child existence, I must add a test condition.

Hi @jang I would like to intercept events on my QuickApp with child devices. So I have defined a custom QuickApp:actionHandler() function as shown below. Do you think it's OK regarding handling events for both parent and child devices, with no side effect, or am I wrong ? function QuickApp:actionHandler(action) if action.actionName == "removeChildDevice" then -- do some stuff ... end if action.deviceId == self.id then return self:callAction(action.actionName, table.unpack(action.args)) else return self.childDevices[action.deviceId]:callAction(action.actionName, table.unpack(action.args)) end end

Bienvenue sur le forum

Bienvenue sur le forum

Remarque c'est vrai que c'est troublant, partout sur le site d'Aeotec ils écrivent +/- 1°C (donc précision de 2°C). A mon avis ce sont les marketeux qui ont rédigé les pages du site qui se sont plantés. Car je reste persuadé que la précision est de 1°C, comme 99% des capteurs grands publics...il n'y a pas 36 capteurs sur le marché non plus, ils utilisent tous les 2 ou 3 les plus courants. Sinon sur le forum officiel la compatibilité de ce nouveau module avec la HC3 est confirmée : https://forum.fibaro.com/topic/53165-aeotec-zwa009-aërq-temperature-humidity-sensor/?do=findComment&comment=223531

1 degré de précision c'est plus ou moins 0.5

J'ai juste fait un copier-coller, mais je pense que la précision est de 1°C, c'est courant pour ce genre de capteur.

Bienvenue sur le forum

La taille peut être, mais aussi le type de fichier, je pense que les fichiers exe sont bloqués pour des raisons de sécurité (virus...) Si tu n'as pas de compte sur Github, c'est le moment d'en créer un pour héberger ton projet.