Lazer

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.

D'après les messages, tu as des tables de ta base SQL qui sont corrompues. Tu as eu une coupure de courant, ou un reboot violent de ton NAS ? Je n'ai jamais eu ce genre de problème.... il va falloir que tu utilises phpMyAdmin pour aller voir l'état des tables en question, les réparer, voire les supprimer puis les recréer.

Je ne me moque pas, j'essaye d'expliquer Sur Amazon, il semble y avoir pas mal de modèles, à pas cher (de conception sino-chinoise, et de fabrication du même niveau, à la durée de vie au moins aussi réduite que l'alimentation d'origine) : https://www.amazon.fr/s?k=alimentation+12V+4A&__mk_fr_FR=ÅMÅŽÕÑ&ref=nb_sb_noss_2 Faut juste faire attention à l'embout DC 5.5 mm (diamètre extérieur). Je ne sais plus si la HC2 utilise un embout intérieur 2.1 ou 2.5mm. Je suis quasi sûr que c'est l'alimentation qui est bonne à changer. La box fait automatiquement des sauvegardes cloud à chaque mise à jour de firmware, donc tu as au moins ceux-là, mais ils elles ne sont peut être par récentes.

Je t'avais bien dit qu'il fallait une puissance au moins aussi importante. 2A x 12V, ça fait 24W, donc oui c'est clairement insuffisant pour la phase de boot qui doit consommer plus (même en pointe pendant seulement quelques secondes) Tu sembles confondre les notions de tensions, de courant, et de puissance (et non, le "voltage" ça n'existe pas en français) Si tu regardes sur ce topic, tu devrais pouvoir identifier ta carte mère : Si tu as l'un de celles qui sont connues (de conception Intel), elles sont conçues pour fonctionner avec une tension entre 8V et 19V, ce qui est plutôt large. Mais bon, les alimentations standards, c'est du 12V, et après ça saute à 24V, ce qui est trop important, là tu vas griller la carte mère à coup sûr. Donc reste sur du 12V. Ensuite, le courant, en ampères donc, doit être de 4A ou plus. Ce n'est pas le courant qui va traverser la box, mais le courant max qu'elle va appeler, donc que doit pouvoir fournir l'alimentation. Si tu prends une alimentation avec un courant supérieur (5A.... 10A soyons fou), c'est encore mieux. Pour info, 10A, en 12V, ça fait 120W, évidemment que la box ne consommera jamais tout ça, mais au moins tu es certain que l'alimentation ne va pas griller. Donc c'est très facile de trouver une alim avec les bons critères : tension de 12V, et courant aussi important que tu veux, tant qu'il est supérieur ou égal à 4A. L'alim de ton PC portable, 19V, devrait théoriquement être compatible avec la carte mère.... mais vérifie quand même avec un voltmètre qu'elle ne dépasse pas les 19V, ça serait bête de griller la carte mère.

Pour les énergies, il faut taper dans la table domocharts_energy_day, et prendre simplement la colonne sum_value (en kWh) : Après si vous voulez aller plus en détail, les autres colonnes permettent d'isoler les consommations en HC, HP, etc. PS : sur mon screenshot j'ai un bug, avec un device qui rapporte une consommation négative... ça serait trop beau pour être vrai... c'est juste un problème de reporting des prises Greenwave sur la HC3

Tu peux le voir depuis l'onglet des sauvegarde de la box.... mais vu qu'elle est en panne, je ne crois pas qu'on puisse le voir depuis le site de Fibaro. C'est stocké sur leurs serveurs.