Aller au contenu

Console de débogage

Krikroff

Par Krikroff
dans Support

 Partager

Messages recommandés

Krikroff Newbie

Krikroff

Posté(e)
Posté(e)

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

 

image.png.f66a1047873ff8f264d5bce35a023913.png

 

Elle est accessible à tout moment via le bouton dédié en bas à gauche. image.png.99795194af5079b1b506ffc1f71144d8.png


L'ouverture présente la console en bas de page de la manière suivante:

 

image.thumb.png.436526ca51b7fe061a1ef621e446527c.png

 

Il est possible de l'ouvrir en mode "standalone" à l'aide du bouton image.png.f3818e9001b214fe471314c472974eeb.png 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: 

 

image.thumb.png.546e105d4b8cd1529c6514e68dfc8c9b.png

 

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:

 

image.png.292201191d627e0b68141237f6b43f47.png

 

 

LES FILTRES:

 

Pour le focus sur des mots dans les résultats :

 

image.png.49ae856a82706d5d618d1fd098e5f5f3.png

 

 

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:

 

image.png.c33a336124781812f4636ae3c3d1a082.png

 

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:

 

image.png.9881a48210fe3fcd66977b50711eb704.png

 

Le bouton "RESET" permet de réinitialiser l’ensemble des filtres, à côté pour refermer la console lorsqu'elle est en mode standalone.

 

image.png.0f58d8713a4a39c84060796c1d3d8864.png

 


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)

image.png

image.png

  • Like 4
Lien vers le commentaire
Partager sur d’autres sites
jjacques68 Contributor

jjacques68

Posté(e)
Posté(e)
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 ?

Lien vers le commentaire
Partager sur d’autres sites
Krikroff Newbie

Krikroff

Posté(e)
  • Auteur
Posté(e)

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 ;)

 

Lien vers le commentaire
Partager sur d’autres sites
Krikroff Newbie

Krikroff

Posté(e)
  • Auteur
Posté(e)

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.

Lien vers le commentaire
Partager sur d’autres sites
jjacques68 Contributor

jjacques68

Posté(e)
Posté(e)

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é...

Lien vers le commentaire
Partager sur d’autres sites
Krikroff Newbie

Krikroff

Posté(e)
  • Auteur
Posté(e)

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" 

Lien vers le commentaire
Partager sur d’autres sites
jjacques68 Contributor

jjacques68

Posté(e)
Posté(e) (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 !! :60:

 

Je range tout en base : 

 

image.thumb.png.bd354c57325d503ca60a4aeaaeda3762.png

 

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 !! :15:

Suis obligé de relancer le QA quand ça arrive !

Modifié par jjacques68
Lien vers le commentaire
Partager sur d’autres sites
Krikroff Newbie

Krikroff

Posté(e)
  • Auteur
Posté(e)

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é ;)

 

Lien vers le commentaire
Partager sur d’autres sites
jjacques68 Contributor

jjacques68

Posté(e)
Posté(e)

 

 

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

 

 

 

Lien vers le commentaire
Partager sur d’autres sites
Krikroff Newbie

Krikroff

Posté(e)
  • Auteur
Posté(e)
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 ?

Lien vers le commentaire
Partager sur d’autres sites
jjacques68 Contributor

jjacques68

Posté(e)
Posté(e)
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... :) 

Lien vers le commentaire
Partager sur d’autres sites
Krikroff Newbie

Krikroff

Posté(e)
  • Auteur
Posté(e)

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

Lien vers le commentaire
Partager sur d’autres sites
 Partager
Aller sur la liste des sujets
×
×
  • Créer...