Krikroff Posté(e) le 10 avril 2020 Signaler Posté(e) le 10 avril 2020 La nouvelle console de débogage est introduite avec la mise à jour 5.030.45 du 09/04/2020 La documentation officielle "Quick App" c'est ici: Home Center 3 – Quick Apps Cette nouvelle console principale permet d’agréger l'ensemble des messages poussés par les méthodes "print", "debug", "trace", "warning", "error", qu'ils soient émis d'une scène ou bien encore d'un Quick App mais également les notifications z-wave, l'ajout ou la suppression de modules Elle est accessible à tout moment via le bouton dédié en bas à gauche. L'ouverture présente la console en bas de page de la manière suivante: Il est possible de l'ouvrir en mode "standalone" à l'aide du bouton très utile et efficace si l'on possède un double écran Bien entendu avec la possibilité de filtrer sur les enregistrements afin d'affiner une recherche. Par exemple: je veux afficher uniquement les messages du type "DEBUG" et "WARNING" pour le QA1 et la scene 2 et mettre un focus sur le mot "Callback". Cela peut donner ceci: Cela peut paraître déroutant au début mais c'est ultra efficace notamment pour suivre les interactions entre plusieurs Quick App ou encore lorsque une scène exécute un call sur un Quick App etc.. LES MÉTHODES: Dans un Quick App les méthodes suivantes seront utilisées pour pousser des messages dans la console: self:trace(message, ...) self:warning(message, ...) self:debug(message, ...) self:error(message, ...) print(...) A noter: Le print correspond à un debug, pas besoin ici de passer un libellé pour l'étiquette. Dans une scène il faut utiliser fibaro.debug(tag, message, ...) fibaro.trace(tag, message, ...) fibaro.warning(tag, message, ...) fibaro.error(tag, message, ...) print(...) A noter: Pour le moment dans une scène il faut préciser le nom de l'étiquette (proposé par défaut par l'auto-complétion de l'éditeur LUA ). Le print correspond à un debug, pas besoin ici de passer un libellé pour l'étiquette. Exemple: L'action fibaro.trace("Scene18", "Ceci est un message de type ", "**TRACE**") sortira dans la console: LES FILTRES: Pour le focus sur des mots dans les résultats : Les étiquettes: Par défaut dans un Quick App une étiquette porte automatiquement (par convention de nommage) le libellé suivant: QUICKAPP000000 ou "000000" correspond à l' ID du périphérique. Cette valeur étant stockée dans une variable accessible dans l’environnement du QA (scope et hors-scope) il est donc parfaitement possible de personnaliser le libellé, de la manière suivante: -- Ici un nom customisé tout en conservant l' ID du device __TAG = "NOM_DE_MON_QA_"..plugin.mainDeviceId Attention: ceci n'est pas encore possible dans une scène, la variable __TAB n'étant pas accessible (une demande est en cours). Pour le filtrage sur les différentes étiquettes: Remarques (à venir dans une prochaine version): Lorsque la console est ouverte depuis une QA le filtrage est alors réalisé par défaut sur les messages de device concerné Lorsque la console est ouverte depuis une scène le filtrage est alors réalisé par défaut sur les messages de la scène concernée Les types : Pour le filtrage sur les différents types de messages: Le bouton "RESET" permet de réinitialiser l’ensemble des filtres, à côté pour refermer la console lorsqu'elle est en mode standalone. Remarques: Les données sont purgées régulièrement Lorsque la console est ouverture depuis la page principale le filtrage est alors réalisé par défaut sur les messages du type "Z-WAVE" (à venir dans une prochaine version) 4
Krikroff Posté(e) le 10 avril 2020 Auteur Signaler Posté(e) le 10 avril 2020 Pour aller plus loin sur le sujet: ou encore A suivre... 1
jjacques68 Posté(e) le 10 avril 2020 Signaler Posté(e) le 10 avril 2020 Il y a 10 heures, Krikroff a dit : A confirmer mais les données sont très certainement purgées régulièrement oui je confirme... en même temps ça défile pas mal !! mais y aurait-il un moyen d'intercepter n'importe quel ajout dans le debug, pour peut-être le stocker dans une base de donnée annexe ?
Krikroff Posté(e) le 10 avril 2020 Auteur Signaler Posté(e) le 10 avril 2020 Ce n'est pas possible de faire cela nativement, tu es prêt à faire chauffer ton clavier ? 1
jjacques68 Posté(e) le 10 avril 2020 Signaler Posté(e) le 10 avril 2020 ben, nativement je m'en doute Mais y a bien une table dans l'API que l'on pourrait checker toutes les X temps, et envoyer les data sur une socket pour y être stocker en base... Mais je vois pas ça dans l'API
Krikroff Posté(e) le 10 avril 2020 Auteur Signaler Posté(e) le 10 avril 2020 J'ai des réponses mais vraiment un intérêt de tout intercepter pour envoyer en base ? Pas de messages cachés, je me pose réellement la question
Krikroff Posté(e) le 10 avril 2020 Auteur Signaler Posté(e) le 10 avril 2020 Sujet mis à jour avec quelques ajustements: Remarques (à venir dans une prochaine version): Lorsque la console est ouverte depuis une QA le filtrage est alors réalisé par défaut sur les messages de device concerné Lorsque la console est ouverte depuis une scène le filtrage est alors réalisé par défaut sur les messages de la scène concernée Lorsque la console est ouverture depuis la page principale le filtrage est alors réalisé par défaut sur les messages du type "Z-WAVE" Sera corrigé dans une prochaine version: le passage en mode "standalone" ne conserve pas les filtres sélectionnés dans le mode bas de page.
jjacques68 Posté(e) le 10 avril 2020 Signaler Posté(e) le 10 avril 2020 ben déjà sur la HC2 j’avais mis en place un système, mais fais maison, donc dans chaque VD et scène. j’avais une instruction qui me permettais d’envoyer ce que je voulais dans une base HFSQL (windev). ça passait via une socket sur un petit soft installé sur un PC, qui ajoutait tout ce que je voulais en base. c’était « mon » historique quoi ! et j’avoue que je m’en suis servi plus d’une fois pour retrouver ce qu’il s’est passé...
jjacques68 Posté(e) le 10 avril 2020 Signaler Posté(e) le 10 avril 2020 (modifié) ah punaise ! si !! dans l’api, il y a : debugMessage... Modifié le 10 avril 2020 par jjacques68
jjacques68 Posté(e) le 10 avril 2020 Signaler Posté(e) le 10 avril 2020 ben c’est pas mal ça ! on peut lire, et supprimer ! roaaa, le clavier va chauffer oui en effet !!
jjacques68 Posté(e) le 10 avril 2020 Signaler Posté(e) le 10 avril 2020 c’est dommage on a pas le changement de status des device...
Krikroff Posté(e) le 10 avril 2020 Auteur Signaler Posté(e) le 10 avril 2020 Pour les changements sur les devices il faudrait utiliser une autre méthode (cf. /api/refreshStates) mais je te conseille déjà de voir ce que tu peux faire avec le EndPoint "/debugMessages"
jjacques68 Posté(e) le 10 avril 2020 Signaler Posté(e) le 10 avril 2020 (modifié) Bon ben voilà : function QuickApp:Check() --recupère les data de l'API local MonContenu = api.get("/debugMessages").messages --pour chaque ligne local MaData = "" for index, MaLigne in pairs(MonContenu) do --créé la chaine MaData = os.date("%d/%m/%Y %H:%M:%S", MaLigne.timestamp)..";".. MaLigne.id..";".. MaLigne.type..";".. MaLigne.tag..";".. json.encode(MaLigne.message) --l'envoie en base fibaro.call(487,"AddElement", "LOG;"..MaData) end --purge l'API que après le traitement sinon il y a redondance d'informations --car chaque ajout en base met une trace dans le debug... api.delete("/debugMessages") --relance que si le QA est activé if fibaro.getValue(plugin.mainDeviceId, "value") == true then fibaro.setTimeout(tonumber(self.TimeLoop)*1000, function() self:Check() end) end end c'est nickel !! Je range tout en base : rien à voir... Mais j'ai toujours et encore de soucis avec les sockets !! Toujours ce problème de reconnexion !! C'est pas clair ! et pas normal !! Suis obligé de relancer le QA quand ça arrive ! Modifié le 10 avril 2020 par jjacques68
Krikroff Posté(e) le 10 avril 2020 Auteur Signaler Posté(e) le 10 avril 2020 Bien joué, c'est quoi ton call ? fibaro.call(487,"AddElement", "LOG;"..MaData) H.S: pour ton histoire de socket je te propose de continuer sur ton sujet dédié
jjacques68 Posté(e) le 10 avril 2020 Signaler Posté(e) le 10 avril 2020 Ce call est une méthode d'un QA qui me permet d'envoyer la trame sur la socket. Même principe que l'on avait déjà abordé, j'ai un buffer pour faire du FIFO... histoire de pas perdre de trames... Donc le "AddElement" permet de remplir le buffer. le flag "LOG" me permet, dans le soft qui reçoit les données, d'identifier justement la trame. Je peux en avoir une autre, comme par exemple : je mémorise le compteur d'eau journalier avec la trame "EAU;123456789". Donc selon le flag, j'enregistre les données dans telle ou telle base de données. J'ai une socket pour remplir plusieurs bases (du moins 2 pour le moment). Pour info, notre histoire de socket précédente, portait sur un autre système, avec un autre logiciel, avec une autre socket, qui est que de l'IHM pur... Pas tout mélanger quand même Et je rencontre le même problème pour les 2 sockets... mais : il y a 3 minutes, Krikroff a dit : H.S: pour ton histoire de socket je te propose de continuer sur ton sujet dédié oui tout à fait, je vais encore faire des essais et je reviendrais sur le bon topic
schwinny Posté(e) le 10 avril 2020 Signaler Posté(e) le 10 avril 2020 Les sockets, c'est pour avoir chaud aux pieds non ? 1 1
jjacques68 Posté(e) le 10 avril 2020 Signaler Posté(e) le 10 avril 2020 ouah !! plus de 20 000 enregistrements en 7 heures !! hé bé... ça travaille sévère la dedans...
Krikroff Posté(e) le 10 avril 2020 Auteur Signaler Posté(e) le 10 avril 2020 Il y a 5 heures, jjacques68 a dit : Ce call est une méthode d'un QA qui me permet d'envoyer la trame sur la socket. Je me doutais bien de cela mais pourquoi ne pas avoir simplement gérer le socket dans le QA porteur du check ? il y a 24 minutes, jjacques68 a dit : plus de 20 000 enregistrements en 7 heures !! .. d'ou le fait que je me pose réellement la question Il y a 6 heures, jjacques68 a dit : --purge l'API que après le traitement sinon il y a redondance d'informations --car chaque ajout en base met une trace dans le debug... api.delete("/debugMessages") Tu n'aurais pas des self:debug ou des print dans ton autre QA ?
jjacques68 Posté(e) le 11 avril 2020 Signaler Posté(e) le 11 avril 2020 Il y a 7 heures, Krikroff a dit : pourquoi ne pas avoir simplement gérer le socket dans le QA porteur du check ? car cette socket est utilisée par d’autre QA également Il y a 7 heures, Krikroff a dit : self:debug ou des print dans ton autre QA non, mais le simple fait d’appeler une méthode, ajoute systématiquement une ligne (pour tous les QA d’ailleurs) Et comme l’argument que je passe n’est ni plus ni point que le debug lui-même, ça fait de la redondance... Je sais pas si je me fais comprendre...
jjacques68 Posté(e) le 11 avril 2020 Signaler Posté(e) le 11 avril 2020 Il y a 8 heures, Krikroff a dit : d'ou le fait que je me pose réellement la question en fait l'historique est très faible, si on souhaite voir si y a eu des erreurs il y a quelques heures, c'est mort !!! on les retrouve plus !!
Krikroff Posté(e) le 11 avril 2020 Auteur Signaler Posté(e) le 11 avril 2020 Tu as parfaitement raison nous sommes d’accord pour l’historique Oui oui je sais bien qu’un appel sur un QA déclenche un message . Juste que je ne suis pas persuadé que la solution retenue soit la plus performante, après ça fonctionne alors...Envoyé de mon iPhone en utilisant Tapatalk
jjacques68 Posté(e) le 11 avril 2020 Signaler Posté(e) le 11 avril 2020 nan mais je peux enventuellement mettre des filtres... A voir dans le temps... prochaine étape, l'historique des device....
jjacques68 Posté(e) le 11 avril 2020 Signaler Posté(e) le 11 avril 2020 Le 10/04/2020 à 13:39, Krikroff a dit : Pour les changements sur les devices il faudrait utiliser une autre méthode (cf. /api/refreshStates) j'y suis parvenu avec panels/event...
Krikroff Posté(e) le 11 avril 2020 Auteur Signaler Posté(e) le 11 avril 2020 Parfait Envoyé de mon iPhone en utilisant Tapatalk
Messages recommandés