henri-allauch Posté(e) le 3 mai 2021 Signaler Posté(e) le 3 mai 2021 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
Lazer Posté(e) le 3 mai 2021 Auteur Signaler Posté(e) le 3 mai 2021 (modifié) C'est exactement pour cela que j'en ai parlé, je me doutais que ça allait faire réagir les développeurs 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é le 3 mai 2021 par Lazer 1
henri-allauch Posté(e) le 3 mai 2021 Signaler Posté(e) le 3 mai 2021 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
Lazer Posté(e) le 3 mai 2021 Auteur Signaler Posté(e) le 3 mai 2021 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 ???"
LMSI Posté(e) le 3 mai 2021 Signaler Posté(e) le 3 mai 2021 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.....?
Lazer Posté(e) le 3 mai 2021 Auteur Signaler Posté(e) le 3 mai 2021 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. 1
Dragoniacs Posté(e) le 10 mai 2021 Signaler Posté(e) le 10 mai 2021 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....
Lazer Posté(e) le 10 mai 2021 Auteur Signaler Posté(e) le 10 mai 2021 Bien, donc tout va bien alors. C'est le comportement de la dernière fois qui était surprenant.
ggenier Posté(e) le 25 juin 2021 Signaler Posté(e) le 25 juin 2021 Bonjour à tous, J'ai installé le QA sur une HC3 lite, désolé, je n'ai pas lu tous les posts, si vous avez indiqué que ce n'était pas possible. J'ai une erreur ligne 109 du sha2lib "at least 53-bit floating point numbers are required", je suis pas expert, mais à priori c'est pas lié mon install, mais plus à une version de lua. Est ce que vous ave une idée ? Je suis sur la version mise jour des fichiers. Merci d'avance.
Lazer Posté(e) le 25 juin 2021 Auteur Signaler Posté(e) le 25 juin 2021 Je pense que tu dois être le premier à tester ce QuickApp sur HC3 Lite.... j'ai la même impression que toi, ça semble provenir de LUA. Pas de la version, qui est surement la même, mais plutôt d'une limitation liée aux ressources disponibles, car il te dit qu'il a besoin de nombre flottants à plus de 53 bits, ce qui est assez énorme.... Malheureusement cela vient de la librairie sha2lib, donc la cryptographie, le code n'est pas de moi, je ne sais pas le débogguer.... C'est bien dommage ça, car la HC3 Lite serait finalement plus limitée qu'on ne le pensait au début.
Dragoniacs Posté(e) le 25 juin 2021 Signaler Posté(e) le 25 juin 2021 Peut être que@ADN182 a une idée ?Le VD était de lui il me semble....Envoyé de mon RMX1993 en utilisant Tapatalk
ggenier Posté(e) le 26 juin 2021 Signaler Posté(e) le 26 juin 2021 Lazer doit avoir raison. Le arm a53 de la hc3 est un 64bits. Le arm a7 de la hc3l est un 32 bits. Donc je suis niq** Je savais que j'allais devoir changer de box mais pas si tot
Lazer Posté(e) le 26 juin 2021 Auteur Signaler Posté(e) le 26 juin 2021 Effectivement, tu as mis le doigt dessus, une histoire de taille de bit.... Le VD et le QA n'ont aucune ligne LUA en commun, j'ai entièrement repris l'écriture à zéro. Sauf... la librairie qui gère la crypto, que ni moi ni @ADN182 ne maitrisons, elle provient d'Internet. Nous l'avons pris à des endroits différents, mais je pense qu'au final c'est bien le même auteur original. Perso j'ai utilisé la version packagée et testée par Tinman pour HC3.
juch11111 Posté(e) le 17 juillet 2021 Signaler Posté(e) le 17 juillet 2021 (modifié) Bonjour! J'ai le même problème - utilisateur @manuxenon. [17.07.2021] [23:49:31] [DEBUG] [QA_ROBOROCK_275]: Xiaomi:buildMiPacket("!1 �m`�Pj����������������", "{"id":3593,"method":"get_status","params":{}}") [17.07.2021] [23:49:31] [DEBUG] [QA_ROBOROCK_275]: Xiaomi:transmit() : sendTo() success [17.07.2021] [23:49:41] [ERROR] [QA_ROBOROCK_275]: Xiaomi:receive() : receive() error : Operation canceled [17.07.2021] [23:49:41] [ERROR] [QA_ROBOROCK_275]: Xiaomi:command() : Receive failed : Operation canceled [17.07.2021] [23:49:41] [ERROR] [QA_ROBOROCK_275]: Can't get vacuum status : Receive failed : Operation canceled [17.07.2021] [23:49:41] [TRACE] [QA_ROBOROCK_275]: Update label "LabelDebug" to "❌ Receive failed : Operation canceled ❌" Je ne suis pas capable d'y faire face. J'envoie les journaux. @Lazer Peut-être que vous pouvez aider quelque chose ? xiaomi log.txt Modifié le 17 juillet 2021 par juch11111
Lazer Posté(e) le 18 juillet 2021 Auteur Signaler Posté(e) le 18 juillet 2021 "Operation canceled" => Pas de réponse de l'aspirateur, c'est un problème réseau, il n'y a rien que je puisse faire, la HC3 non plus. Il faut que tu vérifies ton adresse IP, la qualité de la connexion Wi-Fi de ton aspirateur, etc. PS : merci pour le log, mais les fichiers portant l'extension TXT sont bloqués au téléchargement sur le forum, donc il faudrait que tu le renommes différemment.
juch11111 Posté(e) le 18 juillet 2021 Signaler Posté(e) le 18 juillet 2021 @Lazer Pas nécessairement. J'ai vérifié une autre fonction (miIO.info). Il fonctionne parfaitement. Tous les génériques fonctionnent (miIO.xxx). Je me demande si les commandes de ce robot aspirateur sont correctes. Les autres commandes fonctionnent - les données doivent être correctes (ip, port, token). Je vous renvoie le fichier texte. xiaomi log.lua
Lazer Posté(e) le 18 juillet 2021 Auteur Signaler Posté(e) le 18 juillet 2021 OK c'est plus clair, merci pour le log. Alors on voit bien qu'il commence à discuter, donc la communication réseau est OK. Puis.... plus de réponse.... Je vais étudier ça, mais plus tard, pas avant plusieurs jours.
juch11111 Posté(e) le 19 juillet 2021 Signaler Posté(e) le 19 juillet 2021 Ok. Je vais attendre. Je suis à court d'idées. La seule idée est : des commandes incorrectes ou une syntaxe de commande incorrecte.
Lazer Posté(e) le 19 juillet 2021 Auteur Signaler Posté(e) le 19 juillet 2021 Question : tu as bien installé la version 2.01 proposée dans le topic ?
juch11111 Posté(e) le 20 juillet 2021 Signaler Posté(e) le 20 juillet 2021 J'utilise la version 2.0 maintenant. Sur la 2.01, je pense que c'est encore pire. Très nombreuses erreurs. J'envoie les journaux de la 2.01 [20.07.2021] [08:50:02] [DEBUG] [QA_ROBOROCK_275]: Xiaomi:fetchMiPacket() : Hello packet, nothing to decrypt [20.07.2021] [08:50:02] [ERROR] [QA_ROBOROCK_275]: Xiaomi:command() : /usr/share/lua/5.3/json/decode.lua:74: bad argument #1 to 'match' (string expected, got boolean) [20.07.2021] [08:50:02] [ERROR] [QA_ROBOROCK_275]: /usr/share/lua/5.3/json/decode.lua:74: bad argument #1 to 'match' (string expected, got boolean) [20.07.2021] [08:51:02] [DEBUG] [QA_ROBOROCK_275]: loop(60) [20.07.2021] [08:51:02] [DEBUG] [QA_ROBOROCK_275]: Xiaomi:fetchMiPacket() : Header MD5 checksum : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [20.07.2021] [08:51:02] [DEBUG] [QA_ROBOROCK_275]: Xiaomi:fetchMiPacket() : Hello packet, nothing to decrypt [20.07.2021] [08:51:02] [DEBUG] [QA_ROBOROCK_275]: Xiaomi:buildMiPacket("!1 m`rU", "{"params":{},"id":10026,"method":"get_status"}") [20.07.2021] [08:51:02] [DEBUG] [QA_ROBOROCK_275]: Xiaomi:transmit() : sendTo() success [20.07.2021] [08:51:12] [ERROR] [QA_ROBOROCK_275]: Xiaomi:receive() : receive() error : Operation canceled [20.07.2021] [08:51:12] [ERROR] [QA_ROBOROCK_275]: Xiaomi:receive() : receive() error : Operation canceled [20.07.2021] [08:51:12] [ERROR] [QA_ROBOROCK_275]: Xiaomi:command() : Receive failed : Operation canceled [20.07.2021] [08:51:12] [ERROR] [QA_ROBOROCK_275]: Xiaomi:command() : Receive failed : Operation canceled [20.07.2021] [08:51:12] [ERROR] [QA_ROBOROCK_275]: Can't get vacuum status : Receive failed : Operation canceled [20.07.2021] [08:51:12] [TRACE] [QA_ROBOROCK_275]: Update label "LabelDebug" to "❌ Receive failed : Operation canceled ❌" [20.07.2021] [08:51:12] [ERROR] [QA_ROBOROCK_275]: Can't get vacuum status : Receive failed : Operation canceled [20.07.2021] [08:52:02] [DEBUG] [QA_ROBOROCK_275]: loop(60) Xiaomi log 2.01.lua
Lazer Posté(e) le 20 juillet 2021 Auteur Signaler Posté(e) le 20 juillet 2021 OK merci, voilà qui est mieux. J'étudierai ça plus tard. Tu as quel modèle d'aspirateur ? PS : pense toujours à commencer par faire la dernière mise à jour quand tu as un problème, règle valable pas uniquement pour la domotique, mais de façon générale pour n'importe quel sujet (ordinateur, téléphone, etc). Les mises à jour sont là pour corriger les bugs.
juch11111 Posté(e) le 20 juillet 2021 Signaler Posté(e) le 20 juillet 2021 Je m'en souviendrai. Merci. Mon robot aspirateur: ["dreame.vacuum.mc1808"] = "Xiaomi Vacuum 1C",
Lazer Posté(e) le 4 août 2021 Auteur Signaler Posté(e) le 4 août 2021 @juch11111 J'ai regardé ton fichier de log, le comportement de ton aspirateur est très étrange, il ne répond pas comme attendu. Rassures moi, tu n'as pas mis à jour que le fichier main, tu as aussi mis à jour le fichier Xiaomi en version 1.01 ? Parce que j'ai pas franchement l'impression.... Si oui, alors dans le fichier main, est-ce que peux essayer de commenter le paragraphe suivant entre les lignes 258 et 265, en ajoutant des balises de commentaires comme suit : --[[ Xiaomi:getFeatures({ success = function(result) tools:print("gray", "Vacuum features :", tools:tostring(result, true, true)) end, error = function(response) tools:error(response.message) end, }) --]] Puis tu relances le test, et tu captures les logs.
juch11111 Posté(e) le 7 août 2021 Signaler Posté(e) le 7 août 2021 (modifié) Merci pour votre aide. J'ai retéléchargé QA. J'ai changé les deux fichiers. Main et xiaomi. Malheureusement, cela ne fonctionne toujours pas. J'envoie des journaux avec des commentaires sur la partie (log comment.lua.lua) et le tout (log uncomment.lua). Pour confirmation, je télécharge mon QA, que j'ai sur mon panneau de contrôle. (Xiaomi_Vaccum.fqa) Modifié le 7 août 2021 par juch11111 Enlever le token
Lazer Posté(e) le 16 août 2021 Auteur Signaler Posté(e) le 16 août 2021 Salut @juch11111 J'ai vérifié ton QuickApp, donc tu as bien la dernière version. J'ai regardé tes 2 fichiers de logs, et toujours pas de réponse de l'aspirateur, il ne répond qu'à la première commande "miIO.info", puis après plus rien. Il faut savoir que mon QuickApp utilise l'API Xiaomi Mi-Home, décrite sur cette page : https://github.com/marcelrv/XiaomiRobotVacuumProtocol Entre temps, l'auteur à mis à jour sa documentation, tout récemment, il y a 5 jours, avec des nouvelles informations intéressantes. Il précise la liste des appareils supportés, et le tien ne figure pas dans la liste. Par ailleurs, il précise tout en bas du document que tous les appareils Xiaomi Mi (Home et non-Home) répondent à l'instruction "miIO.info" et quelques autres, mais c'est tout. Donc avec ton aspirateur, on est en plein dans le cas de figure de l'appareil qui répond à ces quelques commandes génériques, mais pas à toutes les autres commandes du protocole Xiaomi Mi-Home. Donc le comportement de ton aspirateur est cohérent avec ce qui est documenté. Malheureusement pour toi, je ne peux plus rien faire à ce niveau là... si l'API exploitée par ton aspirateur est différente de Mi-Home, il faudrait commencer par trouver une documentation qui décrit le protocole utilisé par ton modèle d'aspirateur. Sachant qu'à ma connaissance, Xiaomi ne publie aucune documentation officielle sur ses API. Les documents disponibles en ligne ont été rédigés à partir de reverse engineering.
Messages recommandés