HC3 & HC3L - 5.150.15 - STABLE - 08/11/2023

[jluc2808 61]

plus je regarde le retour API moins je comprend et dans tous les cas je ne retrouve pas mes petits

choisissez la Réponse :

A - l'API retourne n'importe quoi

B - le panneau diagnostic/Z-wave de la HC3 moteur 2 , restitue n'importe quoi

C - y a une logique mais pas évidente 

D - les extra-terrestres ont débarqué et s'amusent à perturber les HC3

 

Pour moi je vote D

[Lazer 8 477]

E - Obi-Wan Kenobi utilise la force pour communiquer sans fil

[Christb 0]

Le 05/01/2024 à 21:12, Lazer a dit :

Après pas mal de cheveux perdus, j'ai fini par comprendre comment utiliser les listes de selection drop-down à la mode Fibaro.... à vrai dire je ne sais pas si c'est un bug ou un comportement prévu, mais c'est vraiment très étrange

 

Si on charge de façon dynamique (lors de l'exécution du code LUA) les options avec self:updateView(), comme dans ton exemple, alors il est impossible de sélectionner une option dans la liste.
Je veux dire par là que l'utilisateur peut sélectionner une option dans la liste, ça va bien déclencher la fonction de callback, mais l'option choisie ne restera pas sélectionnée dans la liste, il est impossible de forcer la présélection avec self:updateview() ce qui nuit considérablement à l'expérience utilisateur, puisque le propre d'une liste déroulante est de montrer l'option actuellement sélectionnée et de permettre visuellement d'en changer.

 

Pour que la présélection fonctionne, il faut 2 conditions :

• Les options doivent être chargées de façon statique dans la fenêtre de modification du QuickApp, sur la droite de l'écran lors de l'édition du contrôle :
  
  
   
• Dans le code LUA, la présélection d'une option peut alors se faire avec l'argument "selectedItem" dans la fonction self:updateView(), comme ceci :

  
  self:updateView("SelectSwing", "selectedItem", "Off")

   

 

Ah la logique polonaise et ses subtilités, elle nous surprendra toujours

 

 

Voici un exemple de code plus concret pour la fonction de callback associée à la capture d'écran ci-dessus :

function QuickApp:selectSwing_onToggled(event)

	self:updateView("SelectSwing", "selectedItem", event.values[1])

	-- Puis fait d'autres choses afin de réaliser l'action désirée...
	-- ...

end

On constate qu'on récupère la valeur de l'option sélectionnée par l'utilisateur dans la variable event.values[1]

 

Dans mon cas c'est simple puisque la valeur de l'option correspond à son nom.

 

 

Note : la modification "statique", telle qu'effectuée dans la fenêtre de modification du QA (capture d'écran) est en réalité possible pseudo-dynamiquement dans le code LUA.
Pour cela, il faut modifier le QA proprement dit, non pas avec updateView (qui n'agit qu'en mémoire vide), mais avec api.put("/devices/ID", ...) ce qui a pour effet de sauvegarder la config du QuickApp dans la base de données, mais aussi de la redémarrer instantanément... attention aux effets de bord, il ne s'agirait pas de faire cette modification de façon inconditionnelle dans onInit(), sinon on obtient un QA qui reboot en boucle.

 

 

Dear Lazer,

It seems that Fibaro made some progress with the last beta version (1.513) : if the option in advanced tab " Use the new views in mobile application "  is unticked, then it is possible to link a second select type button to the selection of another button.

I have also found a way to have the "Choose"  label displayed even if the selector had been used before (in normal QA code word, the QA is remembering its last choice for ever). For your info, test QA attached.

Could you test it to see if the QA behaves as for me (whatever the previous choice was, selecting "Auto" in the Top selector forces the bottom selector to display "Choose".

 

502_Binary_Switch.fqa

[Lazer 8 477]

When I click on Heat or Cool in S1, then S2 reflects the change.
Whereas if I choose another value (Auto or Off) then S2 displays Choose.

 

[yves.guern 14]

Bonjour Lazer,

A la suite de ton post:

Le 05/01/2024 à 21:12, Lazer a dit :

Après pas mal de cheveux perdus, j'ai fini par comprendre comment utiliser les listes de selection drop-down à la mode Fibaro.... à vrai dire je ne sais pas si c'est un bug ou un comportement prévu, mais c'est vraiment très étrange

 

Si on charge de façon dynamique (lors de l'exécution du code LUA) les options avec self:updateView(), comme dans ton exemple, alors il est impossible de sélectionner une option dans la liste.
Je veux dire par là que l'utilisateur peut sélectionner une option dans la liste, ça va bien déclencher la fonction de callback, mais l'option choisie ne restera pas sélectionnée dans la liste, il est impossible de forcer la présélection avec self:updateview() ce qui nuit considérablement à l'expérience utilisateur, puisque le propre d'une liste déroulante est de montrer l'option actuellement sélectionnée et de permettre visuellement d'en changer.

 

Pour que la présélection fonctionne, il faut 2 conditions :

• Les options doivent être chargées de façon statique dans la fenêtre de modification du QuickApp, sur la droite de l'écran lors de l'édition du contrôle :
  
  
   
• Dans le code LUA, la présélection d'une option peut alors se faire avec l'argument "selectedItem" dans la fonction self:updateView(), comme ceci :

  
  self:updateView("SelectSwing", "selectedItem", "Off")

   

 

Ah la logique polonaise et ses subtilités, elle nous surprendra toujours

 

 

Voici un exemple de code plus concret pour la fonction de callback associée à la capture d'écran ci-dessus :

function QuickApp:selectSwing_onToggled(event)

	self:updateView("SelectSwing", "selectedItem", event.values[1])

	-- Puis fait d'autres choses afin de réaliser l'action désirée...
	-- ...

end

On constate qu'on récupère la valeur de l'option sélectionnée par l'utilisateur dans la variable event.values[1]

 

Dans mon cas c'est simple puisque la valeur de l'option correspond à son nom.

 

 

Note : la modification "statique", telle qu'effectuée dans la fenêtre de modification du QA (capture d'écran) est en réalité possible pseudo-dynamiquement dans le code LUA.
Pour cela, il faut modifier le QA proprement dit, non pas avec updateView (qui n'agit qu'en mémoire vide), mais avec api.put("/devices/ID", ...) ce qui a pour effet de sauvegarder la config du QuickApp dans la base de données, mais aussi de la redémarrer instantanément... attention aux effets de bord, il ne s'agirait pas de faire cette modification de façon inconditionnelle dans onInit(), sinon on obtient un QA qui reboot en boucle.

 

 

 

Je me permet:

1) de te remercier d'avoir découvert self:updateView("NomDuBouton","selectedItem","toto"), pour moi c'est tout ce qu'il manquait pour rendre cette fonctionnalité réellement utilisable.

=> comment as tu fait?  ou as-tu appris le polonais (dans une notice de calculatrice HP)?

2) de te 'corriger' à propos des listes de choix dynamiques/statiques:

on peut utiliser un chargement dynamique de la liste avec self:updateView("NomDuBouton", "options", Liste_d_Options) mais il ne faut appeler cette fonction "qu'une fois". Effectivement à chaque appel, la sélection précédente disparait (sauf à appeler ensuite ta fonction magique!)
Donc il ne faut appeler self:updateView("NomDuBouton", "options", Liste_d_Options)  que si la liste d'option a effectivement changé (et surement pas dans la callback associée au bouton de la liste...)

 

Mais désormais, associé à ta fonction il y a moyen de faire ce que l'on souhaite!

Je viens de modifier 2 de mes QA en ce sens et c'est très BÔ!

Une d'entre-elle permet de modifier les paramètres de configuration des devices sans template.

Il y a 2 listes dynamiques dans la QA: L'ID du device et le N°du paramètre (dont la liste varie en fonction de l'ID)

 

Merci!

 

Bonne journée

[Lazer 8 477]

Hum, je ne me souviens plus bien comment j'ai trouvé la syntaxe de la fonction, mais par contre je me souviens avoir chercher longtemps...

 

Merci pour ta trouvaille, je n'ai même pas creusé aussi loin.