MAM78 Posté(e) le 19 novembre 2021 Signaler Partager Posté(e) le 19 novembre 2021 Je cherche à coder dans une QuickApp de type "Capteur binaire" le changement d'icône. Je m'explique, mon main est chargé de vérifier régulièrement l'état d'un composant tiers via des requêtes getAPI. Lorsque ce composant tiers est en état inaccessible : je signifie déjà le problème via une indication d'Erreur via la commande suivante : self:updateProperty("log", "Error"). en plus je souhaiterais que : l'icône qui s'affiche soit celle qui correspond au "Capteur inactif" le symbole affiché en-bas à droit soit rouge : du genre : Lorsque ce composant tiers est en état accessible : je souhaiterais que : l'icône qui s'affiche soit celle qui correspond au "Capteur actif" le symbole affiché en-bas à droit soit vert du genre : Quelle est la ou les commandes Lua qui permettraient qu'automatiquement l'icône affichée soit celle qui correspond à l'un au l'autre état ainsi que le symbole d'état rouge ou vert. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fredmas Posté(e) le 19 novembre 2021 Signaler Partager Posté(e) le 19 novembre 2021 Si j’ai bien compris ta question normalement tu devrais trouver la réponse ici : Lien vers le commentaire Partager sur d’autres sites More sharing options...
MAM78 Posté(e) le 19 novembre 2021 Auteur Signaler Partager Posté(e) le 19 novembre 2021 Non pas tout à fait, je souhaite utiliser les principes de fonctionnements automatiques de la HC3.De base tu peux associer deux icônes à un device pouvant représenter 2 états selon, il me semble la valeur true/false de la propriété du module parent: valueMais comment faire pour que le petit symbole rouge ou vert s’active ?Envoyé de mon iPhone en utilisant Tapatalk Pro Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fredmas Posté(e) le 19 novembre 2021 Signaler Partager Posté(e) le 19 novembre 2021 OK ça je ne sais pas s'il y a une fonction qui "superpose" le petit symbole vert sur l'icone au besoin en fonction de l'état. Car j'avais imaginé (que ce soit pour un QA perso ou un QA Fibaro (y compris pour les modules natifs Fibaro), tout simplement uploder les 2 icones, et faire l'updateProperty en fonction des conditions. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 19 novembre 2021 Signaler Partager Posté(e) le 19 novembre 2021 (modifié) Ben... euh... soit j'ai pas compris la demande... soit c'est juste la base de la base d'un QA de type binary (voir les exemples proposés par Fibaro par défaut lors de la création du QA) => self:updateProperty("value", true) (ou false) L’icône suivra toute seule, c'est la HC3 qui le gère EDIT : en fait après relecture c'est ce qu'à expliqué Fredmas juste au dessus Modifié le 19 novembre 2021 par Lazer Lien vers le commentaire Partager sur d’autres sites More sharing options...
MAM78 Posté(e) le 19 novembre 2021 Auteur Signaler Partager Posté(e) le 19 novembre 2021 la question est comment faire en sorte que la pastille rouge ou verte en bas à droite s’affiche. Sur les modules Fibaro la pastille passe en rouge lorsqu’il y a une détection d’un dysfonctionnement du module je voudrais reproduire le même principe pour mon quickapp Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 19 novembre 2021 Signaler Partager Posté(e) le 19 novembre 2021 (modifié) Ah je crois que j'ai compris. Tu veux passer le module en état mort (= dead). Je ne suis pas certain de savoir de quelle pastille tu parles, mais lorsqu'un module ne communique plus, il passe donc en état mort. Son icône devient alors grisée avec un symbole radio de dysfonctionnement par devant. Tu peux donc modifier toi même la propriété "dead" de ton QuickApp avec updateProperty pour mettre true/false, exactement comme pour la value. Et tu peux même réagir aux tentatives de réveil : function QuickApp:wakeUpDeadDevice() tools:trace("Tentative de réveil") -- ... ici on tente de contacter le module via IP, Wi-Fi, etc... -- Puis on désactive son état mort : self:updateProperty("dead", false) end PS : exemple de gestion dans mon QuickApp Yamaha MusicCast. PS2 : au moindre problème réseau, le QA passe en dead, c'est un peu pénible... surtout pour les appareils connectés en Wi-Fi dont la liaison est instable par nature. Dans la prochaine version je mettrai un compteur interne et le QA ne passera dead qu'après 2 ou 3 tentatives de connexion infructueuse afin d'éviter le "bagotement". Modifié le 19 novembre 2021 par Lazer Lien vers le commentaire Partager sur d’autres sites More sharing options...
MAM78 Posté(e) le 19 novembre 2021 Auteur Signaler Partager Posté(e) le 19 novembre 2021 Merci c’est bien ça que je cherchais. Je n’avais pas trouvé d’exemple dans tes quickapp tels que IPX/ECODEVICE/Onduleur. Je retiens ta suggestion des RETRY. Est-ce que pour toi il serait judicieux de mettre en dead également les child ? Envoyé de mon iPhone en utilisant Tapatalk Pro Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 19 novembre 2021 Signaler Partager Posté(e) le 19 novembre 2021 Il me semble que dans le QA GCE je gère déjà l'état dead, mais pas le WakeUp forcé, car il n'était pas encore dispo sur les vieux firmware, à l'époque où je l'ai développé. Gérer l'état dead des child me parait tout aussi important que pour le parent, c'est ce que je fais en tout cas. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fredmas Posté(e) le 19 novembre 2021 Signaler Partager Posté(e) le 19 novembre 2021 il y a 22 minutes, Lazer a dit : Ah je crois que j'ai compris. Tu veux passer le module en état mort (= dead). (...) Tu peux donc modifier toi même la propriété "dead" de ton QuickApp avec updateProperty pour mettre true/false, exactement comme pour la value. c'est exactement ce que j'ai testé entre midi et deux, et ça fonctionnait "visuellement" effectivement. Je m'apprêtais à en discuter ici ce soir. Le truc auquel je ne savais pas répondre et que je comptais te demander ce soir @Lazer c'est : au-delà du visuel, quel est la conséquence pour le QA de passer ses propriétés en "Dead". C'est un état en attente qui pourrait changer tout seul suivant des conditions précisées ? ou par exemple le QA se met en veille attendant une action manuelle par exemple ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 19 novembre 2021 Signaler Partager Posté(e) le 19 novembre 2021 Modifier la propriété "dead" n'a absolument aucun impact sur le déroulement du code LUA dans le QA. C'est à toi de gérer cet état dans ton code... en gérant les tentative de reconnexion à l'appareil, etc. Le seul impact, il est visuel, et il est géré par la HC3 : elle va mettre à jour l'icône pour informer visuellement l'utilisateur. Dans le même genre, il y a le champ "enabled", qui est modifiable par l'utilisateur pour désactiver un module depuis l'interface Web. En pratique, cela ne bloque pas le code LUA, c'est au programmeur de gérer cet état. Tous mes QA depuis plus d'un an commencent par lire cette valeur, pour éventuellement stopper net leur exécution depuis le onInit() -- Check if QuickApp device is enabled if not api.get("/devices/"..tostring(self.id)).enabled then tools.log(self, self.trad.disabled, 0) tools.updateLabel(self, "LabelDebug", string.format(self.trad.label_debug_error, self.trad.quickapp_disabled)) tools:warning("Device", self.name, "is disabled => QuickApp stopped") return end Une autre propriété intéressante, c'est "log" qui permet de choisir ce qu'on veut afficher dans la zone de texte sous l’icône du QA. Cela existe depuis les VD sur HC2 d'ailleurs. 3 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fredmas Posté(e) le 19 novembre 2021 Signaler Partager Posté(e) le 19 novembre 2021 il y a 5 minutes, Lazer a dit : Modifier la propriété "dead" n'a absolument aucun impact sur le déroulement du code LUA dans le QA. C'est à toi de gérer cet état dans ton code... en gérant les tentative de reconnexion à l'appareil, etc. Le seul impact, il est visuel, et il est géré par la HC3 : elle va mettre à jour l'icône pour informer visuellement l'utilisateur. Merci beaucoup pour l'explication. Ca répond et c'est clair il y a 5 minutes, Lazer a dit : Dans le même genre, il y a le champ "enabled", qui est modifiable par l'utilisateur pour désactiver un module depuis l'interface Web. En pratique, cela ne bloque pas le code LUA, c'est au programmeur de gérer cet état. Tous mes QA depuis plus d'un an commencent par lire cette valeur, pour éventuellement stopper net leur exécution depuis le onInit() -- Check if QuickApp device is enabled if not api.get("/devices/"..tostring(self.id)).enabled then tools.log(self, self.trad.disabled, 0) tools.updateLabel(self, "LabelDebug", string.format(self.trad.label_debug_error, self.trad.quickapp_disabled)) tools:warning("Device", self.name, "is disabled => QuickApp stopped") return end OK il y a 5 minutes, Lazer a dit : Une autre propriété intéressante, c'est "log" qui permet de choisir ce qu'on veut afficher dans la zone de texte sous l’icône du QA. Cela existe depuis les VD sur HC2 d'ailleurs. Haaaaaa même en cours d'apprentissage, celle-ci je la connais déjà et je l'utilise dans mes QA Lien vers le commentaire Partager sur d’autres sites More sharing options...
MAM78 Posté(e) le 20 novembre 2021 Auteur Signaler Partager Posté(e) le 20 novembre 2021 (modifié) Merci @Lazer c'est exactement le réponses que j'attendais et même plus Tu ne m'as pas répondu concernant ma demande sur ton avis de mettre également les Child en "dead" puisqu'en principe, si tu n'arrives pas à communiquer avec l'équipement tiers, il est fort probable que l'équipement tiers n'arrive pas non-plus à communiquer avec les Childs. Modifié le 20 novembre 2021 par MAM78 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 20 novembre 2021 Signaler Partager Posté(e) le 20 novembre 2021 Euh, ben si je t'ai répondu pour les child Lien vers le commentaire Partager sur d’autres sites More sharing options...
MAM78 Posté(e) le 20 novembre 2021 Auteur Signaler Partager Posté(e) le 20 novembre 2021 Oups désolé, j’ai zappé ta réponse Envoyé de mon iPhone en utilisant Tapatalk Pro Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés