API - debugMessages

[jjacques68 602]

Hello tout le monde !

 

j'utilise depuis le début de la HC3 l'API "debugMessages", afin de récupérer les messages (debug, trace, warning, error) pour les insérer en base.

Je me suis rendu compte que je loupais de temps en temps des infos.

 

Voici le panel de l'API : 

 

alors il faut savoir que si on met rien dans le paramètre "offset" il nous retourne que les 30 derniers... (d'où mes loupés... ... ...)

 

En fait, je souhaite tout simplement, à chaque fois que j'interroge l'API, récupérer tous les messages depuis la dernière interrogation.

 

Là j'arrive à faire ce que je veux avec : 

local MonContenu = api.get("/debugMessages?from="..self.lastCheck.."&last=0&offset=200").messages

 

Mais j'ai du faire une usine à gaz de code pour arrivé à mes fins :

 

A chaque boucle, je mémorise le timestamp du 1er message ainsi que son ID (attention le premier message est le plus récent)

ensuite pour la prochaine interrogation, j'utilise le paramètre "from" dans lequel je lui glisse le memo du timeStamp précédent.

ça marche très bien, sauf qu'il m'inclus dans la requête, CE memo du timeStamp (c'est clairement stipulé !! - younger than or equal)

Donc j'ai des doublons maintenant.

 

j'ai mis le paramètre "last" à 0. Sa définition est pas très clair...

 

et le paramètre "offset" à 200. Le valeur -1 qui m'intéresserait ne marche pas. il comprends "1" !!

 

Donc en français ça donne : je récupère les 200 derniers nouveau messages depuis le timeStamp mémorisé.

 

et pour virer les doublons, si l'ID du message en en cours <= l'ID mémorisée alors je l'oublie.

 

Mais ce serait tellement plus simple de pouvoir récupérer les messages dont l'ID est supérieur à la valeur donnée !!!

Ce que devrait faire le paramètre "last", sauf que si on lui donne une valeur, il renvoie les messages inférieurs à cette valeur !!!

 

Je me plante complètement de raisonnement, où y a des loups cachés qqpart ??  

 

Ensuite quand on observe le JSON de réponse, il y a cette info : 

 

Quelqu'un a une idée de ce que c'est ?

C'est un ID c'est sûr, mais je n'arrive jamais à voir le message correpsondant à cet ID ??

 

merci pour vos conseils !!!

 

 

PS pour ceux que ça intéressent voici le code de la fonction dans mon QA :

 

function QuickApp:Check()

    if self.properties.value == true then 
    
        --recupère les data de l'API
        local MonContenu = api.get("/debugMessages?from="..self.lastCheck.."&last=0&offset=200").messages

        --pour chaque ligne
        for MaLigne = 1, #MonContenu do

            --si on trouve des ID inférieur au mémo alors on oublie (= doublon)
            if MonContenu[MaLigne].id <= self.memoID then break end

            --créé la chaine pour envoyer sur la socket
            local MaData = os.date("%d/%m/%Y %H:%M:%S", MonContenu[MaLigne].timestamp)..";"..
                        MonContenu[MaLigne].id..";"..
                        MonContenu[MaLigne].type..";"..
                        MonContenu[MaLigne].tag..";"..
                        json.encode(MonContenu[MaLigne].message)

            --l'envoie en base
            fibaro.call(487,"AddElement", "LOG;"..MaData)
            
            --envoi des erreur par mail si option activée
            if MonContenu[MaLigne].type == 'error' and self:getVariable("SendError") == "1" then fibaro.call(457, "SendMail", MaData) end
        end

        --mémorise les infos pour la prochaine boucle (l'élément 1 du tableau sera le dernier élément lors de la prochaine boucle)
        self.lastCheck = MonContenu[1].timestamp
        self.memoID = MonContenu[1].id
                
    end   

    --bouclage
    setTimeout(function() self:Check() end, tonumber(self.TimeLoop))
end

 

[Lazer 8 477]

Je ne sais pas si tu as vu, mais plutôt que de passer par l'API debugMessage, tu peux aussi utiliser l'API refreshStates.

 

Il y au paramètre optionnel logs=true qui permet de voir passer tous les messages.

Et cette API fonctionne très bien, il suffit de mettre le paramètre last=.... à la dernière valeur récupérée lors de l'interrogation précédente (il suffit de mettre 0 lors de la première interrogation)

 

/api/refreshStates?last=405142&logs=true

 

Il suffit ensuite de parcourir le champ logs :

 

 

A mon avis c'est pareil pour debugMessages, il suffit de mettre last=... à la dernière valeur récupérée dans nextLast (pas testé)

[jjacques68 602]

il y a 7 minutes, Lazer a dit :

tu peux aussi utiliser l'API refreshStates

ooooh mais c'est interessant ça, je savais pas !

 

je savais pas ! 

si je peux tout réunir dans le refreshState, c'est mieux !

 

merci du tuyaux !!  

[Lazer 8 477]

yes, c'est une super API refreshStates

 

Bon j'ai pas réussi à utiliser last dans debugMessages, tu as raison, au lieu de renvoyer les messages plus récents, ils renvoie les plus anciens... bref ça ne sert à rien... c'est juste probablement buggué.

[jjacques68 602]

mouai, c'est un peu étrange debugMessage...

 

Par contre j'espère que mon script qui analyse le resfreshState ne va pas finir par ramer...

Parce qu'il commence à faire vraiment beaucoup de chose...

[jjacques68 602]

Bon ben ça y est, j'utilise du coup l'API refreshStates pour récupérer les log !

ça marche nickel  

et beaucoup moins pénible à utiliser que debugMessage.

 

merci pour le conseil !

 

Par contre phénomène étrange mais qui semble logique : et j'ai du mal à l'expliquer :

 

si tu affiches dans le debug un log que tu viens d'intercepter, ben ça tourne en rond !

en gros y a un log qui passe.

tu affiches log pour debug.

donc forcément il repasse dans le log.

donc forcément tu le ré-affiches.

donc ... le même log peut s'afficher à l'infini et a une vitesse dans mon cas de 25 ms (boucle d'interrogation de l'API).

[Lazer 8 477]

Toi tu cherches les ennuis, et ensuite tu vas te plaindre de bouffer du CPU

[jjacques68 602]

 nan mais faut juste le savoir quoi  

niveau CPU ça va toujours bien :