fel-x

Exactement !! C'est précisément l'objet de ma question ! Le dernier dump est obtenu par get.api("/icons") en Lua (depuis une QA) Les premiers en haut sont ceux renvoyés par le REST API (http://IP_BOX/api/icons et http://IP_BOX/api/devices) On trouve bien les correspondances entre get.api("/devices") et http://IP_BOX/api/devices Mais pas entre get.api("/icons") et http://IP_BOX/api/icons ! La réponse m'a été donnée par @jgab dans le forum officiel : il suffit d'employer net.HTTPClient() avec comme header ["X-Fibaro-Version"] = "1" pour obtenir une copie complète de icons.json En effet il y a un bug dans le swagger qui emploie toujours ["X-Fibaro-Version"] = "2" (même si on force le paramètre à 1) ; ce qui correspond à une version minimaliste et tronquée de icons.json ; et c'est aussi ce que fait api.get() sur /icons ! Donc pour contourner ce bug on force le paramètre sur "1" en appel HTTP. Fallait le savoir !!! pas cool de la part de Fibaro

Voici le dump complet de api.get("/icons") (je le mets un peu en page sinon tout est sur une seule ligne) Attention il est long mais c'est @jojo qui a demandé [19.04.2026] [19:19:07] [DEBUG] [API-GET-ICONS]: [ { "source": "HC", "iconSet": 368, "type": "com.fibaro.FGGC001", "files": [ { "path": "/assets/icon/fibaro/com.fibaro.FGGC001/com.fibaro.FGGC001.svg", "type": "event", "condition": { "type": "event", "data": { "eventType": "CentralSceneEvent", "data": { "keyId": 0 } } } }, { "path": "/assets/icon/fibaro/com.fibaro.FGGC001/com.fibaro.FGGC001.svg", "type": "event", "condition": { "type": "event", "data": { "eventType": "CentralSceneEvent", "data": { "keyId": 1 } } } }, { "path": "/assets/icon/fibaro/com.fibaro.FGGC001/com.fibaro.FGGC001.svg", "type": "event", "condition": { "type": "event", "data": { "eventType": "CentralSceneEvent", "data": { "keyId": 2 } } } }, { "path": "/assets/icon/fibaro/com.fibaro.FGGC001/com.fibaro.FGGC001.svg", "type": "event", "condition": { "type": "event", "data": { "eventType": "CentralSceneEvent", "data": { "keyId": 3 } } } }, { "path": "/assets/icon/fibaro/com.fibaro.FGGC001/com.fibaro.FGGC001.svg", "type": "event", "condition": { "type": "event", "data": { "eventType": "CentralSceneEvent", "data": { "keyId": 4 } } } }, { "path": "/assets/icon/fibaro/com.fibaro.FGGC001/com.fibaro.FGGC001.svg", "type": "event", "condition": { "type": "event", "data": { "eventType": "CentralSceneEvent", "data": { "keyId": 5 } } } }, { "path": "/assets/icon/fibaro/com.fibaro.FGGC001/com.fibaro.FGGC001.svg", "type": "event", "condition": { "type": "event", "data": { "eventType": "CentralSceneEvent", "data": { "keyId": 6 } } } }, { "path": "/assets/icon/fibaro/com.fibaro.FGGC001/com.fibaro.FGGC001.svg", "type": "event", "condition": { "type": "event", "data": { "eventType": "CentralSceneEvent", "data": { "keyId": 7 } } } }, { "path": "/assets/icon/fibaro/com.fibaro.FGGC001/com.fibaro.FGGC001.svg", "type": "event", "condition": { "type": "event", "data": { "eventType": "CentralSceneEvent", "data": { "keyId": 8 } } } }, { "path": "/assets/icon/fibaro/com.fibaro.FGGC001/com.fibaro.FGGC001.svg", "type": "event", "condition": { "type": "event", "data": { "eventType": "CentralSceneEvent", "data": { "keyId": 9 } } } }, { "path": "/assets/icon/fibaro/com.fibaro.FGGC001/com.fibaro.FGGC001.svg", "type": "event", "condition": { "type": "event", "data": { "eventType": "CentralSceneEvent", "data": { "keyId": 10 } } } }, { "path": "/assets/icon/fibaro/com.fibaro.FGGC001/com.fibaro.FGGC001.svg", "type": "event", "condition": { "type": "event", "data": { "eventType": "CentralSceneEvent", "data": { "keyId": 11 } } } }, { "path": "/assets/icon/fibaro/com.fibaro.FGGC001/com.fibaro.FGGC001.svg", "type": "event", "condition": { "type": "event", "data": { "eventType": "CentralSceneEvent", "data": { "keyId": 12 } } } } ] } ]

Je suis toujours dans mon projet de QA de gestion des icônes et ça devient vraiment pas mal. Mais je bloque lorsque je veux afficher les icônes natives d'un device. Le chemin de l'icône pour chaque device peut être déduit depuis les infos contenues dans le JSON du device (accessible via REST API sur BOX_IP/api/devices/#ID) : properties.deviceIcon donne l'ID du l'icône et parfois même son chemin est déjà précisé dans properties.icon.path Lorsque deviceIcon est > 1000 c'est facile ; c'est une icône custom et son chemin est logique : BOX_IP/assets/userIcons/devices/User100X/User100X.png (avec quelques subtilités pour les multistates) Mais lorsque le deviceIcon est < 1000 ça signifie que l'icône est native dans la HC3. Si son properties.icon.path est indiqué, alors c'est simple, mais là où ça se corse c'est s'il est vide. Il m'est impossible de reconstruire le chemin de l'icône au départ de son properties.deviceIcon Je pensais pouvoir le récupérer depuis icons.json obtenu par l'API REST sur BOX_IP/api/icons mais je découvre que api.get("/icons") ne renvoie pas du tout les mêmes infos ! Il est plutôt très court et ne contient presque aucune info sur les icônes générales de la box. J'y vois 19 entrées parlant juste des icônes spéciales (FGKF, FGGC,FGPB, FGCD, usbPort) C'est bizarre car si on fait le parallèle, l'API sur les devices renvoie exactement la même chose via le REST API (BOX_IP/api/devices) que via api.get("/devices"). Quelqu'un sait pourquoi tous les icônes ne sont pas exposées par api.get("/icons") ? Et aussi comment récupérer le chemin de l'icône dans un tel cas ? A titre d'exemple mon device ID 711 est une caméra IP. Sur BOX_IP/api/devices/711 je lis bien ceci : { "id": 711, "name": "Cam4", "roomID": 227, "view": [], "type": "com.fibaro.ipCamera", "baseType": "com.fibaro.camera", ... "properties": { ... "deviceIcon": 92, ... "icon": { "path": "", "source": "" }, ... } Vu que properties.icon.path est vide, je pars vérifier manuellement dans le JSON des icônes via BOX_IP/api/icons et j'y trouve la ligne : { "device": [ { "id": 300, "deviceType": "com.fibaro.binarySwitch", "iconSetName": "ButtonSwitchV2", "fileExtension": "svg" }, ... { "id": 92, "deviceType": "com.fibaro.ipCamera", "iconSetName": "kamera", "fileExtension": "png" }, ... ] } Je confirme que l'UI affiche l'icône BOX_IP/assets/icon/fibaro/kamera/kamera.png ! Mais comment récupérer le iconSetName et le fileExtension de l'id 92 ? via api.get("/icons") on ne peut pas. Il y a un autre appel api.get() qui existe ? Je ne trouve rien dans le swagger. Help !!!

Moi je traduis "if lastChanged < os.time() - 5*3600" par 'lastChanged a eu lieu il y a plus de 5 heures" Donc je dirais d'employer "Property-" puisque la syntaxe GEA explique ceci : "Property-" = Si la valeur de la propriété "lastChanged" du module ... est INFERIEURE à ...

Si tu dis vrai, alors ça devrait marcher avec {"Property+", id["SALON_TMP"],"lastChanged", {"Function", function() return os.time() - 5*3600 end}...

Attends, je pense que tu dois mettre le calcul dans la fonction car GEA retourne une valeur, mais ne fait pas de calcul lui-même. {"Function", function() return os.time() - 5*3600 end} comme ça la soustraction est faite dans la fonction non ?

Comme je le disais, même si tu parviens à récupérer os.time() par GEA, je ne crois pas que ça va fonctionner car GEA ne connait pas la préférence 'lastChanged"; il n'est pas prévu dans le code de GEA qu'il aille puiser cette préférence dans les JSON des devices. C'est certainement possible mais il faut alors demander à @Lazer de l'implémenter pour toi. Ce n'est pas parce qu'une préférence existe et qu'elle est exposée par l'API que GEA peut la lire. Du moins c'est comme ça que je le conçois.

et pour le coup tu avais raison les timestamp sont des nombres et on peut faire des calculs directement avec, sans passer par tonumber()

ok, je veux dire que pour récupérer la valeur d'une propriété dans le json d'un device tu dois faire un appel API. voici mon test (remplace juste par l'ID correct chez toi) function QuickApp:TestTempDelay() local deviceID = XXX -- ton id["SALON_TMP"] local dev = api.get("/devices/" .. deviceID) if not dev or not dev.properties or not dev.properties.lastChanged then hub.debug("Test pour jojo", "lastChanged non trouvé dans le JSON du device " .. deviceID) return end local lastChanged = dev.properties.lastChanged local now = os.time() local difference = now - lastChanged hub.debug("Test pour jojo", "Il s'est passé " .. difference .. " secondes depuis la dernière modification de température") end

ha mais ça ne veut pas dire qu'elle soit exposée directement ! Tu peux aller chercher dev.properties.lastChanged via l'api en LUA, mais donc tu dois faire tourner ça dans une fonction ou une scène avant de la comparer avec os.time() si je ne m'abuse.

Ah ben oui, je pense qu'il retourne le timestamp Unix.. mais au pire tu lui demandes tonumber(os.time()) à la place pour t'assurer que tu obtiens un nombre. Et d'ailleurs je ne savais pas que "lastChanged" existait ??

Salut @jojo Je ne pense pas que GEA puisse garder en mémoire directement des anciennes valeurs pour les comparer à la valeur actuelle. Mais pourquoi ne pas contourner le problème avec 2 règles : 1/ GEA enregistre dans une variable globale ta valeur à intervalles réguliers. 2/ GEA compare ta valeur actuelle à la variable enregistrée à intervalles réguliers. Evidement (imaginons l'exemple avec des températures) si la valeur est enregistrée à 18, puis elle passe de 18 à 19 puis à 16 puis à 18 de nouveau, et que c'est à ce moment-là que la seconde règles la compare au 18 "enregistré" tu auras la mauvaise info qu'elle "n'a pas changé" alors qu'elle a pourtant fluctué. Mais peut-être qu'il faut creuser cette piste ? Ca peut peut-être quand même convenir à ton besoin ? Par exemple vérifier la valeur assez souvent (ou en surveiller le changement par GEA) et enregistrer en variable le timestamp du dernier changement détecté. Ensuite calculer si la durée entre le timestamp enregistré et le os.time() actuel dépasse ton seuil pour t'en avertir le cas échéant ?

Après mes recherches, juste pour info, il y a aussi un device qui nécessite un set de 10 icônes ; c’est le fibaro The Button. je construis une QA qui permet de jouer avec les icônes de tous les modules et de les changer, mais je veux absolument éviter qu’un module reçoive un set d’icônes incompatible, car l’affichage échoue ensuite dans le UI. Ce n’est pas grave, car l’affichage échoue ne bloque rien, mais ce n’est pas joli. voila pourquoi j’essaye de trouver comment fibaro fait le mapping exact entre un device et son nombre d’icônes attendu. un parent c’est facile > toujours 1 cône. mais après ça se complique. je pense avoir trouvé et pris en compte toutes les possibilités mais come je ne dispose pas de tous les types de devices dans mon installation il m’est difficile de tester toutes les situations. dommage que fibaro n’a pas documenté ça. je devrais peut être aussi contacter le support ? Qu’en pensez-vous ?

J’ai bien avancé dans l’analyse des JSON de mes modules et je pense que fibaro se base essentiellement (mais pas uniquement) sur properties.deviceControlType pour déterminer combien d’icônes qu’il doit y avoir dans le « set » pour le module. je n’ai malheureusement pas tous les modules fibaro dans mon installation pour vérifier ça a 100%. L’un de vous aurait un fibaro dimmer pour me dire quel est son properties.deviceControlType ? j’ai trouvé une info sur un autre forum (non fiable je crains) que ce serait « 23 » ? possible de confirmer ? merci et joyeuses Pâques