Lazer

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

Merci pour la suggestion, ça sera pour une prochaine version alors Tu sais qu'en attendant, plutôt que de modifier le code de GEA dans le fichier main, tu peux définir tes propres options dans ta fonction config() : function config(GEA) ... GEA.options.sleep = {name = "Sleep", .... } } Normalement si tu redéfinies une option qui existe déjà, l'originale sera replacée par la tienne.

Non je ne sais pas désolé, si ton réseau fonctionne bien et que la HC2 a accès à Internet (mise à jour possible), alors c'est que le souci est du coté des serveurs Fibaro. Cette remarque m'amène à te suggérer de vérifier si tu as bien fait toutes les mises à jour de la HC2 après le recovery (qui t'a ramené sur un vieux firmware par défaut)

Oui essaye de contacter le support Fibaro, ce sont les seuls à pouvoir déchiffrer les sauvegardes. Cela dit c'est étrange, les sauvegardes sont chiffrées en prenant en compte le numéro de série de la box, donc si tu fais un recovery, tu peux restaurer sur la même box. Le message d'erreur que tu as donne l'impression que tu as changé de box entre temps. Bref, Fibaro devrait pouvoir te dépanner.

Euh... il fait quoi ce code ? Il "clique" sur un bouton ? Dans ce cas, pourquoi te prendre la tête... alors qu'il suffit d'appeler la fonction qui est appelée elle-même par le bouton, comme d'habitude avec la fonction universelle fibaro.call() fibaro.call(id, "nom_de_la_fonction", eventuels, paramètres, pour, la, fonction) Ou alors je n'ai pas compris la question.

C'est exactement cela, maintenant tu as tout compris Par contre, ce n'était pas un test pour te tester Mais bien un exemple supposé réel. Dans le cas de cette règle, l'intention de l'utilisateur est de déclencher l'action instantanément, au moment précis où la porte s'ouvre, tandis que la température est négative. Cependant, l'effet de bord non attendu, c'est que les actions se déclencheront également à chaque fois que la température varie (ce qui arrive souvent) tandis que la porte est toujours ouverte... pas du tout l'effet attendu. A la réflexion, cet exemple n'était peut être pas le plus pertinent. Mais c'était surtout la logique que je voulais mettre en évidence, et les effets de bords induits qui peuvent être surprenants si on n'a pas saisit l'utilité des parenthèses. C'est un cas que j'ai souvent vu sur le topic du support GEA... déjà à l'époque de la HC2, raison pour laquelle Steven a introduit les parenthèses.

Pour "Program" : Je te suggère de supprimer les 2 lignes suivantes de la syntaxe : {"Program+", <id_module>} {"Program-", <id_module>} Qui sont techniquement possibles, mais n'ont aucun intérêt en pratique... qui aurait le cas d'usage d'aller comparer si le programme n°X est supérieur/inférieur à la valeur Y.... ça n'a juste aucun sens.... ça n'est pas comme comparer une Value (de luminosité, de température, de puissance, etc)

OK, ton retour d'expérience ne m'étonne pas du tout. Sur forum-photovoltaique.fr, un gars avait fait un test pendant plusieurs jours avec et sans le profil zéro-injection, et la différence était énorme. Et quand on y réfléchi c'est logique, la passerelle n'a pas la possibilité de communiquer en temps réel avec les micro-onduleurs pour leur donner au 1/10ème de seconde près la consigne de production / écrêtage. Enphase, par le biais de l'un de ses employés qui officie sur le même forum photovoltaïque, avait confirmé que le profil zéro-injection d'Enphase est extrêmement conservateur, c'est à dire qu'il garantie qu'il y aura réellement zéro injection, quitte à faire l'inverse même, d'où les 10 Watts dont tu parles, qui sont en fait soutirés du réseau (car la meilleure façon de ne pas injecter reste encore... de soutirer.... quel gâchis) Du coup, entre ces 10 W consommés inutilement, et le défaut de réactivité de la communication Envoy / IQ7, font que les pertes de production sont assez importantes.... Il y a quelques pages, je m'insurgeais contre les pratiques de notre distributeur Enedis en France, ça prend tout son sens. Dans le reste de l'Europe et du monde, les règles des différents distributeurs sont assez variables, certains sont plus intelligents, et d'autres encore plus débiles... Là où Enphase est malin, c'est avec le profil 3 kW qui je pense a été développé spécifiquement pour la France, puisque la loi française (et contrairement à ce que prétend Enedis), autorise une injection de 3 kW. Je pense que cela permet de bénéficier du meilleur des 2 mondes : ne pas perdre de production solaire, et ne pas perturber le réseau Enedis. Bref, ma recommandation, c'est de ne pas faire de zéro-injection, c'est crétin pour plein de bonnes raisons techniques et écologiques. Utiliser le profil 3 kW me parait être la solution la plus pertinente. Ou bien le profil par défaut, on injecte tout le surplus, ça permet de bénéficier à tous les citoyens (enfin, les voisins en premier), particulièrement important en cette période de crise énergétique, pénurie, et transition énergétique. Car tout électron produit avec le solaire ne le sera pas avec du gaz, charbon, ou pétrole... c'est toujours ça de gagné.

Ah oui si tu changes le profil uniquement dans les options de l'application ça n'a pas d'effet. Tu as mis lequel du coup ?

ça c'est top le coup du laisser appuyé en complément de l'appui court "normal" Espérons qu'ils ne mettent pas 6 mois à sortir la prochaine version, car ils sont moins rapides pour développer l'app que la box, et c'est rien de le dire...

Lorsque tu cliques sur le bouton "-", au lieu de choisir Z-Wave ou Zigbee dans le popup qui s'ouvre, tu choisis "Autre appareil". Il va alors te mettre sur l'onglet des QuickApps. Mais tu cliques sur l'onglet Tout, Z-Wave, Nice, Elero ou Zigbee et tu pourras supprimer les modules que tu veux avec la corbeille (essayer de supprimer le module parent en 1er me parait préférable, pour cela il faut cocher la case "Voir ce qui est masqué") Exemple avec un FGMS qui n'a plus de pile (nœud mort).... je n'ai pas cliqué en vrai car je vais lui remettre des piles :

Je pense qu'il faut que l'application Toolkit soit connectée à la passerelle Envoy (et pas juste au Wi-Fi de la maison)