jjacques68

ben j'essaye de faire ça avec api.get() : /api/devices?property={category="lights"}}} retour : rien

pas bête, mais y a des subtilité entre l'URL et la fonction : "properties" devient "property" "interfaces" devient "interface" ils ont tout mis au singulier on dirait... Ducoup je suis resté sur les fonctions pour avoir le même "texte" que ce que l'on voit dans le JSON !

oui j'ai vu, ben on va voir ce que ça donne... J'y ai déjà posé une colle

question : comment fait-on pour filtrer sur cette rubrique "categories", qui est un tableau : j'ai essayé sans succès : ListeDevice = fibaro.getDevicesID({properties={categories={"lights"}}}) ListeDevice = fibaro.getDevicesID({properties={categories,"lights"}}) ListeDevice = fibaro.getDevicesID({properties={categories="lights"}}) ListeDevice = fibaro.getDevicesID({properties={categories[1]="lights"}}) ?????

Viens de faire une première grosse passe sur mes scripts... Et bien j'en ai modifié pas mal de code, question optimisation... J'ai bien l'impression, d'après la charge CPU, que ça a fait du bien... y a comme on dirait, plus d'oxygène Et je peux encore faire mieux, mais faut remettre en question l'algo de base pur certain... j'ai déjà des idées @Lazer j'ai commencé un topic pour le filtrage des device, je l'ai mis dans la section "pour les nuls", mais visiblement il faut qu'un admin approuve le sujet, j'ai fais une connerie ?

On peut également filtrer sur le type d'interface : ListeDevice = fibaro.getDevicesID({interfaces ={"light"}}) Ici la syntaxe change encore, car on filtre sur un élément d'une sous-table : "interfaces".

Donc je me lance : un exemple tout simple : lister les device visible : dans l'API on trouve la propriété "visible" : donc : MaListe = fibaro.getDevicesID({visible=true}) me retourne la liste des ID de TOUS les device visible on peut cumuler des filtres : par exemple je veux les visibles de type lumières : ListeDevice = fibaro.getDevicesID({visible=true, properties={isLight=true}}) là, la syntaxe est étrange car on descend dans l’arborescence des propriété des device :

Bonjour à tous, Je commence ce topic afin de recenser les différentes manières de filtrer les device de nos box. Je suis entrain de tester cela depuis une HC3, donc je ne peux pas confirmer que cela fonctionne sur une HC2... Pour se faire, on utilise : MaListe = fibaro.getDevicesID({filter}) on aura donc la liste des ID des device trouvés. il existe une autre méthode avec : MaListe = api.get(/devices/?...) dans ce cas, on aura un retour JSON avec tout le contenu des propriétés des device. On choisira l'un ou l'autre suivant l'usage. Dans mon cas, je me suis rendu compte que j'utilisais très souvent api.get(), juste pour avoir la liste des ID ! Donc pas du tout cohérent, vu qu'on a pas besoin de récupérer la totalité des propriétés ! Pour les exemples suivant, je me sers de l'API d'un device, que j'ai copié dans NotePad++ afin de visualiser le JSON plus facilement (voir les captures futures)

non mais c'est super interessant. pour mon problème initiale de plantage... je réfléchirais en dormant là je sèche. Suis pas du genre à lâcher l'affaire, mais là... à moins d'attendre la prochaine MAJ, en espérant... sinon à l'ancienne, je désactive toutes les notifications des device, et je les gère depuis une scène ! Ah mais non, y a pas de multi instance des scènes ! donc faudra que j'utilise mon QA qui interroge le refreshState, qui tourne très bien... lui... Mais ça veut dire : gérer une liste de device, gérer la valeur du device, bla-bla-bla ... super lourd ! EDIT : peut être essayer de protéger l'appel de la foncation par un pcall...

oulà ton exemple me donne mal au cheveu qui me reste. faut que je l'étudie avec du debug... merci pour les explications !

en attendant, j'ai trouvé comment rendre le plantage du QA, donc de la box, non plus aléatoire, mais bien répétable à souhait ! il me suffit d'exécuter le QA (donc 3 à 4 secondes pour tout traiter) et de déclencher un device (capteur, ou actionneur) pendant ce temps là. Et ça loupe pas, crash instantané ! alors : hypothèse : à chaque changement d'état d'un device, la box fait un appel à l'api /deviceNotifications/ pour savoir si elle doit envoyer une notification ou non. Et moi pendant ce temps là je suis entrain de modifier cette API. Donc ça aime pas et plante tout. Pourtant... avant la mise à jour c'était ok, jamais planté, et je confirme que ce scénario arrivait souvent... Mais alors si c'est bien ça, je sais absolument pas comment le contourner !

ah mais attend ! suis bête ! j'utilise souvent la récursivité ! quand par exemple on veut bouclé une fonction à intervalle régulier pour contrôler une heure et déclencher des actions ! function MaFonction() ... fibaro.setTimeout(60*1000, function() MaFonction() end) end c'est bien ça ?

ok très bien. donc dans ce ca précis, le fait de passer par l'asynchrone suffit où il faut que je fasse une vrai récursivité ?

ça faudra tester...

je le ferais avec plaisir, mais ce sera lite... du moins au début, en espérant que la communauté alimente le sujet... sinon je continue mon optimisation du script qui plante : j'ai remplacé : ListeDevice = api.get("/devices/?visible=true") par : ListeDevice = fibaro.getDevicesID({visible=true}) ici, j'ai absolument pas besoin de toutes les infos des device que me donne le api.get(). J'ai juste besoin de la liste des device, déjà ça soulage la RAM et je prends beaucoup moins de temps à avoir la liste des ID (et ça j'avoue avoir fait cette connerie dans beaucoup de script...) Et du coup c'est plus facile d'exploiter la table également... ça rejoint la remarque de @mprinfo qui disait d'utiliser les fonctions fibaro... ben là c'est un bon exemple... Ensuite je me suis rendu compte que je faisais un api.put() même pour des device qui n'ont pas la propriété concernée ! Ne pouvant mieux filtrer la liste des device, je vérifie donc par code la présence de cette propriété avant de continuer -> c'est con ! mais j'avais pas fait gaffe !! Bon malgré ça, ça plante toujours aléatoirement, mais très rarement... donc là je trace pour chaque fonction exécutée, le "start" et le "end" avec l'ID en cours de modifications. ça m'explose le debug, mais je verrais bien sur quelle device ça bloque, peut être que c'est toujours le même ! A suivre ! PS : @Lazer : on est bien d'accord sur le terme "récursif" d'une fonction : for blablabla do fibaro.setTimeout(0, function() MaFonction() end) end ici, "MaFonction" est récursive, c'est bien ça ? C'est comme si je lançais une multitude de "thread" ? toujours ok ? le délai à 0 me gêne, j'ai l'impression que ça "emballe" la box...

@Lazer : alors j'arrive pas à trouver le moyen de mieux filtrer mes device pour ce coup là... Franchement, je pense que qqun de compétent (si tu vois ce que je veux dire ) créé un topic sur la manière de filtrer les api.get()... Visiblement, on peut pas filtrer tout ce qu'on veut. Mais on sait pas ce qu'on peut faire ou pas J'ai vu qu'il existait des moyens de comparaison (gt, lt ge, le, equal, ...) et pas moyen de les utiliser C'est galère quand il faut descendre dans l'arborescence de la table json... bref, en plus c'est pas franchement pas documenté... Ce serait vraiment top que qqun le fasse , je le ferai bien, mais je m'y connais pas assez, et rien sur le fofo officiel... je dis ça mais je dis rien sinon : je viens de modifier ce QA pour mes notifications : J'ai réussi à me passer d'une boucle (celle qui contient la liste des types d'actions dans ma variable) J'ai mis le code qui modifie l'api pour chaque device dans une fonction récursive. Et ben mon vieux, rien que ça , ça change la vie, la CPU mon franchement moins... MAIS ça continue à planter de temps à autre... ??? --[[----------------------------------------------------------------------------------------------- Active/désactive les notifications push V2 - 30/07/2020 - fonction récursive pour la modification V1 - 25/03/2020 - original -------------------------------------------------------------------------------------------------]] function QuickApp:onInit() __TAG = string.format("QA_%s_%s",self.id, self.name) self:debug("onInit") self.ListeEvent = { ["IsOpening"]=true, --Volet ouvert ["IsClosing"]=true, --Volet fermé ["TurningOn"]=true, --lumière ON ["TurningOff"]=true, --lummière OFF ["Motion"]=true, --détection PIR ["Flood"]=true, --détection inondation ["Opening"]=true, --ouverture d'une porte/fenêtre } end function QuickApp:turnOn() self:updateProperty("value", true) self:UpdateNotif(true) end function QuickApp:turnOff() self:updateProperty("value", false) self:UpdateNotif(false) end -------------------------------------------------------- -- Modifie l'API du device si son evenement est dans la liste -------------------------------------------------------- function QuickApp:ModifyNotif(id, value) --récupère les notifications de ce device MyNotif = api.get("/deviceNotifications/v1/"..id) --pour chaque notif de ce device, si trouve l'evenement, le modifie for j = 1, #MyNotif do if self.ListeEvent[MyNotif[j].type] then MyNotif[j].active = value end end --applique les modifications pour ce device api.put("/deviceNotifications/v1/"..id, MyNotif) end -------------------------------------------------------- -- Fonction Pincipale, liste tous les device visible -------------------------------------------------------- function QuickApp:UpdateNotif(value) --liste tous les device VISIBLE ListeDevice = api.get("/devices/?visible=true") --pour chaque device trouvés for i = 1, #ListeDevice do fibaro.setTimeout(0, function() self:ModifyNotif(ListeDevice[i].id, value) end) end self:trace("Notification = "..tostring(value)) end

alors un petit exemple, je pourrais gagne un api.get(), celui qui liste tous les devices, si j'utilise l'api : /deviceNotifications/v1 mais comment filtrer les éléments qui sont active = true ?? J'ai essayé : ListeDevice = api.get("/deviceNotifications/v1?notifications=[active,true]") ListeDevice = api.get("/deviceNotifications/v1?active=true") ListeDevice = api.get("/deviceNotifications/v1?=[active,true]") Mais à chaque fois il me retourne la liste entière [ { "deviceId": 3, "notifications": [ { "active": false, "label": "labels.deviceNotifications.settings.type.Unavailable", "type": "Unavailable", "interval": { "type": "once" }, "channels": [], "users": [ 2 ] } ] }, { "deviceId": 7, "notifications": [ { "active": false, "label": "labels.deviceNotifications.settings.type.Unavailable", "type": "Unavailable", "interval": { "type": "once" }, "channels": [], "users": [] } ] }, ... ]

ça ok ! et on peut les cumuler ? ÉDIT : oui pardon j'avais pas vu le dernier ! bon j'essayerais... merci encore pour les tuyaux !!

après pour les filtres dans les api.get, j'ai déjà beaucoup galéré ! il me semble qu'on peut pas filtrer sur toutes les propriétés existantes, et surtout on peut pas cumuler si ? par exemple filtré sur une propriété qui est elle même un tableau ? on peut pas filtrer sur l'élément x de ce tableau de cette propriété ?

oui voilà c'est ça

super interessant ton lien merci !

@mprinfo : y a pas de commande fibaro pour désactiver telle ou telle notification sur un device ! @Lazer : alors niveau temps on parle de en moyenne 4 secondes d'après les time code de début et fin de la fonction. la première boucle est en effet très grosse (tous les device visible) mais la seconde comporte 3 ou 4 éléments. et la troisième comporte le nombre d'éléments visible dans la variable... punaise ! oui oui dis comme ça, ça mouline sévère ! mais tu me fais pensé, avec ta remarque précédente sur les tableaux, j'avais vérifié les tableaux que je créé moi même, ex : MaTable = {} J'ai pas pensé aux tables créées quand on fait des api.get() ! et comme tu l'as bien constaté, j'ai tendance, pour me faciliter le code, à abuser des api.get() pour des fonctions génériques ! donc de créer beaucoup de tableaux !! en revanche, la gestion des socket par exemple, est bien gérée, malgré la quantité d'info qui passent, c'est hyper réactif ! mais j'ai de la récursivité partout pour ça pour pairs et ipairs, j'ai commencé à m'en séparer au profit de tableau indexé, si ça s'appel comme ça : {[1] = ..., [2] = …} comme ça je tape directement sur la bonne valeur, sans avoir à le parcourir systématiquement... bon ben je sens l'optimisation de code ces vacances PS : je savais pas qu'on pouvait faire du settimeout avec 0 en délais...

tu as raisons, tu suis bien ce que fais j'avais pas pensé au QA qui sont visibles aussi etc... en effet je peux peut-être mieux filtrer du coup ! pour les fonctions récursives, le fait, dans une boucle, d'appeler une fonction par settimeout, impose de mettre une tempo dans les paramètres du settimeout ! ça va ralentir la vitesse d'exécution du QA !! ?? ou alors j'ai pas compris ! ?

@mprinfo, ça marchait avant la dernière mise à jour, donc pas trop envie de la laisser tranquille !

mais je filtre sur la propriété visible, vu que ça concerne tous les device visible ! je peux faire plus ... oui donc on revient à la manière de coder je vais regardé ce que peux faire avec les fonctions récursives...