Lazer

@jjacques68 Mais dans les visibles, tu as les Z-Wave, les QuickApps, leurs enfants, etc.... t'as vraiment besoin de parcourir tout ça ? La manière d'optimiser le code est une chose en effet. Mais je constate que tu n'as pas du tout la même façon d'utiliser ta box que beaucoup d'entre nous. Outre ce QuickApp qui parcoure tous les devices, je sais que tu récupères aussi tous les événements pour les envoyer sur une base de données externe.... bref ça plus ça plus ça, etc.... ça commence à faire beaucoup de code bien lourd, qui charge beaucoup la box

Oui donc normal en fait, on en avait déjà parlé il me semble, les Quickapps DOIVENT rendre la main au système régulièrement. Là ton code est totalement séquentiel, il n'y a aucun settimout ou autre fonction asynchrone pour rendre la main, donc la HC3 n'aime pas. Je ne sais pas trop ce que fait ton code, mais je te suggère : - limiter tes 2 boucles imbriquées, notamment la première, est-ce bien judicieux de parcourir la liste de tous les devices, ce peux-tu pas filtre un peu mieux ? - sinon, faire un algo récursif, qui appelle une fonction en asynchrone (via settimeout) pour rendre la main au système régulièrement. Parcourir la liste de tous les devices, c'est vraiment bourrin.... même dans Domocharts je filtre au maximum à la source (au moment de l'api.get) pour n'avoir que les températures, puis une autre boucle pour n'avoir que les humidités, etc.... mais je ne parcoure pas un device "pour rien" Ça tourne toutes les 60 secondes, et comme tu le vois sur mes graphs présentés, aucune surcharge de la box.

Faut pas t'étonner qu'elle plante ta box, si tu mets le doigt dedans En tout cas c'est cool d'avoir trouvé origine de ton problème

Je suis vraiment très content qu'ils ajoutent cette fonctionnalité à tous les nouveaux modules, pour prolonger la durée de vie des relais Synchronization of switching in zero-cross - reducing the possibility of welded relay contacts.  Cela dit je pensais que c'était déjà le cas sur cette génération de modules.... donc ils ont encore fait du Fibaro, à savoir des annonces en grande pompe, mais une fonctionnalité très en retard !!

Le changelog, c'est utile 3.4 Fixed inputs issue when bistable switches are used. Synchronization of switching in zero-cross - reducing the possibility of welded relay contacts.  SDK updated to 6.51.07.

C'est possible oui, même si je n'en vois pas l'intérêt. Pour moi ce script sert à externaliser les backups en cas de crash violent de la HC3. Pour le problème qui te concerne, en cas de firmware buggé nécessitant un retour arrière, tu t'en rends compte tout de suite, il suffit de restaurer le dernier backup cloud effectué par la box juste avant la mise à jour, ou bien l'un des 3 derniers backups locaux stockés sur la HC3. Je ne vois pas bien dans quelle situation on pourrait nécessiter de revenir en arrière plusieurs semaines/mois après ?!? Pour tout dire, ça m'est arrivé une fois avec la HC2, j'ai dû retourner en arrière 3 semaines, non pas à cause d'un firmware, mais à cause d'une corruption de la base de données des modules Z-Wave. Du coup, le firmware n'avait aucune importance. Je vais essayer de faire ça, mais pas tout de suite.... pas trop le temps en ce moment.

Je suis d'accord avec Nico Le mieux c'était la cheminée, un pull-over, et se relever toutes les 1/2h pour remettre une buche quand le pull-over ne suffit plus. C'était mieux avant comme diraient certains.... Pfff, on ne se rend pas compte de la chance qu'on a avec nos petits problèmes esthétiques

Par contre, le "used space", d'une valeur de 49% avant reboot dans l'exemple de @jjacques68 doit se stabiliser et le graph doit présenter une tendance asymptotique, comme sur mon graph présenté en page précédente. Après reboot, dans les heures qui suivent, il augmente vite, c'est normal, mais doit rapidement se stabiliser comme dit à la phrase précédente. Si le used space ne cesse de croître sans arrêt, comme se fut le cas lors des premiers firmware v4 de la HC2 (c'est à dire pendant 2 ans....) , alors c'est qu'il y a une fuite mémoire, c'est à dire des process qui allouent de la mémoire, sans jamais la libérer. Si on laisse courir, alors on va au crash.... avec reboot forcé obligatoire. Dans les pires cas, il n'est pas possible de rebooter autrement que par un arrêt électrique. A noter qu'avec la HC3, je l'avais déjà signalé, il est très facile pour un QuickApp mal développé (c'est donc 100% notre faute, pas celle de Fibaro) d'allouer de la mémoire jusqu'à saturation. Il suffit de mettre des données dans une variables, par exemple un tableau qui ne cesse de croitre. Donc méfiance dans vos codes LUA.

Le cache qui augmente ? C'est tout à fait normal. Un système UNIX/Linux optimisé doit toujours tendre vers un espace libre de 0% (en pratique un peu plus, il faut garder 1 à 5% de "mou") Et je dis bien "doit". Si la RAM n'est pas totalement utilisée, c'est que le système ne parvient pas, pour une raison ou une autre, à mettre suffisament de données en cache. Pour rappel, le cache est là pour accélérer les performances. Le cache, c'est ce qui permet de conserver en RAM une information, pour éviter d'aller la relire plus tard sur le support de stockage non volatile (toujours plus lent... que ça soit une bande, un disque dur, un SSD, ou même un SCM (Storage Class Memory = la prochaine révolution), c'est toujours très largement plus lent que la RAM) On trouve du cache partout, dans les disques durs, dans les processeurs (il y a même 3 niveaux de cache), etc Bien sûr au niveau du processeur même, ce sont des caches très largement plus rapide que la RAM elle-même.

Rappel, tu n'es monté qu'à 55% (49+6) Donc tu avais encore beaucoup de marge C'est incroyable que Fibaro n'ait toujours pas compris qu'il ne faut pas comptabiliser le cache sous Linux, ça ne fait qu'apeurer les gens pour rien....

buvez un verre une bouteille de Vodka

Oui il y a déjà un sujet (et mêmes plusieurs) pour ces sujets. Revenons en à ce module, pour l'aspect esthétique, ce qui me gêne le plus c'est la demi boule du capteur PIR, que je trouve vraiment disgracieux avec ses petites facettes polygonales qui attirent le regard. On dirait les vieux détecteurs de mouvements des alarmes du siècle précédent. Mais difficile de juger sur une photo, j'attends de l'avoir en main pour me rendre compte. De toute façon il est destiné à être installé dans mon bureau, donc ça ne gênera pas grand mode (et moi je serai heureux de voir plein de mesures sans lever mon popotin de mon fauteuil )

Dans ton navigateur, tu saisis http:// avec l'adresse IP de ta box Si tu ne la connais pas, il faut regarder le bail DHCP qui lui a été attribué sur ton routeur (box Internet), ou encore plus simple, utiliser l'outil "Fibaro Finder" disponible sur le site de Fibaro. Via le cloud, l'interface est plus lente, et il y a plusieurs actions que tu ne pourras pas faire (mise à jour, import d’icônes, etc..)

Tu es bien connecté en local sur l'adresse IP de ta box, et non via le cloud Fibaro ?

Moi c'est l'inverse, j'adore les informations/statistiques/nombres en tout genre C'est pas pour rien que j'historise tout avec Domocharts. Madame s'en fout, c'est elle qui laisse trainer le bordel dans la maison, alors elle va pas me faire une remarque pour un petit truc accroché au mur, à part la traditionnelle remarque "encore un truc qui sert à rien" (mais que dire de ses chaussures ) Mais comme je disais, l'apparence, ça ne se discute pas trop (enfin si, le ST814 on est tous d'accord pour dire qu'il est hideux), ça plait ou ça plait pas Mais à la base je rebondissais sur la comparaison avec le X-Display et la revente de la maison... usine à gaz versus module autonome. Sinon tu sais que tu peux éteindre les diodes des Motion Sensor ? C'est plus efficace que de se laisser dire que c'est moche.... Perso je les ai laissé s'allumer, mais à la luminosité minimum, si bien que moi que les vois s'allumer quand je les regarde (juste pour la satisfaction de les voir fonctionner), mais personne ne le remarque tellement c'est discret.

Le Nest oui, mais le Netarmo justement je l'ai toujours aussi trouvé mastoque. Mais ça ne plaira pas aux fans du design épuré, c'est certain.

C'est surtout le capteur de PM2.5 qui nécessite beaucoup d'espace, il y a tout un circuit d'air avec une ventilation forcée. Après quand on voit les thermostats super à la mode, Netarmo et Nest, c'est tout aussi épais, et pourtant ça je choque personne il me semble.

Je suis d'accord...

Euh non, c'est carrément tout l'inverse en fait. le Xdisplau dépend d'un IPX800 et ses capteurs, c'est complexe à supporter. Et ça ne mesure que temp hum lum, le basique. C'est pas comparable à ce capteur , qui mesure pleins de paramètres de la qualité de l'air uniques en domotique, et est surtout 100% autonome avec son écran, il fonctionne sans box domotique. Même mieux qu'une Netarmo qui n'a pas d'écran et dépend du cloud Après les goûts et les couleurs, ça ne se discute pas

Now you can...

J'ai mis la doc PDF complète en premier post au fait Avec les paramètres Z-Wave et tout et tout.

Non voilà, dans la notice ils ne donnent que C02 ou PM2.5 en principal. Ce module est vendu comme un moniteur de qualité de l'air.... donc la température est accessoire. Dommage tout de même, j'aurais aussi préféré la température, c'est à mon avis le principal critère de bien être dans une pièce.

Bienvenue sur le forum

"Main" en anglais, ça veut dire principal C'est donc juste le choix du paramètre principal, celui qui s'affiche en grand. Mais comme l'a remarqué Nico, l'écran affiche bien le CO2 et les PM 2.5 simultanément (comme tout le reste)

C'est toujours le cas, c'est bien pour ça que mon écran principal est un 32" pile au centre du bureau, bien en face du clavier. Le 24" est accessoire (et dire que la plupart des entreprises ne sont déjà pas capables de filer un 24" à leurs salariés comme écran principal...) et sur le coté, je l'allume rarement. Il me sert pour des besoins ponctuels, quand j'ai besoin de toute la surface d'affichage du 32' mais que je dois afficher quelque chose à coté. Pour le cas qui nous concerne ici, le 24" ne sert qu'à afficher la fenêtre de logs de la HC3, je travaille le code sur l'écran principal.