Lazer

Des logs peut être ? Depuis le dernier firmware, le panneau d'événements remonte beaucoup plus d'informations. S'ils n'ont pas adapté la politique de purge automatique, ça pourrait expliquer la croissance de la DB. En espérant que ça ne soit pas un autre souci plus grave. Mais oui, il faut demander au support.

Toi t'es encore à l'apéro https://www.domotique-fibaro.fr/forum/98-thermoflor-heatit/

Bienvenue sur le forum

Voilà c'est fait

Bon le topic Piloter L'enregistrement Des Caméras Avec Synology Surveillance Station est de retour : Pas évitent à restaurer... je l'ai retrouvé dans un vieux backup du février 2020 et j'ai tout fait à la main.... Faut que je fasse Surveillance Station Manager maintenant....

email : support@fibaro.com

hum, tu aurais eu une corruption de ta DB alors, qui l'aurait fait gonfler ? Tu devrais peut-être demander au support de se connecter et jeter un oeil

Tu fais le code que tu veux.... Moi je reprendrais leur code, et je l'améliorerai (virer ce qui est inutile, et optimiser les instructions trop lentes) Après tu as le choix, soit tu surcharges fibaro.getDeviceID() (suffit d'appeler ta fonction pareil), ou alors te créer une autre fonction dans ton toolbox (très pratique en plus maintenant avec les fichiers dans les Quickapps)

Regarde mon post au dessus, et surtout la fin, j'ai édité entre-temps. Moi je referais le code complet, je suis certain que tu peux gagner en performance.

Voici le code de la fonction fibaro.getDevicesId() sur HC2 pour mieux comprendre ce qui se passe à l'intérieur : fibaro.getDevicesId = function(self, filter) if type(filter) ~= 'table' or (type(filter) == 'table' and next(filter) == nil) then return fibaro:getIds(fibaro:getAllDeviceIds()) end local args = '/?' for c, d in pairs(filter) do if c == 'properties' and d ~= nil and type(d) == 'table' then for a, b in pairs(d) do if b == "nil" then args = args .. 'property=' .. tostring(a) .. '&' else args = args .. 'property=[' .. tostring(a) .. ',' .. tostring(b) .. ']&' end end elseif c == 'interfaces' and d ~= nil and type(d) == 'table' then for a, b in pairs(d) do args = args .. 'interface=' .. tostring(b) .. '&' end else args = args .. tostring(c) .. "=" .. tostring(d) .. '&' end end args = string.sub(args, 1, -2) return fibaro:getIds(api.get('/devices' .. args)) end et fibaro.getIds() dont elle dépend : fibaro.getIds = function(self, devices) local ids = {} for _, a in pairs(devices) do if a ~= nil and type(a) == 'table' and a['id'] ~= nil and a['id'] > 3 then table.insert(ids, a['id']) end end return ids end Ainsi que fibaro.getAllDeviceIds() : fibaro.getAllDeviceIds = function(self) return api.get('/devices/') end Leur code n'est pas vraiment optimisé car de toute façon il récupère bien le JSON complet des devices. Je serais toi, j'utiliserais api.get() et je recoderais fibaro.getIds() directement dans mon code, ça ira plus vite Avec quelques optimisations comme virer ce table.insert() monstrueux (comme discuté sur un autre topic, c'est l'une des instructions les plus lentes en LUA) cf : https://springrts.com/wiki/Lua_Performance#TEST_12:_Adding_Table_Items_.28table.insert_vs._.5B_.5D.29

Remarque, dans ce cas précis pour filtrer les lumières, il serait plus rapide d'utiliser le filtre suivant qui donne le même résultat, mais plus simplement : /api/devices?property=isLight

Tiens, c'est cadeau /api/devices?property=[categories,["lights"]] Donc on peut descendre assez profondément dans le filtre. Je te laisse convertir ça à la sauce getDeviceID()

J'ai fait ça dans l'après-midi quand j'étais seul à la maison, donc réseau Z-Wave calme, peu de trames qui passent.

J'ai fait la mise à jour de 3 modules (1 FGS-213 et 2 FGS-223) c'est passé super rapidement pour les 2 premiers, et plus lentement pour le dernier qui est physiquement éloigné au garage.

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