fel-x

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

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.

Salut, Encore besoin d'un coup de main avec GEA Je voudrais que le debug ou le push affiche une phrase contenant la valeur d'une variable globale. J'essaye d'exploiter "Function" mais sans succès. Peut-être que je ne cherche pas du bon côté ? Par exemple pour avoir un push : "Il y a eu xx passages aujourd'hui" où xx est la valeur (nombre) de la variable globale "PassToday" j'ai essayé plusieurs combinaisons comme: GEA.add ( {CONDITIONS}, 30, "", {"Push", 840, {"Function", function() local pass = fibaro.getGlobalVariable("PassToday") or "?" return "Il y a eu " .. pass .. " passages aujourd'hui" end} } ) Je suis sur la bone piste? C'est possible de lire la variable en temps réel pour l'inclure dans le push ? merci

J'ai buté longtemps sur ce problème où dans une liste générée dynamiquement, il faut sélectionner deux fois de suite une option pour que l'updateView du "selectedItem" fonctionne. J'ai fini par trouver une solution, par essais-erreurs et ça fonctionne dans tous les cas chez moi. J'ai converti la valeur en chaine de caractères avec tostring() voici pour le code ci-dessus ma solution: self:updateView("SelectSwing", "selectedItem", tostring(event.values[1])) De là à expliquer pourquoi la "double sélection consécutive" de la même option revient au même... je ne trouve pas ??? Mais bon c'est une solution facile Ca fonctionne chez vous aussi ? En tout cas moi je peux continuer à bosser sur ma prochain QA...

@Supermilk As-tu eu des nouvelles du support Fibaro ? J'ai une HCL en parfait état de marche qui repose dans une boite à chaussures... J'imagine que je pourrais en tirer le firmware pour te le partager ?? En plus elle était à jour il y a encore moins de 2 ans PS: si en plus quelqu'un veut la racheter

Tiens c'est peut-être une bête idée mais est-il possible/envisageable d'implémenter le * (wildcard) dans GEA? Pour permettre par exemple : GEA.add({{"Dates", "27/**"}, {"Time", "11:30"}}, 0, "message", {"Push", 840}) J'imagine que ça risquerait d'affoler le CPU si on l'emploie mal

Oui oui j'ai bien la bonne config de base avec GEA.portables = {840} Ceci dit je ne souhaite pas avoir une notification sur mon portable à chaque règle exécutée. Je préfère donc préciser en action vers quel(s) deviceID(s) doivent partir les push. Par exemple ceci fonctionne aussi : {"Push", {840, 716, 717, 718}, "Coucou la famille !"} mais je sais qu'un "Push" tout seul sans aucun argument/paramètre derrière va envoyer vers le {840}

oui en effet @Lazer je n'avais pas saisi le sens de ton message. Je suis justement occupé à remplacer tous mes "Monthly" par 12 lignes mensuelles, car de façon définitive aucune ligne "Monthly" ne fonctionne (même sans autre condition). Et là tu viens de me faire percuter. Je préfère une longue ligne pas jolie, mais une optimisation des ressources ! Je vais modifier de ce pas. J'en profite pour signaler que je constate que le message Push est celui qui est dans l'action et pas dans la notification, lorsque j'emploie "Dates" en condition. GEA.add({"Dates", "01/01"}, 30, "message 1", {"Push", 840) -- l'ID 840 (smartphone) ne reçoit rien GEA.add({"Dates", "01/01"}, 30, "message 1", {"Push", 840, "message 2"}) -- l'ID 840 (smartphone) reçoit "message 2" A quoi sert le "message 1" que je pensais retrouver dans le Push et dans le debug, mais que je ne retrouve nulle part ? Ou c'est moi qui fait un truc pas juste ? Parce qu'avec "Time" ou "Days" (ou les deux) en condition, je reçois bien le "message 1 en Push" et n'ai pas besoin d'ajouter un "message 2" GEA.add({{"Time", "13:10"}, {"Days", "All"}}, 30, "message 1", {"Push", 840}) -- l'ID 840 (smartphone) reçoit "message 1"

Et donc doit-on partir du principe qu'à défaut de pouvoir ajouter une condition "Time", pour l'instant "Monthly" se déclenche une et une seule fois par mois à minuit (entre 00:00:00 et 00:00:31) à la date correspondante ? Par exemple {"Monthly","Samedi"} se déclenchera dès qu'on passera du premier vendredi au premier samedi du mois à minuit.