Lazer

Non non pas la peine de se prendre la tête, lisez bien le lien que j'ai donné, tout y est expliqué, le problème vient du serveur de mise à jour de chez Fibaro. Bref, attendez patiemment, c'est Fibaro hein, pas l'équipe de développement la plus réactive qu'on connaissance...

En fait c'est plus simple. Puisque justement le code original ne change pas. Pour le do end, je suppose que ça sert à créer une closure pour limiter la portée des variables locales à cette closure (dès fois que ce code soit dans un fichier qui comprend plein d'autres choses)

C'est assez simple (et génial) en fait ce que @jang te propose. Il redéfinie toutes les fonctions "à risque" de Fibaro dans un nouveau fichier du QuickApp. Donc à l'utilisation, ça ne change rien, tu continues à utiliser les fonctions normalement (sans t'embêter avec les pcall(), mais elles seront protégées par des pcall() quand même)

Sinon pour l'interrupteur spécifique, j'ai retrouvé, c'était une recherche puis un tuto de @turlututu74 Mais le module RGBW doit être configuré en mode Input/Output, donc on perd la possibilité de l'utiliser simplement avec l'interface web et l'application mobile Du coup à l'époque il avait fait un Virtual Device, ça ne me plaisait pas car même ainsi, ce n'était pas intégré nativement dans l'application mobile. Avec la HC3 on doit pouvoir faire un QuickApp de type colorController et retrouver le fonctionnement natif, mais il y aura un peu de LUA à coder. ça me donne presque envie de me lancer dans l'aventure pour le ruban de ma salle cinéma.... ça fait une idée de projet pour plus tard EDIT : produit vraiment difficile à trouver. Une rapide recherche sur Amazon et Aliexpress ne remonte que des contrôleur 0-12V ou 0-24V, mais pas de simples interrupteurs 0-10V Il faudrait creuser plus la question...

Et bien ça tu l'as en fait rien qu'avec le bouton 1. Bon tu ne choisis pas directement la couleur, faut attendre pour faire défiler les couleurs, mais ça semble répondre à ton besoin. Les boutons 2 et 3 optionnels permettent de changer la saturation et la luminosité, mais c'est pas indispensable si tu laisse la saturation et la luminosité tout le temps à 100% (ou que tu les contrôle par scénario en fonction de l'heure de la journée, de luminosité ambiante, etc) Page 15 dans la doc, mais je n'ai jamais utilisé :

Bah.... comment voudrais tu faire autrement ? C'est comme dire que tu voudrais piloter ta TV avec 1 seul bouton, ce n'est pas possible, l'appareil fait plein de trucs, il faut une télécommande avec pleins de boutons. Après faut pas oublier que c'est de l'éclairage d'ambiance, ça ne remplace pas l'éclairage principal de la pièce qui lui est toujours piloté par l'interrupteur principal. Donc souvent, le RGB est piloté par la domotique (scénarios préprogrammés, la plupart des gens ont leur couleur préférée et utilisent souvent la même... ou un échantillon de couleurs préférées, c'est pour cela que Fibaro permet d'enregistrer quelques couleurs perso). Et on pilote par scénario automatiques, téléphone, commande vocale, etc. Sinon tu as la platine interrupteur évoluée que j'évoquais lors de mon message précédent.

Non pas possible je pense, avec 1 poussoir tu peux contrôler une seule fonction. Sinon il existe des interrupteurs "évolués" permettant de choisir la couleur, je crois qu'on en avait parlé il y a quelques années sur le topic du RGBW 1ère version, tu pourras peut être y retrouver des références.

Bienvenue sur le forum

Bienvenue sur le forum

Voilà, et voir la réponse complète de @tinman J'aime particulièrement : The question only is "how really important the update is today, can i wait a day?" Quand ça arrive ils retirent complètement le firmware, c'est déjà arrivé quelques fois.

Non pas grave, si ça fonctionne bien, aucune raison de faire de mise à jour après tout Pas mieux chez moi non plus.... il faudrait contacter le support Fibaro pour les en informer, ils ne s'en sont peut être pas rendus compte...

Il va falloir reprendre l'habitude de poser vos question sur le topic du support GEA les gars Bref, ce message t'informe que tu n'as aucun déclencheur instantanée (durée = -1) parmi tes règles.

Tu parles d'accès à distance... du coup ça me met la puce à l'oreille. Tu accèdes bien à ta box en locale (adresse IP), et non pas via le cloud Fibaro ? C'est un prérequis pour les mises à jours je crois. Et fait la mise à jour stable, ne fait pas la beta. EDIT : la vache, tu es vraiment sur un vieux firmware, tu n'as pas fait de mise à jour depuis quoi, l'année dernière ? EDIT 2 : lol je suis allé sur la page de firmware de ma box, et ça fait erreur 500... incroyable ça, jamais vu ça. EDITH Piaf : surement un problème coté serveur Fibaro, attends demain ça ira surement mieux. Heureusement la box n'est pas plantée, les autres pages fonctionnent normalement.

Désolé j'ai été pas mal occupé aujourd'hui. Apparemment (d'après mes tests rapides) la seule valeur tolérée pour deviceControlType maintenant c'est 1. Ce n'est pas documenté de toute façon, donc il te faut faire des essais successifs si tu veux identifier les valeurs autorisées....

Ah mince, c'est bête ça, quelle idée aussi d'aller se coucher si tôt Plus sérieusement, désolé si ça t'a fait planter la box.... c'est étrange quand même. Cela dit, la HC3 dispose d'un Watchdog intégré, donc elle devrait rebooter toute seule.... mais je ne sais pas au bout de combien de temps par contre.

Enlève le deviceControlType, je suis presque sûr que c'est le problème, j'avais eu le souci avec Surveillance Station ou un autre QA de mes débuts, car l'API Fibaro a changé entre temps. Tu serais tombé dessus en procédant par élimination comme je te l'ai suggéré.

OK... donc il y aurait bien un problème avec les paramètres donnés à self:createChildDevice() Tu peux essayer d'en virer au maximum pour ne laisser que l'essentiel ? name et type je crois Puis tu procèdes par élimination pour trouver le coupable. Autre chose que tu peux faire aussi, juste avant l'appel de cette fonction, c'est ajouter les debug suivants : tools:debug(tools:tostring(childProperties, true, true)) tools:debug(tools:tostring(childInterfaces, true, true)) tools:deepPrint(childProperties) tools:deepPrint(childInterfaces) ça va te permettre de voir précisément le contenu des tables, et le type exact de chaque variable

Ton log te montre que les variables self.id et self.name ne sont pas encore initialisée à ce moment là (ce qui est sans conséquence car la fonction (tools.trace() se contente d'afficher nil) Le tools.log() te met aussi un warning. Après ça plante, je ne saisis pas bien pourquoi. Mais essaye de tout virer dans __init(), il doit y avoir un truc qui ne lui plait pas. Laisse juste QuickAppChild.__init(self, device) qui est obligatoire

Là je pense que ça n'a rien à voir avec la gestion des profiles, ta 2nde règle contient une condition de plage horaire, est-ce que tu es bien dans la plage depuis la durée de 30s ? Autre remarque, le Sleep que tu utilises a une tempo de 30s, donc... le profile n'est modifié que 30s après l'exécution de la 1ère règle. Pas évident de jongler avec la gestion temporelle... Non pas du tout, rien de particulier à faire Non, le print() que tu vas mettre dans ta fonction function setEvents() ne va s'exécuter qu'au démarrage de GEA, pas pendant la vérification des règles qui a lieu toute les 30s, car elles sont chargées en mémoire. Donc GEA ne revient jamais dans la function setEvents()... sauf en cas d'exécution instantanée sur événement / trigger, avec durée = -1 C'est plus ou moins la même chose qu'une variable locale en LUA... c'est à dire une variable en mémoire RAM, perdue lors du redémarrage de GEA Puisqu'on ne peut pas utiliser les variables locales dans la function setEvents() (voir explication au dessus), ces "VariableCache" permettent de stocker des informations en mémoire pour être utilisées dans les prochains cycles de GEA. Exemple, j'en utilise une pour déclencher l'aspirateur 1 seule fois par jour, sans ça il se redéclencherait plusieurs fois par jour dès que la batterie est rechargée : -- Robot aspirateur Xiaomi Roborock GEA.add({{"Profile", "Absent"}, {"Value", id["QA_XIAOMI_ROBOROCK"], false}, {"Battery", id["QA_XIAOMI_ROBOROCK"], 100}, {"VariableCache!", "Aspirateur", true}}, 5*60, "", {{"QuickApp", id["QA_XIAOMI_ROBOROCK"], "clean"}, {"VariableCache", "Aspirateur", true}}, "Démarrage aspirateur") GEA.add({"Time", "00:00", "00:01"}, 0, "", {"VariableCache", "Aspirateur", false}, "VariableCache Aspirateur") Autre exemple, mémoriser la valeur de 2 lumières, les allumer à 100%, faire une action (ici une photo), puis les rétablir à leur niveau précédent, le tout en 1 seule règle : GEA.add( { {"Label", id["VD_OCTOPRINT"], "LabelJob", "Operational"}, {"Label", id["VD_OCTOPRINT"], "LabelJobProgress", "100.0 %"} }, 30, "Impression 3D terminée à #time#", { {"VariableCache", "LED_IMP3D_HAUT", {"Value", id["LED_IMP3D_HAUT"]}}, {"VariableCache", "LED_IMP3D_COTE", {"Value", id["LED_IMP3D_COTE"]}}, {"value", {id["LED_IMP3D_HAUT"], id["LED_IMP3D_COTE"]}, 99}, {"Email", "Christophe", "Octoprint : Impression 3D terminée avec succès à #time#", "GEA : Octoprint"}, {"Sleep", 10, {"Picture", id["CAMERA_IMPRIMANTE_3D"], "Lazer"}}, {"Sleep", 15, {"Value", id["LED_IMP3D_HAUT"], {"VariableCache", "LED_IMP3D_HAUT"}}}, {"Sleep", 15, {"Value", id["LED_IMP3D_COTE"], {"VariableCache", "LED_IMP3D_COTE"}}} } )

Y'a un truc que je pige pas bien dans ton log, je vois que la fonction __init() s'exécute, donc le child a bien été créé non ? En tout cas même si le child n'a pas été créé dans la Database de la HC3, l'objet a bien instancié en mémoire à partir de la classe. Par contre cette fonction __init() affiche des trucs pas très rassurants "nil" comme si dans l'init, tu avais des instructions qui vont utiliser des variables qui ne sont pas (encore ?) initialisées Ensuite tu as un appel à tools:log(), et là aussi il n'est pas content car il affiche un message d'erreur. Puis il y a plantage dans quickApp, qui est un fichier interne à la box auquel nous n'avons pas accès. Ce plantage est intercepté grâce au pcall() de la fonction tools:createChildDevice() qui retourne donc false, ce qui permet à ton QuickApp de continuer à s'exécuter et d'afficher le beau message d'erreur. Bref, pour moi l'erreur elle n'est pas dans la création du child, mais dans la fonction __init() de ton child

Il faudra que je reproduise le problème chez moi... mais pas tout de suite. Si en attendant @Dragoniacs a une idée pour te débloquer

Je ne me souviens plus des modifications apportées entre la v2.10 et la v2.20, mais déjà tu devrais commencer par utiliser cette dernière, peut être que le bug sera corrigé. Sinon il faudra que je me penche sur le problème plus en profondeur (j'ai déjà une v2.30 qui est prête, mais elle ne corrige pas ce problème lié à createChild)

Oui c'était assez long... Mais instructif

Ah mince alors, désolé, j'ai donc écris une bêtise Merci pour la doc à jour, je la mettrai en 1ère page