Lazer

@jjacques68 je n'y connais pas plus que toi non plus en /api/devices, car ce n'est pas documenté par Fibaro, donc il faut tâtonner pour trouver les filtres utilisables. Comme dit mprinfo, tu peux créer un topic regroupant les filtres qui fonctionnent qu'on complètera dans le temps

@mprinfo tapatalk, comme par hasard... source de tous les maux.... @moicphil je vais chercher dans de vieilles sauvegardes de la DB... il va falloir que je me tartine ça à la main

Bienvenue sur le forum

Merci @q.philippe alors les nouveaux possesseurs de HC3, quelques numéros de série récents à partager ?

Mais là ton filtre n'est pas sur l'API /devices, mais /devicenotifications, je ne pense pas que ça fonctionne

On peut filtrer pas mal de choses, exemples en stock : /api/devices?visible=true returns devices with visible equal to 'true' /api/devices?property=[batteryLevel,100] returns devices with property batteryLevel equal to 100 /api/devices?property=[unit,%CE%BCg/m3] returns devices with unit equal to µg/m3 /api/devices?interface=light returns devices with light interface /api/devices?type=com.fibaro.netatmoWeatherStation returns Netatmo Weather Station /api/devices?baseType=com.fibaro.weather returns Weather plugins /api/devices/?property=isLight /api/devices?interface=zwave&parentId=1

Autre chose, au point où tu en es, il faut aussi que tu optimises tes boucles for Quand on a de grosses boucles récurrentes, il faut proscrire pairs et ipairs qui sont très lents. De même que certaines instructions sur les tableaux comme table.insert() Une saine lecture de référence pour optimiser son code : https://springrts.com/wiki/Lua_Performance#TEST_9:_for-loops Remarque : ça n'empêche pas d'optimiser son code en amont, revoir l’algorithme global du script est plus pertinent que ces optimisations atomiques.... comme je te dis, filtre mieux tes devices

Pas besoin de tempo, moi je fais tous mes settimout avec une valeur de 0, ça s'enchaine hyper vite. Ralentir la vitesse... en théorie oui, en pratique je ne sais pas si c'est sensible. Mais surtout si ça évite le crash, y'a pas trop de question à se poser Cela dit, ta double boucle imbriquée, je suis quand même surpris qu'elle dire si longtemps.... tu devrais benchmarker chaque instruction, il doit y avoir un endroit où ça coince, c'est pas normal que ça dure longtemps (d'ailleurs, de combien de temps on parle ?) Je me demande si ton problème ne serait pas ailleurs.... En effet, tu charges la liste de TOUS les devices, ce qui produit un tableau très gros en RAM. Et j'ai constaté dans mes tests de saturation mémoire, que la charge CPU augmente considérablement lorsqu'un QA alloue des trop gros tableaux. Genre comme si la box passait plus de temps à "chercher" de la RAM qu'à faire tourner le code pour utiliser le contenu de la RAM allouée. N'oublions pas qu'en LUA (comme Java, et pleins d'autres langages évolués) il y a un Garbage Collector qui tourne "quand il a le temps" pour libérer la RAM allouée. Sauf que ça prend du CPU.... Donc j'en reviens à ce que je disais précédemment, il vaut mieux utiliser de petits tableaux, mieux filtrer ton api.get pour récupérer une liste de device la plus restreinte possible.

@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.