Lazer

Non pas du tout

C'est l'hôpital qui se fout de la charité

Et bien voilà, bel exemple, tu as réussi à t’embrouiller à cause de getDevicesID() et ses accolades Je t'avais donné des exemples sur l'autre topic, les revoici, pour t'inspirer de la syntaxe, donc avec des crochets dans ton cas : /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

Le souci c'est que tu utilises getDevicesID () et non pas api.get() qui elle, utilise bien la même syntaxe Tu devrais déjà utiliser la "vraie" API officielle(*), et ensuite quand ton filtre fonctionnera, t'attaquer à la conversion en langage accepté par getDevicesID, ça me semblerait plus cohérent comme démarche (*) même si elle n'a d'officielle que le nom, tellement est la mal documentée

Déjà pour tester tu pourrais mettre uniquement l'URL de l'API dans ton navigateur, plutôt que de passer par le code LUA En plus ça faciliterait la lecture, parce que là, "listeDevice = fibaro.getDevicesID(...." je suis désolé mais c'est inutile et illisible en l'état. Exemple : /api/devices?interface=quickApp Là c'est clair, et on peut directement l'utiliser dans un navigateur ou dans un code LUA avec api.get() Enfin ce n'est que mon avis...

Oui mprinfo a bien résumé et ce genre de discussion n'a rien à faire dans la section pour les nuls, car déjà c'est un sujet avancé, et c'est un topic de travail amené à évoluer. Ça a été déplacé par un modérateur, je vois que c'est dans Support HC3, je ne sais pas si c'est le meilleur endroit, mais y'a pas trop d'endroit idéal pour ce genre de sujet.

Mon exemple parcoure un tableau. Pour chaque élément de ce tableau, si on trouve un sous-élement qui est lui-même de type tableau, alors on appelle à nouveau la fonction pour parcourir l'intérieur. Et ainsi de suite. Là tu as la récursivité. Si par exemple le tableau contient 10 sous-tableaux imbriqués, alors on aura jusqu'à 10 appels récursifs enchainés. Je suis sûr que sur Internet tu trouveras plein d'exemples pratique de récursivité. Cela dit on a dévié de la discussion initiale, la récursivité ne répond pas vraiment à ta problématique.

Ah oui elle ne doit pas aimer Changement de firmware, changement de mode de fonctionnement interne, et avec un code borderline, c'est le crash assuré !! oui... mais non pas vraimeent car comme dit dans un post précédent, à partir du moment où tu es asynchrone, ce n'est plus vraiment de la récursivité, car tu ne récupères jamais le code de retour de la fonction quand ta nouvelle fonction MaFonction() s'exécute, la précédente est en réalité déjà terminée depuis longtemps. Un vrai algo récursif, ce n'est pas ça. La fonction peut s’appeler elle-même plusieurs fois de façon imbriquée on utilise souvent pour traiter des données, et les découper par tranche, une sorte de dichotomie de plus en plus fine Tu as un vrai code récursif ici, avec la fonction browse() : Note que ça peut être dangereux un code récursif, car tu peux partir dans une boucle d'appel infini de fonction, et ne jamais en sortir. Ça fini toujours en crash (saturation mémoire) Tu as vu Inception ? Bah c'est exactement ça

Une remarque sur la boucle infinie et le sleep() qui ne rend jamais la main. Supposons le code suivant : while true do print("Hello") sleep(60*1000) end Il ne fait donc rien 99,999999999999 du temps (approximativement :D ) et affiche une ligne chaque minute. Pourtant, comme il est synchrone et ne rend jamais la main, il empêche les autres événements sur le QuickApp. Par exemples : clic sur un bouton, mise à jour de sa valeur, etc.... Donc la HC3 va considérer qu'il est planté car il ne fonctionne pas comme attendu.... et l'utilisateur s'en rendra vite compte s'il ne se produit rien quand il tente d’interagir avec le QA

non pas besoin, c'était bien l'asynchronisme qui a amélioré le fonctionnement de ton script. Car la HC3 attend des QuickApps qu'ils rendent la main régulièrement. Si un QuickApp part dans une boucle infinie (comme on le faisait avec les Main Loops des VD), alors la HC3 peut considérer la QA comme planté... Note qu'un sleep() ne rend pas la main au système, c'est bien le setTimeout() qu'il faut. Mais le setTimeout ne provoque pas une pause dans un code linéaire, il provoque l'appel d'une nouvelle fonction, il faut donc structurer son code différemment. L'utilisation des fonctions HTTPClient:request() également, ou plus exactement l'appel des fonctions success() ou error() en retour Et bien sûr, on peut combiner asynchronisme et récursivité Mais ce n'est plus de la vraie récursivité dans ce cas, car dans une algo récursif traditionnel, on attend la valeur de retour de la fonction apellée.... tandis qu'en asynchrone, on ne récupère jamais la valeur de retour de la fonction appelée, puisqu'elle s'exécute après le déroulement du code en cours Pas simple.... je ne sais pas si c'est clair.

Non, tu confonds 3 notions : - récursivité = une fonction qui s'appelle elle-même => parfaitement réalisable sur HC2 et HC3 - multi-thread = plusieurs instances d'un même code qui s'exécutent simultanément (très difficile à gérer dès lors les différents threads manipulent la même donnée) => impossible sur HC2 et HC3, les QuickApps sont mono-threadés. Sur HC2 les Scènes pouvaient avoir plusieurs instances simultanément, mais ce n'était pas du multi-thread pour autant, car c'était autant de process indépendants (on appelle cela un fork... Les différents processus s'exécutent indépendamment et ne partagent pas les mêmes données) - asynchronisme : le lancement d'une fonction s’exécute "plus tard", dès la fin du code en cours d'exécution (cas du settimout(0...)), ou bien plus tard (settimeout(xxx, ..)), possible sur les scènes depuis la HC2, et sur les QuickApps depuis la HC3

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