Lazer

Normalement, après l'inclusion, la HC3 cache automatiquement ceux qui sont inutiles. Si tu as un doute sur le module enfant à utiliser, c'est simple : tu agis avec les interrupteurs sur le module (ce qui va ouvrir/ferme le volet), et tu constates sur l'interface Web quel est l’icône qui a changé d'état => Alors tu sais que c'est ce module-là que tu dois conserver dans ton interface, et cacher tous les autres (mais encore une fois, normalement par défaut, les autres sont déjà cachés) Il y a une exception, c'est la télécommande, qui est affichée par défaut car elle permet de faire des scénarios simples en mode graphique. Perso je ne m'en sert pas, donc je cache systématiquement le module enfant de cette télécommande. Pour cacher un module, c'est simple, il y a une case à cocher dans les propriétés avancées de chaque module : Si tu ne vois pas les modules cachés, il y a une case à cocher en haut à droite (décochée par défaut) : En complément, on voit le parent et tous ses enfants dans l'onglet Général : Perso j'ai pris pour habitude de nommer le module parent avec la référence du produit, donc FGD-212 dans le cas présent. Sur cette capture d'écran, on voit bien mon module enfant principal qui contrôle la Lumière, puisqu'il s'appelle ainsi. D'ailleurs c'est le seul qui est visible dans l'interface, tous les autres sont cachés (et portent encore leur nom par défaut, je ne les ai pas renommés, pas besoin)

En Z-Wave , chaque module physique peut avoir plusieurs fonctions (endpoint). Et chaque fonction correspond à un module dans l'interface Fibaro : un parent (qui désigne le module physique), et des enfants (qui désignent les différentes fonctions) Normalement la plupart sont cachés dans l'interface car on ne s'en sert pas, de sorte à ne rendre visible que celui est est utile, c'est à dire la commande du volet roulant dans ton exemple. Tu peux renommer tes modules pour qu'ils apparaissent joliment dans le panneau d'énergie : les 53.0, 63.0, etc

Je te conseille d'attendre avant de passer en Z-Wave v3. La prochaine version, pas sûr, ça sera surement bien plus tard. Là c'est du beta, y'a plein de modules qui ne sont pas reconnus sur le nouveau moteur, il leur faudra encore plusieurs mois de travail, comme déjà précisé. La reconfiguration douce des périphériques, c'est pour ceux qui mesurent une puissance électrique, à cause du nouveau mode de calcul de l'énergie électrique de modules.

Bienvenue sur le forum

L'application mobile Fibaro a été renommée récemment et s'appelle maintenant Yubii Home Center : https://play.google.com/store/apps/details?id=com.fibaro.homecenter&hl=fr&gl=US https://apps.apple.com/fr/app/id1421839464 Tu peux faire tous les scénarios que tu veux, donc bien sûr, sur ouverture d'une porte/fenêtre, tu peux déclencher ce que tu veux. De là à en faire une alarme, c'est clairement déconseillé. Il ne faut pas mélanger domotique (confort) et alarme (sécurité). La domotique peut venir compléter une alarme pour ajouter des scénarios originaux renforçant la sécurité (simulation de présence, faire clignoter les lumières en cas d'intrusion, etc), mais la domotique n'est pas suffisament fiable pour jouter le rôle d'une alarme. Les risques, c'est de ne pas détecter une intrusion, ou au contraire, de détecter une intrusion alors qu'il ne se passent rien. Les détecteurs de mouvement, notamment, sons très sensibles en domotique (afin de réagir le plus vite possible dans quelqu'un entre dans la pièce, par exemple pour allumer la lumière). Trop sensibles, si bien qu'un nuage suffit parfois à détecter un mouvement. Et là, tes voisins vont te détester si ta sirène se déclenche pour rien. Et toi, tu vas passer un sale quart d'heure quand ton téléphone va te notifier d'une intrusion qui n'a en fait pas lieu. Bref, c'est un sujet qui a déjà été abordé de très nombreuses fois sur le forum, tu peux te balader et aller lire ce que tu trouves, il y a une section dédiée aux alarmes. Pour les "accessoires", qu'on appelle plus couramment modules, les box Fibaro sont en Z-Wave. C'est un des protocoles majeurs en domotique, tu trouveras de très nombreux modules de diverses marques : Fibaro bien sûr, mais aussi Aeotec, Qubino, etc. Il est possible de tout faire, ton imagination est la seule limite.

Bienvenue sur le forum

Non c'est le premier truc auquel j'ai pensé, mais fait le calcul x1024x1024, tu verras que ça ne correspond pas. La différence est peut-être due à la compression du fichier avant/après, mais ça ferait un bien faible taux de compression du coup, vu la faible différence de taille.

Non j'ai pas essayé DSM7, et je ne risque pas d'y passer de si tôt, voire jamais : - je suis sous Xpenology... donc je sais pas s'ils vont arriver à porter DSM 7 rapidement - l'API de DSM7 semble avoir beaucoup changé, je vois partout que ça casse la compatibilité avec les scripts existants - et... je ne suis jamais copain avec les nouvelles versions majeures, déformation professionnelle, je préfère attendre pour avoir du recul

Grace à toi je viens de découvrir que la HC3 affiche la taille du backup dans la page web... et c'est une nouveauté du dernier firmware. Du coup je n'avais jamais constaté cette différence, forcément, vu que ça n'existait pas avant. Si tu télécharge le fichier depuis l'interface Web, tu verras qu'il est identique à celui sauvegardé sur le NAS par le script. Donc... l'affichage de la taille de la sauvegarde sur la page Web de la HC3 est faux... voilà voilà... Bon ça donne quand même un ordre d'idée, c'est pas si mal.

Sans certitude, mais essaye peut-être avec un autre navigateur.

Je ne sais pas si le support te donnera satisfaction, ils répondent souvent à coté de la plaque, des réponses génériques, etc. Tu devrais profiter que l'équipe de dev est active sur le forum en moment pour décrire ton problème directement là bas : https://forum.fibaro.com/forum/1279-update-5080/

@juch11111 J'ai regardé ton fichier de log, le comportement de ton aspirateur est très étrange, il ne répond pas comme attendu. Rassures moi, tu n'as pas mis à jour que le fichier main, tu as aussi mis à jour le fichier Xiaomi en version 1.01 ? Parce que j'ai pas franchement l'impression.... Si oui, alors dans le fichier main, est-ce que peux essayer de commenter le paragraphe suivant entre les lignes 258 et 265, en ajoutant des balises de commentaires comme suit : --[[ Xiaomi:getFeatures({ success = function(result) tools:print("gray", "Vacuum features :", tools:tostring(result, true, true)) end, error = function(response) tools:error(response.message) end, }) --]] Puis tu relances le test, et tu captures les logs.

Ah dommage

Euh, dès fois que le journal des nouveautés ne soit pas clair : Le nouveau moteur Z-Wave v3 n'est pas une mise à jour. Le nouveau moteur Z-Wave v3 n'est accessible qu'après une réinitialisation complète de la box, et après avoir spécifiquement choisi le moteur Z-Wave v3 lors de l'assistant de démarrage (sachant que le moteur v2 reste celui sélectionné par défaut) Quoi qu'il en soit, même pour ceux qui font le choix de faire une nouvelle installation avec ce nouveau moteur Z-Wave v3, cela reste une première version qui n'est pas exempte de bugs... à réserver aux plateformes de tests, et éviter la production. Pour les systèmes existants, la migration du moteur v2 vers le moteur v3 sera proposé ultérieurement par Fibaro.... d'ici l'automne environ (plus ou moins un certain retard) Bref, vous pouvez faire cette mise à jour 5.080.9 sans crainte (mais on n'est jamais à l'abri d'un bug quelconque).

C'est beau quand même Node RED. Mais je me vois pas gérer 200 règles en mode graphique.... je suis surement déformé (mode Unixien), mais je trouve tellement plus facile de gérer 200 règles GEA en mode texte dans mon éditeur favori...

Oui le Swagger, très pratique ça y est, la tempête de goutes d'eau est arrivée, la HC3 est donc en avance sur son temps

Si ça freeze, tu as tout autant de chance que l'API freeze également, comme le QA. Donc ça ne changera rien. Et que ça freeze n'est pas un souci, puisque tu mesures le delta justement. L’intervalle de temps sera allongé, et c'est tout. Mais tu mesureras bien la surconsommation CPU liée au freeze. Reste le bon point de l'application externe qui passe par l'API : détecter et noter l'heure du freeze. Sinon tu sais qu'en 10 minutes tu pourrais mettre en place DomoCharts sur un NAS et avoir la courbe CPU

En monitoring système, ça n'a pas de sens de regarder à un instant T, parce qu'une ça dure une microseconde, donc tu rates ce qui se passe pendant les 99,99999999999% du temps restant qu'il s'est écoulé depuis la dernière fois que tu as regardé. Ce que tu donnes l'API, ce sont les métriques systèmes au niveau de l'OS (noyau Linux). Pour simplifier, il compte le temps passé dans chaque "tâche" Sachant que idle est un cas particulier, c'est le temps passé à ne rien faire Et il faut soustraire la valeur précédente afin de calcul le delta CPU consommé De cette façon, tu ne "rates" pas ce qui s'est passé entre 2 périodes de monitoring. Enfin, c'est vite dit, parce que si tu regardes 1 fois toutes les 10 secondes, mais que le CPU a bossé 1s à 100% et le reste à 0, toi tu auras l'impression qu'il a bossé à 10% en moyenne pendant les 10s. Mais au moins, tu auras vu ces 10%, c'est toujours mieux que 0. Au fait, attention, le calcul est à faire pour tous les cœurs du CPU de la box (4 sur HC3, 2 sur HC3L), il faut donc faire une petite boucle. Regarde le code de mon QA DomoCharts, dont voici un extrait : local diagnostics = api.get("/diagnostics") local nbCPUs = #diagnostics.cpuLoad if not self.cpuLoad then self.cpuLoad = {} end local cpuAverage = 0 -- Parse cores for i = 1, nbCPUs do local cpuNew = diagnostics.cpuLoad[i] local cpuName = cpuNew.name local cpuOld = self.cpuLoad[cpuName] if cpuOld then local cpuTotalOld = (cpuOld.user + cpuOld.nice + cpuOld.system + cpuOld.idle) local cpuTotalNew = (cpuNew.user + cpuNew.nice + cpuNew.system + cpuNew.idle) local cpuPercentage = tools:round(((cpuTotalNew - cpuTotalOld) - (cpuNew.idle - cpuOld.idle)) / (cpuTotalNew - cpuTotalOld) * 100, 2) cpuAverage = cpuAverage + cpuPercentage print("Core #" .. i .. " " .. cpuName .. " = " .. cpuPercentage .. "%") end -- Memorize values self.cpuLoad[cpuName] = { user = cpuNew.user, nice = cpuNew.nice, system = cpuNew.system, idle = cpuNew.idle, } end print("Usage CPU moyen sur la période : " .. (cpuAverage / nbCPUs))

Cool Les 2 raisons... je pense que la syntaxe abrégée devait fonctionner il y a bien longtemps, et qu'elle a dû cesser de fonctionner à un moment donné dans mes différentes modifications pour HC3. J'ai regardé dans les règles que j'ai testé, je n'ai jamais testé cette syntaxe abrégée, uniquement la version longue avec WeatherCondition explicitement déclaré. Je regarderai si je peux patcher GEA pour rétablir le fonctionnement raccourci de cette règle, comme avant. Et mettre la doc à jour aussi du coup. Au fait, pour voir la condition actuelle de la météo, il faut passer par l'API de la box : /api/weather On y voit clairement toutes les propriétés exploitables avec "Weather" : (pour la précision, on repassera, il fait soleil en ce moment.... mais bon c'est du Cloud (sans jeu de mot), donc pas précis, peut être qu'il pleut effectivement de l'autre coté de Paris.

J'ai fait le déplacement (il y avait aussi les messages de Dragoniacs du coup) Tu peux essayer avec la syntaxe suivante (avec "WeatherCondition") : {"Weather", "WeatherCondition", "xxx"} Ce qui devrait donner un truc du genre (tu es sûr pour la valeur "dégagé" ?) GEA.add({id["OEIL_SAURON_CUISINE"], {"(Weather)", "WeatherCondition", "dégagé"}, {"(Time)","06:00","22:00"}}, -1, "", {"Color", 153, 255, 206, 51, 0}) Je soupçonne la syntaxe abrégée d'être buggée dans cette version de GEA (et vu que je ne l'ai jamais utilisé, ça fait peut être longtemps)

Rien ne se passe ? Alors là c'est curieux, car cette règle devrait se déclencher sur détection de mouvement, c'est ultra basique. Juste une remarque, tu es sûr de son ID ? Que dis le log au démarrage de GEA avec cette règle ? Si tu as bien la dernière version ? Qui affiche en couleur les déclencheurs instantanés au démarrage Mais... mais... mais .... je viens de voir que tu as posté sur le topic de GEA pour HC2... tu parles de quoi en fait ??

Extrait de la doc : --> Il est possible d'exclure une option des déclenchements instantanés à l'aide des parenthèses : -- Syntaxe : GEA.add({ {CONDITION1}, {(CONDITION2)} }, -1, "", {ACTIONS} ) -- Seule la CONDITION 1 sera utilisée en comme déclencheur de la ligne \\ Only condition number 1 will trigger the line -- Exemple : -- Ceci sans exclusion : GEA.add ({{"Global", "JohhnyHome", "1"}, {"Global", "TimeOfDay", "Night"}}, -1, "", {"QuickApp", QA["TTS"], "1"}) -->> La ligne se déclenche lorsque : -- 1- "JohhnyHome" passe à 1 -- 2- "JohhnyHome" est déjà à 1 ET lors du passage de la variable "TimeOfDay" passe à "Night" -- Ceci avec exclusion : GEA.add ({{"Global", "JohhnyHome", "1"}, {"(Global)", "TimeOfDay", "Night"}}, -1, "", {"QuickApp", QA["TTS"], "1"}) -->> La ligne se déclenche UNIQUEMENT lorsque : -- "JohhnyHome" passe à 1 ET que la variable "TimeOfDay" est égal à "Night" Dans ton cas ça ne change rien puisque tu veux le déclenchement instantané sur Weather et la Value du module, mais tu devrais mettre le Time entre parenthèses, car tu vas avoir de drôle de surprise si une prochaine version de GEA permet de réaliser des déclencheurs instantanés sur le Time (ce qui permettrait de faire de GEA un Scheduler....) Il faut prendre les bonnes habitudes dès le début. Remarque : le seul déclencheur pertinent est le détecteur de mouvement. Le déclenchent sur la condition Weather est peu utile à mon avis (il faudrait que la météo change pile pendant les quelques secondes où le détecteur est en alarme... peu de chances) Merci pour le log détaillé, mais bon... j'aurais aimé que tu isoles la règle... car le log est bavard, et avec les autres règles, c'est franchement pas simple à analyser.... Par ailleurs l'en tête de démarrage de GEA aurait été utile aussi, pour voir s'il prend bien en compte tes 2 déclencheurs. En tout cas je vois que le déclenchement instantané sur le détecteur de mouvement de la cuisine a bien lieu, c'est déjà bon signe.

Je n'ai pas vérifié les formules de @mprinfo, mais attention, il faut calculer le delta en faisant la soustraction avec les valeurs précédentes... ce qui implique que ton QA doit mémoriser les valeurs à chaque passage de boucle.

Tu peux regarder la méthode de calcul dans les QA suivants :

OK, mais du coup tu n'as pas répondu à mes questions. Je suis surpris par ta syntaxe, tu as 3 déclencheurs instantanés (= pas de parenthèse). Bon même si "Time" ne peut pas être utilisé en déclencheur instantané, ça en laisse quand même 2 : le changement de météo, et le mouvement. Tu es certain que c'est bien ce que tu veux ? Ensuite, quand tu dis que ça ne fonctionne pas, il faudrait que tu isoles la règle dans une instance GEA dédiée, et que tu actives GEA.debug=true et GEA;lldebug=true comme je le demande toujours, puis tu nous partages les logs pour voir ce qui se passe. Sans log, je ne peux pas deviner le problème.