Krikroff

Peut-être simplement parce que le callActionGroup est codé avec les pieds Si cela fonctionne local ListeLightsInRoom = api.get("/devices/?roomID="..roomID.."&property=[isLight,true]") for k,v in pairs(ListeLightsInRoom) do fibaro.call(v.id, "turnOff") --turnOn end C'est une solution plus qu'acceptable !

Ceci est la bonne solution, tu ne pourras jamais faire la même chose avec un callActionGroup De plus derrière un callActionGroup il n'y que du lua donc même pas un gain de performance.

bas non faut pas, pourquoi tu n'adaptes tout simplement pas te scène ?? Du coup je ne comprends pas pourquoi nous parlons de la propriété isLight ?

Hein !!! Tu utilises quoi pour passer le filtre, un callActionGroup ?

Le filtre correspondant est en l’occurrence: { roomID=232, visible = "true", properties = {isLight = "true"} }

Properties est une collection tu peux passer autant de propriété que nécessaire de la manière suivante: property=[nom,valeur]&property=[nom,valeur]&property=[nom,valeur] Pour ton besoin il suffit logiquement de faire: ?roomID=232&property=[isLight,true]&visible=true

Oui pas de problème pour cumuler des filtres, tu peux essayer ceci: /api/devices/?roomID=232&interface=light&visible=true

Tu as oublié de passer ta variable comme ceci il me semble fibaro.call(IDVoletSalon, "close")

C’est bien dommage et encore plus pour l’enceinte connectée qui aurait également parfaitement rendue ce service et pas que... Notification vocale etc...

Oui oui c’est possible très certainement en détournement une des deux sorties relais de l’intercom mais je préfère la solution du module au niveau du carillon

GetIDs et GetDevicesId ne sont pas implémentés sur le HC3, pourtant pas compliqué à adapter [emoji2957] Oui essaie de nouveau logiquement le filtre directement sur /devices/? Fonctionne

Tu n’as pas un Switch Fibaro ou un Smart Implant au fond d’un tiroir ? Ensuite tu gères le Carillon sur appel ou appui du bouton

Pour le retour d’un tableau d’ID il faudrait utiliser Fibaro.getIDs mais qui n’est pas porté e sur HC3. Je connais le code qui se cache derrière, je peux le partager si cela intéresse quelqu’un

Non cela retourne la liste de tous les devices filtrés et pas que les ID Ps: désolé j’utilise Tapatalk et le code lua dans les messages est illisible du coup pas simple

Oui du coup il faudrait bouclé sur le tableau de devices retourné cat il peut y avoir plusieurs catégories retournées

Cette possibilité a été évoquée et en attente de retour par FIBARO

Tu as la doc de ton carillon ?

ce n’est pas supporté tout simplement et donc inutilisable selon moi. Pour info derrière un getDeviceIds ou callActionGroup c’est bien un api.get() sur le endpoint /devices/?... et en plus en LUA donc même pas des performances d’une intégration native en C ou autre [emoji6] Étrange que cela ne fonctionne pas le filtre sur RollerShutter directement sur /devices/ j’utilise cela sur HC2 et c’est idem sur HC3

Pas de multiples instances d’une même scène sur HC3 il ne faut pas chercher plus loin je pense [emoji848] et envisager une alternative satisfaisante. Pour le refresh du dashboard je me demande si il n’y a pas un problème avec le refreshstate

Date de disponibilité: 13-03-2020 (avant) > Date de disponibilité: 19-03-2020 (maintenant), quel succès ce home center

Je pense que les triggers partent dans tous les sens, déclechés sur les plages 0-100 Plutôt que operator = "!=", value = 0 je passerai operator = "==", value = 100 ET Plutôt que operator = "!=", value = 100 je passerai operator = "==", value = 0 pour ne prendre en compte que les états 0 et 100 Oui je te confirme que cela n'existe plus... et il y a bataille sur le tracker interne fibaro sur le sujet

Je te confirme que ce n'est pas faisable pour le moment dans les conditions d"une scène, mais bien dans les demandes en attentes Sinon c'est quoi l'idée derrière ? Programmation automatique d'une scène selon un éventement ? des exemples ?

Hum oui ce problème de refresh du dashboard est constaté par beaucoup.

Ah mais tu coup tu veux dire que même dans le HC3 ce n’est pas le bon statut qui est remonté ?

C’est top [emoji4] bien joué. Côté ressources, cela occupe un thread le temps du setTimeout mais pas bloquant Pourquoi n’utilises tu pas plutôt un type Binary sensor ? Sauf si tu as besoin de faire une action genre On/Off sur ton QA [emoji6]