Aller au contenu
Lazer

Quick App - Xiaomi Roborock Vacuum

Recommended Posts

Il y a 3 heures, Lazer a dit :

A ce sujet, dans tous mes QuickApps, j'ajoute maintenant la possibilité de désactiver

J'ai aussi pensé à ce mode de désactivation, mais je me suis arrêté en voyant que le lua tournait malgré que le QA soit noté enabled = false.

Il faut donc tester dans le Init la valeur du Enable ?

Si j'utilise l'api : local dev =  api.get("/devices/347" ) ,  dev.enabled contient bien tue ou false OK

par contre fibaro.getValue(347, "enabled")) me rend toujours nil  ???

Existe t'il un equivalent à getSelfID()  des VD de la HC2

 

Ou il y a plus simple et je n'ai pas la solution

Partager ce message


Lien à poster
Partager sur d’autres sites

C'est exactement pour cela que j'en ai parlé, je me doutais que ça allait faire réagir les développeurs :D
Et effectivement, c'est à nous de coder la logique de désactivation.

 

L'équivalent de getSelfID() est tout simplement self.id (accessible uniquement depuis une fonction de QuickApp, puisqu'on utilise self), ou bien de façon plus générale plugin.mainDeviceId qui est accessible de n'importe où dans le code LUA du QA)

 

fibaro.getValue(347, "enabled")) ne te retourne rien car enabled n'est pas une propriété du device (= elle ne fait pas partie de la sous-table properties dans son JSON)

 

Perso j'utilise ce genre code, vers le début de la fonction QuickApp:onInit() :

	-- Check if QuickApp device is enabled
	if not api.get("/devices/"..tostring(self.id)).enabled then
		self:updateProperty("log", "Disabled")
		for _, child in pairs(self.childDevices) do
			child:updateProperty("log", "Disabled")
		end
		self:updateView("LabelDebug", "text", " " .. (self.trad.quickapp_disabled or "QuickApp disabled") .. " ")
		self:warning("Device", self.name, "is disabled => QuickApp stopped")
		return
	end

C'est le return à la fin du bloc de test qui stoppe l'exécution du QuickApp (en réalité ça ne le stoppe pas, ça empêche juste l'exécution de la suite du code de onInit(), et notamment le setTimeout() un peu plus loi qui est censé lancer la boucle infinie)

 

Modifié par Lazer
  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Mais tout de même quand on met le qa disable dans avancé, on est obligé de faire sauvegarde pour enregistrer cet état. Le qa redémarre donc son init il pourrait s'arrêter seul. 

Il ont oublié de coder ou il y a une raison qui m'échappe ? Je n'ai rien vu dans la doc

Partager ce message


Lien à poster
Partager sur d’autres sites

Oui pour modifier le champ enabled, que ça soit par le GUI ou par l'API, dans les 2 cas ça fait la même requête PUT, qui redémarre obligatoirement le QuickApp.

Donc passage obligé par la fonction onInit()

 

Mais ce que je voulais dire, c'est que le QA sera toujours actif, donc il recevra les sollicitations de l'utilisateur, les appels de fonctions, etc.

Donc si on veut faire les choses proprement, il faudrait tester son état enabled au début de chaque fonction.

Un peu lourd...

 

Oubli de la part de Fibaro, ou simple héritage de ce champ depuis les modules Z-Wave ?

Je ne sais pas, mais en tout cas je suis content qu'on aie accès à cette valeur, ça permet de simplement bloquer l'exécution d'un QA.... Je me souviens sur HC2 d'avoir dû vider des main loop de leur contenu, ou d'avoir mis un fibaro:abort() en première ligne, et d'avoir oublié de l'enlever par la suite... "Mais pourquoi ce c.. de VD ne fonctionne plus ???"

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Concernant l'utilisation du QA, sauf si j'ai loupé un truc dans toute cette discussion, quelqu'un aurait déjà travaillé sur l'éxécution du robot sur une zône prédéfinie?

J'imagine bien qu'il faille utiliser la méthode "app_zoned_clean" mais comment la mettre en oeuvre?

Des pistes ou solutions.....?

Partager ce message


Lien à poster
Partager sur d’autres sites

Ce n'est pas encore en place avec cette version.... ça viendra, mais plus tard.

Maintenant je travaille activement sur la migration de ma propre installation d'ici fin mai, donc les améliorations des QA existants, et futurs nouveaux QA, reprendront après.

  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites

J'ai pris le temps de regarder le debug au moment de la fin de l'aspiration et le retour à la base :

[10.05.2021] [18:38:57] [TRACE] [QA_ROBOROCK_195]: Vacuum is stopped

[10.05.2021] [18:38:57] [DEBUG] [QA_ROBOROCK_195]: Statut : Retour au dock

[10.05.2021] [18:38:57] [DEBUG] [QA_ROBOROCK_195]: Battery level is now 76%

[10.05.2021] [18:39:57] [DEBUG] [QA_ROBOROCK_195]: Statut : Chargement

[10.05.2021] [18:42:57] [DEBUG] [QA_ROBOROCK_195]: Total memory in use by Lua : 1372.20 KB

[10.05.2021] [18:43:57] [DEBUG] [QA_ROBOROCK_195]: Battery level is now 77%[10.05.2021] [18:45:57] [DEBUG] [QA_ROBOROCK_195]: Battery level is now 78%

 

Et le bouton est bien revenu en "OFF" cette fois ci.

Je continue à surveiller....

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Bien, donc tout va bien alors.
C'est le comportement de la dernière fois qui était surprenant.

Partager ce message


Lien à poster
Partager sur d’autres sites

×