fel-x

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

Ha merci ça m'aide Je suis en train de tester une série de devices avec cette boucle : for id = 100, 150 do local dev = api.get("/devices/" .. id) if not dev or dev == nil then self:debug("Device Tester : ", "Le module " .. id .. " n'existe pas") else local typ = dev.typeType or "unknown" local count = self:iconCount(typ) self:debug("Device Tester : ", "Le module " .. id .. " attend " .. count .. " icone(s)") end je récupère surtout des "Le module xxx attend ?? icone(s)" et avec dev.typeType c'est encore pire... Mais je vais continuer à creuser par là. Je ne veux pas me baser sur dev.properties.icon.path ou dev.properties.icon qui ne sont pas fiables je crois.

Ce n'est pas tout à fait ça @Lazer, je voudrais interroger un module et qu'il me réponde s"'il attend une icône, ou un set de 2 icônes, ou un set de5 icônes, ou un set de 11 icônes. Donc la réponse de @jang semble plus proche de ce que je cherche. Est-ce que ceci suffit à couvrir toutes les possibilités ? local map = { [QuickAppBase.iconProviders.single]=1, -- single icon [QuickAppBase.iconProviders.binary]=2, -- off,on [QuickAppBase.iconProviders.multilevel]=11, -- 0%,10%,20%,30%,40%,50%,60%,70%,80%,90%,100% [QuickAppBase.iconProviders.baseShutter]=5 -- opening,opened,closing,closed,unknown } Ou bien il faudrait construire une table avec davantage d'éventualités... Je vais vérifier que paramètres permet de mapper ça... Merci @jang !

Je vais donner une précision sur la finalité car ce n'est pas très clair à la relecture J'écris une QA (dont vous pourrez peut-être profiter sous peu) qui permet de sélectionner des icônes de sa box, et de les attribuer à n'importe quel device (parent, enfant, caché, etc.), avec interface visuelle pratique. C'est purement pour enjoliver le UI ! Afin d'éviter une situation où un utilisateur attribuerait une icône monostate à un device 'multistate' (on devrait plutôt dire "multi-icône"), je voudrais les détecter et empêcher l'exécution. En effet, le UI va chercher les états différents d'une icône dans le cas des modules/QA qui peuvent changer d'état, comme les switches ON/OFF ou des volets par exemple. --> Ce que je cherche c'est une façon (simple?) d'identifier si pour un module donné, la box va chercher des icônes selon l'état ou une icône fixe. Le properties.deviceIcon n'est pas suffisant, ni le contenu du properties.icon (qui parfois est vide, ou fait référence dans properties.icon.path à un fichier SVG plutôt qu'à une icône PNG avec suffixes d'état '#ID0.png' '#ID100.png'). Quant à properties.icon.source il peut valoir 'HC' ou 'HC_USER' sans que cela n'ait d'impact réel sur le fonctionnement. j'espère que ça a du sens ce que je dis

Salut dans mon code, je voudrais pouvoir vérifier si un device est multistate ou pas. En fournissant l'ID d'un module ou d'une QA, je voudrais une vérification immédiate du status multistate ou non. J'ai été lire les Json de plusieurs devices via /api/devices/#ID mais je n'ai pas trouvé une propriété caractéristique... Bien entendu on peut le déduire assez facilement selon le type, ou le basetype, ou le supportedDeviceRoles, etc... Mais je cherche un fonction Lua qui pourra me le dire tout de suite ? Suis-je passé à côté d'une évidence? merci

Je retombe sur ceci durant mes recherches... Est-ce équivalent à ça si on l'utilise au sein de la QA elle-même (donc si id_module = self) self:updateProperty("deviceIcon", id_icon_numerique) Ou bien il y a une différence ?

Pour info c'est une QA "Edenred" qui calcule le nombre de jours ouvrables du mois prochain (via une API publique), et l'antépénultième jour ouvrable du mois en cours. Ce jour-là, une alerte est envoyée en Push pour rappeler de commander un certain nombre de chèques Ederend (= n jours ouvrables du mois suivant) pour le mois suivant. Je ne pense pas que ça intéressera beaucoup de monde.. ou alors quelques rares utilisateurs en Belgique ? J'ignore si la France ou d'autres pays emploient aussi ce système de "chèques-repas" ou un équivalent.

Tu as parfaitement raison @jojo je pourrais faire tous les calculs dans ma QA et simplement dire à GEA de vérifier une seule variable "aujourd'hui c'est le jour J" ! Mais tu sais comment ça marche... j'ai écrit une QA qui fonctionne.. j'ai plus envie de la modifier ... je cherche à l'exploiter depuis GEA sans la changer... je m'embourbe dans mes idées de contournement pour pas changer ma QA... Au final ça fonctionne et en bonus j'ai appris des trucs ! Si j'étais un programmeur/codeur professionnel je pense que je serais déjà viré pour avoir fait si compliqué alors qu'une solution simple existait Heureusement c'est juste un hobby Mais maintenant que ça fonctionne de façon complexe, je vais trouver un moment pour simplifier ma logique. merci pour cette autre perspective du KISS

Ha ben zut alors, j'ai loupé ça ! Alors que la syntaxe est ouverte dans ZeroBrane en permanence sur mon ordi et que je plonge dedans sans arrêt Par contre soit tu as raccourci/customisé ta syntaxe, soit tu es dyslexique car chez moi c'est la ligne 1930

Par curiosité, @Lazer sais-tu m'indiquer le comportement attendu de #value ? Il peut être employé directement dans la règle GEA dès qu'il est "généré" ? Comme par exemple dans une seconde condition ? Je sais qu'on peut l'employer plusieurs fois dans la même règle, mais qu'en est-il s'il y a 2 values générées comme dans ma citation ci-dessus ? Est-ce possible ou il est envisageable d'employer #value1 et #value2 par exemple ? Ou c'est seulement la dernière qui sera reprise par #value ? J'ai fait quelques tests mais avec 2 #value générées dans les conditions, il n'y a ni crash ni exécution de la règle.

c'est plus long à programmer, mais ça fonctionne ! Merci @Lazer

Et maintenant, je voudrais construire une date de toutes pièces, et plutôt que de faire des essais-erreurs, je viens demander si cela est possible ? Je m'explique : il faudrait que la condition d'une règle GEA soit "Dates" La syntaxe de base est claire : GEA.add( {"Dates", "01/01"} , 30, "", {ACTIONS} ) Mais je voudrais que la date soit construite au départ de 2 variables locales (AlertDay, CurrentMonth) appartenant à une QA (941). Par exemple AlertDay = 27 et CurrentMonth = 3 et donc je souhaite la règle suivante : GEA.add( {"Dates", "27/03"} , 30, "", {ACTIONS} ) Est-ce que je peux la générer dynamiquement comme ceci : GEA.add( {{"VariableQuickApp+", 941, "AlertDay", 0}, {"VariableQuickApp+", 941, "CurrentMonth", 0}, {"Dates", "#value#/#value#"}} , 30, "", {ACTIONS} ) Déjà je ne suis pas certain que GEA va récupérer une #value# d'une condition à la suivante, mais en plus je ne sais pas s'il va gérer 2 #value# consécutifs dans la même condition et les distinguer d'office par leur ordre ? Les variables AlertDay et CurrentMonth changent en début de mois dans la QA, et déterminent le jour où une certaine action devra être lancée. AlertDay vaut toujours entre 1 et 31, et CurrentMonth est évidemment toujours le mois en cours (de 1 à 12). Sans doute on pourrait simplifier puisque CurrentMonth est logique à déduire et j'aurais volontiers employé {"Monthly", <num_jour>} comme ceci : GEA.add( {{"VariableQuickApp+", 941, "AlertDay", 0}, {"Monthly", #value#}}, 30, "", {ACTIONS} ) mais "Monthly" ne fonctionne pas comme prévu. Je suis preneur de tout bon conseil

merci @Lazer tout devient plus simple avec ton aide Ca fonctionne très bien avec "Global+" c'est le plus simple pour récupérer la valeur de la variable plutôt que de faire appel à une fonction. Et je sais que tu n'aimes/emploies pas trop les Push mais dans mon environnement et pour mon usage c'est super pratique. Et pour le coup je découvre l'action "Test" en bonus.