Voir les logs dans Gladys interface

Bonsoir tout le monde,

message destiné avant tout à @pierre-gilles je pense mais chacun peut probablement dire ce qu’il en pense.

Etant un bidouilleur dans l’âme mais pas non plus un fou de la ligne de commande, je fais une petite proposition : pouvoir accéder aux logs de gladys directement depuis l’interface de gestion.
Dans SETTINGS > SYSTEM me paraîssant le plus approprié.

Est-ce que c’est envisageable ?

Bonsoir @guim31, si ça crash c’est pas côté UI que tu va pouvoir consulter et si gladys tourne normalement pas besoin de voir les logs.

Donc on est entre les deux ou alors c’est pour du dev.
J’ai peur 1ussi que l’utilisateur “lambda” ( rien de péjoratif) remonte des problèmes qui n’en sont pas.

Voilà mon avis perso :wink:

Oui je comprends très bien ton point de vue.
disons que là par exemple, moi je suis un lambda qui aimerait trouver ce qui cloche… Et je ne sais même pas comment consulter les logs de Gladys ! Haha la honte je sais, mais bon c’est comme ça.

Je pense que nous ne sommes pas à un point de développement de Gladys qui permette de se passer de ce genre de choses. Ou alors c’est trop chiant à intégrer / en rapport du bénéfice attendu. Et dams ce cas là va falloir que j’apprenne à consulter les logs en ssh :sweat_smile:

Eh non j’utilise Ubuntu :blush:

Le point a déjà été abordé. Forcément les avis divergent :slight_smile:
Il n’est pas prévu de l’accès aux logs depuis le front. Certes, c’est une bêta et ça permettrait de remonter facilement des infos pour les early adopters mais le point de vue de PG a l’époque me semblait tranché. Pas de logs dans le front. Les erreurs doivent être gérées et remontées sous forme de message intelligible à l’utilisateur.
Notre rôle en tant que bêta-testeur est de constater les dysfonctionnements et consulter les logs pour remonter l’info. Le rôle des développeurs est de prendre en compte le bug remonté et de le gérer.
Ca à côté frustrant, mais c’est un passage qui doit sûrement favoriser la disparition des erreurs non gérées → ce que l’on ne peut que souhaiter pour une version “bullet-proof”

2 Likes

Ouais… Là j’avoue que j’ai rien à répondre de mieux ^^ je comprends bien ce point de vue :+1:

Par contre ty dis que le point a déjà été abordé, mais je n’ai rien trouvé sur le forum… J’ai raté un truc ou c’était ailleurs ?

J’sais plus trop. P’t’etre bien le discord a l’époque, où bien le slack. Sais pu.

1 Like

Effectivement on en a parlé beaucoup sur le forum les dernières années :slight_smile: Mon avis reste le même!

Connais tu beaucoup de produits qui te demande de regarder les logs quand il y a un problème?

Perso, je n’en connais aucun :stuck_out_tongue: Quand ton smartphone rencontre un problème, il t’affiche une popup claire, pas un terminal noir avec des logs incompréhensible.

Pour l’instant on est encore en développement intensif de Gladys 4, donc effectivement certaines erreurs ne sont pas encore remontées dans l’UI, et je demande aux développeurs de me donner leurs logs pour améliorer le produit.

Après, l’objectif c’est que chaque erreur ait son message d’erreur dans l’UI, un message d’erreur clair, et qui donne à l’utilisateur la marche à suivre pour qu’il puisse résoudre son problème. Chaque développement se fait avec ces contraintes en tête!

J’avais écris quelques guidelines ici par rapport à cette gestion des erreurs dans l’UI:

1 Like

I was making a feature request and it suggested this topic to me.
So I’m digging this up :sauropod:
Here’s what I wrote:
It would be nice to have access to the logs in the Gladys interface.
A window where one could choose to see all logs, only statuses, or only errors.

My position hasn’t changed, see the last message :smiley:

I’m in favor of displaying contextual error messages in the right places (even showing the raw error when the error is unknown), but displaying the complete logs isn’t really Gladys’ philosophy.

Today in Gladys the topic has evolved a lot since we now have 2 patterns for surfacing errors in the interface:

  • When you’re in Gladys and you perform a « direct » action (add a camera, click a button, switch tabs, etc..), and there’s an error, we display the error in a blue/green/yellow/red badge depending on severity. Classic!

  • When a background task fails, we display the background task’s status and the error message in the « Background tasks » tab in settings:

Example of an error:

Now, this tab isn’t yet applied to all background tasks; the idea would be to add everything that runs in the background (scene execution, Gladys startup, etc..), so we can debug more easily.

1 Like

I was waiting for your opinion on the matter @pierre-gilles, so I went and checked the logs over SSH :wink:

I have an idea, I don’t know how good it is / if you’ve already thought of it: monitor the execution of scenes.
Because when you start having several that work together it’s sometimes tricky to keep track. One user (whose name I’ve forgotten, sorry) suggested sending Telegram messages as the scenes progress, but that’s quite tedious and it forces you to enable/disable those actions regularly.

Could we have some kind of « logs » for scenes, just something like:

2022-12-15 12:45:55 - Déclenchement de la scène ALLUMER LES LUMIERES
2022-12-15 12:56:44 - Déclenchement de la scène ALLUMER LE RADIATEUR
2022-12-15 12:45:55 - Arrêt de la scène SURVEILLANCE

I had also thought that on the scenes page, a scene currently running could be displayed differently (example here with a border around):

This solution is a bit more limited since some scenes execute in a few hundredths of a second ^^

So I wanted to get your opinion on the matter before opening a possible new thread / feature request.

1 Like

Read my message above again :smiley:

See:

1 Like

That’s what happens when you read too fast!! So I share this idea of tracking scene execution :wink:

1 Like