J3R3M

Il s'agit effectivement du 3ème paramètre, dont il ne faut visiblement pas modifier la valeur. J'ai déjà essayé s'augmenter la sensibilité (paramètre 1) et ça avait mené à de détections de mouvements sans raisons toutes les 4-5mn, sans arrêt! Et ce, alors qu'ils ne mettaient pas en garde sur la baisse de cette valeur, alors quand ils nous mettent en garde, je n'ose pas imaginer à quel point ça doit devenir hasardeux! Pour ma part, je ne pense pas qu'un maillage soit effectué, mon pôle domotique/réseau étant au coeur du domicile. Pour que le réseau Z-Wave soit surchargé, je présume qu'il faille que beaucoup de modules soient actifs simultanément? Ce qui n'arrive jamais chez moi. C'est bien ce que j'avais en tête, mais pour le coup, c'est nettement moins "smart", d'après-moi. Enfin, cela dépend des modules interconnectés, mais faire cela entre un interrupteur et une ampoule (ou un FGD), cela revient au même que s'il y avait un câblage électrique simple entre les deux, en plus cher. Mais cela est strictement personnel et je n'ai sans doute pas pensé à un cas où cela pourrait être utile. Je vais procéder à quelques tests afin d'essayer de localiser la/les cause(s) de ces latente(s). @Cmoi20, j'utilise le VD Hue de Talwayseb (un peu modifié pour me correspondre, mais le même dans le fonctionnement). Les requêtes semblent bien envoyées sur l'API LAN du HueBridge, mais merci de cette suggestion!

Merci de ce script, cela peut être très utile pour optimiser la programmation de certains scripts. Je trouve que c'est bon à savoir, même si ça semble dérisoire, mais dans le cas, on ne calcule que le temps d'accès à l'information C'est-à-dire que l'on connaît déjà les IDs des modules, ce qui impose d'avoir au préalable un script qui liste les IDs des modules à vérifier, ce qui sera forcément plus long que si on a directement l'accès à l'info dans une VG. Si tu as publié ton script avec les valeurs testées, on est donc sur 1000 tests d'accès, la différence doit donc être 10 fois plus flagrante avec 10 000 tests, bien que ça n'arrive jamais. Une petite question concernant le script que j'essaie de comprendre au maximum : dans la ligne suivante : execute("getVG :", function() local v,m = fibaro:getGlobal(VG) end) À quoi correspond la variable "m", s'il-te-plaît ?

Je continue de m'interroger... Au niveau temps d'accès, est-il plus rapide de récupérer une information de la base de données que récupérer celle d'une VG? Concrètement, pour connaître le timestamp du dernier mouvement d'une pièce, est-il plus rapide de l'enregistrer dans une VG (lors de la détection d'un mouvement) pour la récupérer directement ensuite ou est-il préférable de récupérer l'information LastBreached d'un module ? Je parle bien évidemment en terme de rapidité d'accès, j'ai bien saisi que l'information était stockée dans la Base de Données dans tous les cas.

J'avais déjà fait ça il y a quelques mois et c'est à ce moment là que je m'étais dit que les FGMS avaient une certaine latence. Mais je vais quand même réitérer, tu as raison, pour vraiment mesurer la différence entre l'exécution directe d'une action et l'exécution de mon script avoir avoir détecté un mouvement.

Pour imager mes propos, voilà ce qui arrive quelques fois : Je provoquais volontairement des mouvements dans la cuisine. Ne voyant aucun message de debug (ni de lumière s'allumer d'ailleurs), je continuais. J'ai arrêté de bouger pour me demande ce qu'il se passait. Au bout de quelques secondes, tous ces messages sont apparus d'un coup et la scène s'est exécutée. Pour le coup, je ne suis pas certain que ça soit vraiment lié à la lenteur d'exécution du script sur ce coup-ci, mais plus à une latence de transmission de l'information par le trigger (qui, pour le coup, est à 2m de la HC2) ou à des difficultés de la scène à s'exécuter lorsqu'elle n'a pas été sollicitée depuis plus d'un certain temps.

Bon, le fait que tu passes par autant de périphériques réseaux et que tu aies "aussi peu" de latence prouve quand même que j'ai un soucis de mon côté, puisque je n'ai que deux switchs et ils sont tous deux directement câblés sur le routeur! Mais je me suis déjà bien rendu compte que les Hues posaient problème lorsque, par exemple, des téléchargements lourds étaient effectués en wifi, malgré l'utilisation d'un vrai routeur wifi (Asus RT-AC3200). Je n'ai malheureusement pas la possibilité d'attribuer une bande uniquement aux hues, puisque pour le routeur, il n'y a qu'un périphérique Hue et il est en LAN... Bref, voilà pourquoi j'essaie de grappiller des millisecondes par-ci, par-là, pour limiter au maximum la latence, tout en préservant une scène "intelligente". Après, il est toujours possible de publier le script en question, mais le temps nécessaire pour l'apprivoiser en découragerait plus d'un, moi le premier!

Pour détecter les mouvements, j'utilise des FGMS et des caméras. Tous les mouvements démarrent le même script et la première vérification de celui-ci est de retrouver à quelle pièce est associée son trigger. C'est souvent assez rapide (de l'ordre d'une seconde), mais j'ai remarqué que lorsque le trigger était une caméra, l'allumage était plus rapide. Quelques fois, la HC2 donne l'impression d'avoir besoin de se remettre en jambe et met un peu plus de temps à allumer une lumière, du moins c'est ce qu'on pourrait se dire. Je ne m'aide pas en utilisant que des ampoules Hue, ce qui signifie que tout passe par le Pont Hue puis par le Wifi, ce qui n'aide vraiment pas à gagner du temps. Mais il est vrai que des fois, je me rends vraiment compte de la lenteur d'exécution d'un script, je suis capable de le décomposer : Relais du Wall Plug qui s'enclenche avec une lumière qui s'allume 1 seconde plus tard, par exemple. Je précise quand même qu'une lumière peut parfois mettre 3s à s'allumer, quand elle s'allumera quasiment instantanément 10mn après, dans les mêmes conditions. Mon script est sans cesse modifié en ce moment, mais actuellement, voici ce qu'il fait (238 lignes) :

En effet, je n'avais pas saisi que tout avait été déporté. C'est bien au-dessus de mes compétences et je ne m'y risquerai donc pas! Dans mon cas, la solution la plus simple serait donc de modifier les fichiers de la HC2. Qui seront donc, à remodifier à chaque mise à jour. Puis-je pousser le bouchon en demandant quel(s) fichier(s) serai(en)t à modifier pour que les informations soient accessibles par les scènes et VDs ?

Salut @Lazer et merci de cette réponse! J'avais bien en tête qu'un Linux pouvait facilement être modifié. Mais cette solution semble être tellement du côté obscur de la force que je n'ai même pas réussi à trouver une architecture des dossiers et fichiers de la HC2, bien qu'il puisse être "rapide" de la reconstituer une fois connecté. Par contre, ta solution d'hébergement des scripts m'intéresse fortement (notamment parce qu'elle est pérenne)! Cela signifie qu'à chaque mise à jour, tu réédites seulement un fichier de la HC2 en précisant où trouver les fichiers que tu as délocalisé? Fichiers délocalisés sur un NAS ? Concrètement, j'aimerais que certaines informations "fixes" de ma HC2 soient directement accessibles par les scènes et VD, sans passer par une VG encodée, afin de gagner en rapidité d'accès. Si je peux grapiller quelques millisecondes d'attente dans le noir, ça ne serait pas de refus... J'ai pu remarquer que les FGMS mettaient souvent un peu de temps à envoyer l'info à la HC2. Cumulé à un gros tableau json encodé dans une VG, je peux attendre jusqu'à 2-3s pour l'allumage d'une lumière dans certains cas... :/ Rien à voir, mais je ne savais même pas qu'il y avait un mot différent pour parler de l'auto-hack d'un téléphone, en fonction de la marque!

Je m'auto-réponds pour le SSH, seul Fibaro connait les identifiants pour y accéder. Mais, je serai étonné que personne n'ait tout de même détourné cela d'une manière ou d'une autre!

Bonsoir à tous, Le sujet sur la volonté que Fibaro autorise la création de Fonctions Globales m'a poussé à me poser quelques questions... Depuis le temps que la HC2 existe, n'y-a-t'il pas quelqu'un qui ait encore hacké sa HC2 dans le but de la rendre encore plus efficace? De nombreuses personnes connaissent parfaitement la HC2, personne d'entre-vous n'a passé le cap en piratant sa HC2 afin de créer, par exemple, ses propres fonctions globales? Il est certain que toutes les fonctions LUA créées par Fibaro sont créées sur un fichier qu'il doit être possible de modifier, notamment en SSH je suppose. Si une méthode pour le faire voyait le jour, cela pourrait faciliter la vie (du moins la programmation) de beaucoup de monde! N'y-a-t'il que moi qui ait l'esprit tordu à ce point?

En fait, voici comment sont gérées les informations de mes pièces, avec les explications en commentaire. Est-ce que parcourir cette table (qui est assez conséquente, je le conçois) causerait des pertes de performance dans mes scripts? Puisque j'utilise les informations de la base, c'est certain, mais je les joins à d'autres paramètres que je crée dans ce tableau. (Oui, j'ai les explications en commentaire, s'il m'arrivait quelque chose, j'aimerais bien que ça soit compréhensible :P) --id = ID de la pièce correspond à l'id du bouton du VD Pièce Active --Code = Code de la pièce. Doit être similaire à la clé du tableau principal --Nom = Nom de la pièce avec majuscule et accents (pour utilisation propre dans SMS par ex) --Article = Article du nom de la pièce (ex : "l'" pour "entrée") --Detect = Table des id des détecteurs Fibaro. Si cam, mettre "cam" --LumMini = À partir de quel seuil de luminosité (lux) la lumière doit-elle s'allumer. nil si uniquement cam --LumMax = Table des luminosités maximales détectées par chaque détecteur lorsque toutes les lampes gérées sont allumées à 100%. Le but étant de se baser sur ses valeurs pour déterminer si une autre source de lumière est présente. --Passage = 0/1 - Pièce de passage ou non ? Par exemple, un couloir est un lieu de passage. --TpsActive = Temps maxi durant lequel la pièce restera considérée comme active sans le moindre mouvement --JourNuit = 0/1 - Gestion automatique de l'allumage de la pièce (basé sur les heures de levés et couchés du soleil). Utile lorsque seule une cam détecte les mouvements de la pièce --HueGroup = Table des Ids des VDs Groupe Hue de la pièce --HueList = Table des Ids des VDs des ampoules Hues utilisées dans la pièce --HueType = Table des types des lampes Hues précédemment déclarées ------------------------------------------------------------------------------ -- Pour les réglages Hue suivants, si une seule valeur est définie, on utilisera -- le(s) groupe(s) défini(s) ci-dessus dans HueGroup -- Toutes les valeurs sont stockés dans une table, pour chaque réglage -- Valeur de 0 à 100%, dans le même ordre que les lampes ont été définies dans HueList ------------------------------------------------------------------------------ --HuePowerDodo = Table des valeurs lorsque la pièce est en mode DODO --HuePowerAM = Table des valeurs lorsque Moment = Matinée --HuePowerMidi = Table des valeurs lorsque Moment = Midi --HuePowerPM = Table des valeurs lorsque Moment = Après-Midi --HuePowerSoir = Table des valeurs lorsque Moment = Soirée --HuePowerNuit = Table des valeurs lorsque Moment = Nuit --SonosId = ID du VD SONOS de la pièce --SonosVMax = Table contenant les volumes maxi autorisés pour l'enceinte, en fonction du moment de la journée --SonosV = Table contenant les volumes auxquels seront montées la SONOS en fonction du moment de la journée --VoletsR = IDs des Roller Shutter de la pièce (pour gestion auto) --Chambre = La pièce est-elle une chambre ? ------------------------------------------------------------------------------ ---------- Les valeurs suivantes sont gérées par les scènes et vd ------------ ------------------------------------------------------------------------------ --Dodo = Mode DODO de la pièce 0 ou 1 --DodoMT = Dodo Modification Time --Mise = Mise = 0/1 - Si Mise = 1, gestion manuelle des éclairages de la pièce --PowerMode = Valeur ou Auto géré via le VD Puissance Lights --LastHueValue = Dernières valeurs (Puissance) des Hues de la pièce avant extinction. Ces valeurs seront rappelées en cas de nouveau mouvement dans l'heure. --LastSonosLvl = Dernier niveau de puissance des enceintes de la pièce --LastMove = Dernier mouvement détecté dans la pièce --LastLightsOn = Dernier allumage automatique effectué dans la pièce --LastLightsOff = Dernière extinction automatique effectuée dans la pièce ------------------------------------------------------------------------------ -------- Récupération des valeurs gérées automatiquement -------- local table = json.decode(fibaro:getGlobalValue("T_INFOS_PIECES")); -------- Paramètres des Pièces ------- local pieces = {}; pieces["ENTREE"] = { id = 1, Code = "ENTREE", Nom = "Entrée", Article = "l'", Detect = {"cam"}, LumMini = nil, LumMax = {nil}, Passage = 1, TpsActive = 2, JourNuit = 0, HueGroup = {298}, HueList = {89,96,113,112}, HueType = {"hcol", "hcol", "hcol", "hcol"}, HuePowerDodo = {5,0,0,5}, -- Une valeur = utilisation groupe HuePowerAM = {30}, HuePowerMidi = {40}, HuePowerPM = {40}, HuePowerSoir = {40}, HuePowerNuit = {30}, SonosId = 245, SonosVMax = {40,50,50,50,40}, SonosV = {30,35,35,35,30}, VoletsR = {nil}, Chambre = 0, Dodo = table["ENTREE"].Dodo, DodoMT = table["ENTREE"].DodoMT, Mise = table["ENTREE"].Mise, PowerMode = table["ENTREE"].PowerMode, LastHueValue = table["ENTREE"].LastHueValue, LastSonosLvl = table["ENTREE"].LastSonosLvl, LastMove = table["ENTREE"].LastMove, LastLightsOn = table["ENTREE"].LastLightsOn, LastLightsOff = table["ENTREE"].LastLightsOff }; pieces["SDB"] = { id = 3, Code = "SDB", Nom = "Salle de Bain", Article = "la ", Detect = {220,261}, LumMini = 4, LumMax = {219,5}, Passage = 0, TpsActive = 2, JourNuit = 0, HueGroup = {301}, HueList = {93}, HueType = {"hcol"}, HuePowerDodo = {5}, -- Une valeur = utilisation groupe HuePowerAM = {100}, HuePowerMidi = {100}, HuePowerPM = {100}, HuePowerSoir = {100}, HuePowerNuit = {100}, SonosId = 244, SonosVMax = {90,100,100,100,90}, SonosV = {30,35,35,35,30}, VoletsR = {nil}, Chambre = 0, Dodo = table["SDB"].Dodo, DodoMT = table["SDB"].DodoMT, Mise = table["SDB"].Mise, PowerMode = table["SDB"].PowerMode, LastHueValue = table["SDB"].LastHueValue, LastSonosLvl = table["SDB"].LastSonosLvl, LastMove = table["SDB"].LastMove, LastLightsOn = table["SDB"].LastLightsOn, LastLightsOff = table["SDB"].LastLightsOff }; fibaro:setGlobal("T_INFOS_PIECES", json.encode(pieces)); fibaro:debug("Informations enregistrées.");

Merci encore de ces précisions. Suite à ton post, j'ai fait quelques recherches et j'ai pu découvrir que bien des fonction de l'API Fibaro m'avaient échappées. Une fois de plus, une nouvelle interrogation : niveau rapidité d'éxecution et performance d'un script. Actuellement, les IDs de tous mes détecteurs de mouvements sont effectivement stockées dans une VG (tableau json, indexés par pièce). Malgré la redondance de l'info des IDs dans la base de données, j'aurais tendance à penser qu'un script s'exécutera plus rapidement en parcourant des IDs connus, plutôt qu'en reformant un préalable un tableau avec les IDs qui nous intéressent avant de les traiter. Je me relis et je me dis que ça peut paraître confus, voici deux exemples rapides : -- Cas 1 : IDs déjà référencés dans un tableau -- Dans mon cas, la clé est le nom que j'ai donné à ma pièce local piece = "SALON"; local t = {}; t["SALON"] = {3,19}; t["CUISINE"] = {7,45}; tablePiece = t[piece]; for k,v in pairs (tablePiece) do fibaro:debug(v); end -- Cas 2 : Recherche dans la base de données de la HC2 -- Donc utilisation obligatoire de l'ID de la pièce, puisqu'on a besoin de l'ID d'un module de la pièce pour fibaro:getRoomName(), n'est-ce pas? local PieceId = 6 local devices = fibaro:getDevicesId({roomID=PieceId,baseType="com.fibaro.FGMS001",visible=true}) for k,v in ipairs(devices) do fibaro:debug(v); end Suis-je une fois de plus dans le faux?

Dans mon cas, chaque détection de mouvement mène sur des actions différentes pour chaque type de module, mais elles ne sont pas liées par autre chose que le déclencheur. L'allumage ou non de la lumière est totalement indépendant de l'augmentation du volume des enceintes de la pièce par exemple. Tout comme l'allumage ou non d'un Wall Plug. Il n'y a vraiment rien de lié. J'ai préféré utiliser une seule scène, qui peut parfois mettre un peu de temps à s'exécuter complètement, en me disant que ça serait plus simple à gérer par la HC2 que 4-5 scènes qui pouvaient démarrer simultanément pour chaque nouveau mouvement. Mais peut-être suis-je dans le faux? Concernant les Variables Globales, j'y ai, peut être à tort, stocké la totalité des informations nécessaires pour mes pièces. De l'ID des modules la concernant jusqu'aux réglages des différentes valeurs en fonction du moment de la journée. Ça impose de rechercher dans cette VG pour chacune de mes scènes, mais ça limite à l'utilisation d'une seule scène pour toutes les pièces.

Merci de ces précisions @Steven! Je me permets de demander quelques précisions supplémentaires. Concernant les scènes... Est-il mieux de minimiser le nombre de scènes ou de bien distinguer chaque action? Par exemple, à l'heure actuelle, une seule scène gère toutes les pièces de chez moi, que ça concerne la lumière, les enceintes, les Wall Plugs, la gestion des caméras, l'alarme... Serait-il préférable d'avoir une scène par type d'action?

Les VGs ne seraient-elles pas auto-protégées de fausses modifications ? En fait, en faisant des essais, j'ai pu me rendre compte que la valeur renvoyée par le fibaro:GetGlobalModificationTime() d'une VG ne variait pas lorsqu'on renvoyait exactement même valeur dans la Variable Globale, même plusieurs jours après.

Heureux de constater que je ne suis pas le seul à m'interroger! :-)

Hello, Je me pose une petite question concernant la programmation LUA sur la HC2. Je sais que la formulation du titre de ce message peut paraître décousue, mais je vais essayer de l'expliciter, notamment par un ou deux exemples. Je cherche à savoir comment vous organisez vos actions sur vos HC2. Le but étant de savoir ce qui la sollicite le moins. À savoir, dans des situations particulières, est-ce qu'il est préférable de reproduire la même action ? Ou bien, est-il plus optimisé de d'abord vérifier un état avant d'effectuer une action? Quelques exemples : Allumage automatique de la lumière Celle-ci est déjà allumée. Lorsqu'un nouveau mouvement est détecté dans la pièce, vous renvoyez l'ordre d'allumer (Device ou Virtual Device) ou vous mettez en place une condition qui vérifie si la lumière est déjà allumée? Variable Globale de détection de téléphone Votre téléphone a été détecté par un script bash. Celui-ci appuie sur un bouton de VD toutes les 10s. Même question, est-il préférable de le laisser agir ou de mettre en place une condition pour vérifier avant la modification? Enregistrement automatique des caméras Les caméras enregistrent automatiquement lorsqu'un mouvement est détecté et que personne n'est reconnu au domicile. On appuie sur le bouton REC à chaque nouveau mouvement ou on vérifie avant si un enregistrement est déjà en cours? De mon côté, j'effectue à chaque fois une vérification avant de modifer un état ou d'appuyer sur un bouton. Cependant, dans quelques cas plus complexes, la vérification prendra beaucoup de lignes de code, là où l'envoi de la commande (donc potentiellement répétée très régulièrement) n'en prendra qu'une. J'ai tendance à penser que l'appui sur un bouton de VD (par exemple) toutes les minutes sollicitera moins notre HC2 que plusieurs vérifications (dans plusieurs Variables Globales, plusieurs VD). Suis-je dans le faux? Comment faites-vous de votre côté?

Salut @pepite et merci encore de ta réponse. Décidément, cette incohérence LUA entre VD et Scènes me chagrine!

La scène existe déjà et je l'ai même remis au goût du jour et publié ici en Août Voir le post ici. Ma version de la scène est légèrement différente pour mes besoins, mais cette scène gère déjà parfaitement la Welcome! En effet. Lorsque je l'ai achetée, j'espérais pouvoir l'associer avec la HC2 et c'est ce que j'essaie de faire au mieux. Mais j'espère fortement que quelqu'un découvre la possibilité de traiter directement les informations en local, ne serait-ce que pour palier à un arrêt du fonctionnement de l'outil en cas de coupure d'internet. Malheureusement, à l'heure actuelle, seul Netatmo propose une telle technologie de reconnaissance faciale, technologie que je trouve très utile au quotidien domotisé

Bonjour à tous, Je déterre légèrement mon topic, puisque j'ai une demande similaire, à savoir une équivalence VD/Scène que je n'arrive pas à effectuer. Je cherche à agir sur l'API Netatmo depuis un VD. Ce code fonctionne parfaitement dans une scène : local home_id = "aaaaaaaaaaaaaaaaa"; local api = "https://api.netatmo.com"; local arg = "/api/setpersonsaway"; local datas = "?access_token="..fibaro:getGlobalValue("NETATMO_Token").."&home_id="..home_id; local http = net.HTTPClient(); local url = api..arg..datas; http:request(url, { options = { method = 'GET', data = json.encode(newVar)}}); Mais je n'arrive pas à envoyer cette URL depuis un VD. Les code suivants ne fonctionnent pas : local home_id = "aaaaaaaaaaaaaa"; local URL = "https://api.netatmo.com"; API = Net.FHttp(URL,80) API:GET("/api/setpersonsaway?access_token="..fibaro:getGlobalValue("NETATMO_Token").."&home_id="..home_id) local home_id = "aaaaaaaaaaaaaaaaaaaa"; local URL = "https://api.netatmo.com"; API = Net.FHttp(URL,80); API:PUT('/api/setpersonsaway', '{"access_token":'..fibaro:getGlobalValue("NETATMO_Token")..', "home_id":'..home_id..'}'); J'ai vraiment beaucoup de mal avec ces différences Net.FHttp et net.HTTPClient! Qu'est-ce qui cloche dans mon code svp?

Récupérer toutes le infos de vos caméras Netatmo : - Rendez-vous sur ce lien et connectez-vous sur votre compte développeur si nécessaire - Votre "access_token" sera pré-rempli dans la partie "Try this method by yourself with our TRY IT module.". Copiez-le. - Aller à l'adresse suivante et collez le "access_token" précédemment copié à la fin de celle-ci. https://api.netatmo.com/api/gethomedata?access_token=Votre ACCESS_TOKEN Vous aurez ainsi à disposition toutes les infos nécessaires pour agir sur vos caméras. Pour ma part, j'ai donc récupéré mon "home_id" ainsi que mes "user_id" afin de pouvoir déclarer quelqu'un parti grâce à un lien de ce type : https://api.netatmo.com/api/setpersonsaway?access_token=AAAAAAAAAAAAAAAA&home_id=BBBBBBBBBBBBB&person_id=CCCCCCCCCCCCCCCCC Je vais quand même continuer de cherche une solution locale, en espérant seulement que ça soit possible

Effectivement @jojo, tu as raison. Là où je cherchais absolument à agir sur mon IP locale, il y a une solution presque simple via l'API en ligne de Netatmo. Cela m'embête tout de même un peu de dépendre d'une connexion internet et surtout, de leurs serveurs...

Bonjour à tous, À l'heure actuelle, la Neatmo Welcome participe grandement à identifier les personnes présentes à mon domicile. Les informations de celle-ci sont remontées dans la HC2 via la scène adéquate. Cependant, il y a deux manières pour qu'un individu soit absent pour la Welcome : - Après un laps de temps prédéfini et paramétrable sans que celui-ci ne soit vu - Déclarer l'individu comme en dehors du domicile. Et c'est cette deuxième option qui m'intéresse, la première ne me convenant que très moyennement. Cependant, j'aimerais que ces variables de la Welcome puissent être modifiées depuis la HC2. Est-ce possible? Existe-t-il déjà une solution pour cela (et si tel est le cas, je n'ai pas suffisamment cherché)? Si une solution n'existe pas encore et qu'elle est réalisable, par où commencer? Je suis loin d'être un développeur et de comprendre grand chose avec les comptes développeurs, mais j'ose espérer qu'un simple bouton ON/OFF d'une appli en ligne se laisserait dompter aisément!

Merci de ces réponses. Je n'ai pas encore essayé. J'avoue que ça me chiffonne pas mal que l'enchainement ne se fasse pas correctement. Et je trouve ça vraiment aberrant de devoir temporiser pour espérer que des actions fonctionnent dans 100% des sollicitations. Surtout quand les messages de debug sont bien executés! En fait, lorsque toutes les chambres de chez moi sont en mode "DODO", une boucle est générée pour envoyer un preset bleu foncé aux Hues des pièces partagées (et ainsi on ne se fait pas flasher la tronche lorsqu'on se réveille et se déplace dans la nuit). Le même principe a lieu lorsqu'une des chambres quitte le mode "DODO", une boucle renvoie une preset adéquat. Mais ce n'est pas rare qu'une lampe soit restée blanche dans la nuit, ou bleue au réveil... Surtout quand le debug affiche bien le traitement de toutes les pièces, c'est légèrement déconcertant...