Changement d'icône d'un Main QuickApp

[MAM78]

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.

 

[Fredmas]

Si j’ai bien compris ta question normalement tu devrais trouver la réponse ici :

 

 

[MAM78]

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: value

Mais comment faire pour que le petit symbole rouge ou vert s’active ?


Envoyé de mon iPhone en utilisant Tapatalk Pro

[Fredmas]

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.

[Lazer]

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

[MAM78]

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

[Lazer]

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

[MAM78]

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

[Lazer]

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.

[Fredmas]

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 ?

[Lazer]

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.

 

[Fredmas]

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 

 

[MAM78]

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

[Lazer]

Euh, ben si je t'ai répondu pour les child

 

[MAM78]

Oups désolé, j’ai zappé ta réponse


Envoyé de mon iPhone en utilisant Tapatalk Pro