J’ai cherché un peu et je vois que la mise en forme s’appelle log highlight.
Le rendu tel que ce programme le fait me semble suffisant et clair :
On voit le text qui est mis en valeur, INFO et ERROR aussi.
Le log semble lisible.
Il est indiqué dans les 1er msg il me semble …!? 
Oui, je l’ai vu.
Mais c’est pour recentrer la discussion et éviter de chercher à faire des logs colorés pour faire joli mais qui ne répondent pas au besoin initial de refaire apparaître le formatage des logs.
Edit : je viens de relire de nouveau le 1ᵉʳ post.
« les tags HTML ne sont plus interpretés dans les logs non brut. »
Pour moi, c’est une faille de sécurité et l’interpretation ne devrait pas être fait du tout.
Ce que fait Jeedom aujourd’hui en v4.4 est tout simplement normal, en tout cas sécurisé.
Bonjour à tous,
Si je peux donner mon avis, je me demande pourquoi faire autant pour des fichiers de logs ?
Dans le sens : l’utilisateur lambda n’ira jamais les regarder, sauf lorsqu’il aura un problème, et comme cela a déjà été dit plus haut, le seul que cela va intéresser c’est le dev du plugin ou bien celui qui va aider pour résoudre un problème, et dans ce cas il ne sera pas sur l’interface de jeedom, mais sur le Community à travers des balises pré formatées, et à ce moment, on veut juste que ce soit le plus lisible possible.
Si on veut pleins de couleurs, il suffit de copier les logs et les mettre dans un log parseur et ce sera Noël 
Et effectivement si on envoie ces logs dans un syslog, est ce que cela ne va pas perturber l’intégration?
Et je ne parle même pas de la sécurité, car on sait tous qu’à partir du moment où il y a des balises, il y a des petits malins pour les détourner, quelle que soit la technique employée.
Perso, ce que j’utilise pour plus dans l’interface des logs, c’est le filtre par mot clé, ça c’est essentiel pour moi pour retrouver un message particulier au milieu de toutes les lignes.
Après comme proposé aussi, juste le coloriage en non brut de mots clés comme OK, KO ou ERROR pourrait éventuellement aider. Ou sinon au même endroit que le filtre, la possibilité d’highlighter un mot clé par exemple en rouge (sans le filtrer du coup mais juste en le coloriant) pourrait dans certains cas être pratique aussi.
Mais pas plus, au risque d’alourdir le tout et de ralentir jeedom (car il faut les traiter toutes ces lignes malgré)
Bonne journée à tous.
TiTidom.
1 « J'aime »
Hello,
Bien sûr les logs sont là pour les dev, mais aussi pour les utilisateurs! Je ne compte pas le nombre de plugins qui disent que les dépendances sont installées correctement et qui contiennent des erreurs !
Dans mes plugins j’ai fait une librairie bash qui vérifie le code retour des commandes et donc s’il est indiqué à la fin que tout s’est bien passé c’est que tout s’est bien passé ! S’il y a des erreurs elles sont toutes reprises à la fin avec la ligne de l’erreur et la commande fautive + l’erreur.
Le code couleur d’un OK ou un KO ou Erreur ou Error sont importants (je trouve) afin que l’utilisateur même néophyte puisse voir d’un seul coup d’œil si l’installation des dépendances sont fautives ou pas, au lieu de les relancer plusieurs fois comme un idiot. Je trouve aussi que jeedom devrait prendre en compte le code de retour du fichier d’installation des dépendances. (Qu’on ne me dise pas que c’est le rôle de dependancy_info il est mis en cache !)
Pas besoin de plus d’infos que ok ou ko pour moi, à la limite un warning (debian 9 → il serait temps de mettre à jour !)
On a peut être pas besoin de tout un système de notation en effet.
D’où l’idée soit de compléter les deux array deja présents dans le core et de documenter et faire une norme, sois de laisser l’opportunité d’ajouter ses propre mots à chaque plugin
1 « J'aime »
J’avais déjà vu ça et j’en profite pour un 2ème hors sujet: hésites pas à faire une petit guide/tuto pour nous, j’intégrerais bien ce que tu as fait 
Complètement d’accord.
Pour répéter mon avis: Je suis pour qu’à l’affichage l’interface tente (avec beaucoup de précaution) de mettre en évidence les erreurs etc mais moi je ne rajouterai pas de tag de formattage spécifique dans mes logs (mais ca n’empêche pas que la fonction peut exister si d’autres y voient un intérêt évidemment)
J’avais déjà lu ta proposition mais je ne maîtrise pas assez cette histoire d’array dans le core pour pouvoir donner un avis;
j’ai flag ton post pour pouvoir le relire avec le code à côté (je ferai ça demain je pense)
Completement d accord +1 !
Normalement tout est dans le readme : GitHub - NebzHB/dependance.lib
je l’ai implémentée dans plugin-jmqtt et plugin-atvremote aussi si besoin d’exemples
Demande si tu as un problème
@Bad a donné l’extrait en question plus haut
1 « J'aime »
Alors ce serait plutôt bg- et fg- pour background et foreground ?
Mais à la vue des derniers post, je me demande si ajouter des tags est vraiment la bonne solution…
Je l’ai identifié aussi et (à priori) j’ai déjà le fix dans le buffer de vscode
Ok, mais je ne vais pas alourdir le Core si personne ne s’en sert… (après c’est pas très très lourd)
Yes I did, cf PR : 
Faster and less bandwidth consuming logs display by BadWolf42 · Pull Request #2224 · jeedom/core · GitHub
Ca commence à faire beaucoup de méthodes de classes et je ne suis pas sur qu’on arrive facilement a identifier la classe par le nom du fichier de log. Je serais plus d’avis de partir sur une coloration comme évoqué par @Arnaud_69 (tailspin) et d’ajouter dans le Core les regex essentielles.
Ca aura la même lisibilité qu’aujourd’hui avec du HTML dedans, mais dans le fond tu as raison.
En fait, le besoin initial est plus de colorer [ OK ] en vert que d’avoir des tags, non ?
On est certainement tous en phase là dessus.
Je note, bonne idée, à voir s’il faut réaliser.
Historiquement (v4.3) Jeedom charge tout le fichier à chaque reload (toutes les 3-5s), plus maintenant, donc on a vraiment de la marge.
TiTidom, je n’ai pas repris les autres points de ton message, mais pense avoir répondu ou donné mon avis dans ce message.
[EDIT] : Vous aurez notés que je n’ai pas parlé de l’utilité ou non de coloriser les logs. Mon parti (peut-être un peu tranché) est que souvent les utilisateurs font une capture d’écran des logs, avant qu’on ne soit obligé de leur demande les logs bruts. Autant déjà avoir un peu de coloration à ce moment-là, pour faire une première mini-analyse, voir même que l’utilisateur ait l’erreur devant les yeux toute suite.
Donc en résumé :
- Interdire tous codes HTML dans les logs (unanimité),
- Ajouter des « mots clés » à highlighter dans le Core (à voir lesquels),
- Tags perso dans les logs pour le highlighting (divergence),
- Un plugin propose ses règles de highlighting via un classmethod (compliqué → HS ici),
- Ajouter un champ de recherche sans filtrage (assez simple → autre PR),
- Ajouter un champ Copier le log (simple JS → autre PR),
- Corriger la recherche → TODO, peut-être dans le même PR,
- Autre chose que j’ai loupé ?
Bad
4 « J'aime »
Hello,
Voici pour la 4.4: 🔨 Better log highlighting by BadWolf42 · Pull Request #2369 · jeedom/core · GitHub
Le portage complet en 4.3 est trop complexe pour être vu comme une simple « correction »…
J’ai juste interdit l’interprétation du HTML dans les logs (pour que les plugins puissent de préparer à la 4.4) et corrigé les problèmes de « style » ou de « qualité du code » que j’avais déjà aperçu en 4.4.
C’est ici : Backport fixes from #2369 by BadWolf42 · Pull Request #2370 · jeedom/core · GitHub
Bad
Hello @nebz,
Peux-tu tester la dernière alpha ? Quelques captures d’écran :
- deps jMQTT en coloré et brut :
- http.error :
- update :
- scenario :
- recherche avec mise en surbrillance :
Enjoy
1 « J'aime »
Hello, j’ai que la beta et elle plante dès que je veux la mettre à jour, pas encore eu le temps de m’y plonger…
mais dans ton changelog je vois pas d’info pour [ OK ] pourtant…
ah si dans ton code c’est ok
Au temps pour moi, updated !
Les règles de remplacement sont ici :
(Ne tenez pas compte du <&>, c’est une « bulle » pour éviter de remplacer plusieurs fois le même texte)
1 « J'aime »
je viens de tester en alpha, nickel ça donne bien et rapide !
2 « J'aime »
Testé aussi, 
.
Merci Bad.
2 « J'aime »
Il y a peut être quand même des effets de bord : Problème d'affichage dans les log scénario, à surveiller.
Non 4.3.21
En revanche le css des scénarios n’est pas préparé pour le span :
J’ai modifié le css comme ceci :
#pre_scenariolog label {
height: 8px;
}
#pre_scenariolog span {
min-width: 60px;
}
et cela semble être ok.
Salut,
Je viens de tester en 4.4.5 Beta de mettre en couleur certains background de zone de texte des logs avec :bg-success: :bg-warning: :bg-info: et :bg-danger:
Le background n’est pas aligné verticalement.
en ajoutant comme pour les autres label-xs cela devient plus lisible.
$search[] = ':bg-success:'; $replace[] = '<span class="label label-xs label-success">';
$search[] = ':bg-info:'; $replace[] = '<span class="label label-xs label-info">';
$search[] = ':bg-warning:'; $replace[] = '<span class="label label-xs label-warning">';
$search[] = ':bg-danger:'; $replace[] = '<span class="label label-xs label-danger">';
Hello,
label est plus gros normalement, mais là, il est contraint par un height: 12px;, je suis du même avis que toi, ajouter la class label-xs, cela permet d’avoir des log plus harmonieux.