Je cherche à faire quelque chose sans y parvenir, j’en appelle donc à la communauté voir si quelqu’un à déja tenté le truc
J’ai certains scénarios qui se lancent assez régulièrement, par exemple toutes les 10 minutes.
Sur ce type de scénario, je désactive généralement les logs du scénario pour plusieurs raisons
économiser les écritures sur le disque (je suis pour l’instant sur carte SD je pense passer sur un SSD au prochain upgrade de ma config).
éviter d’écrire des logs pour rien car vu la verbosité et la rotation, je risque de ne pas retrouver les logs dont j’ai besoin car ils risquent d’avoir déja été écrasés …
Par contre quand je debugge j’aime bien avoir les logs
Donc souvent quand je retouche mes scénarios, je les lance manuellement et je regarde le log pour voir ce que ça à donné. Pour pouvoir faire ça il faut à chaque fois que je réactive le log, que je sauvegarde, que je fasse mes modifs et que je teste et qu’à la fin je pense à désactiver de nouveau les logs …
Ce que j’aurais aimé faire si c’est possible c’est récupérer le trigger qui à déclenché le scénario : si il à été exécuté manuellement alors j’aurais réactivé les logs, si il s’agit d’un lancement déclenché ou provoqué la je reste sans logs.
Je sais modifier la conf de certains équipements par exemple en appellant l’équipement logique via qLogic::byId() et en faisant un setConfiguration mais est il possible de faire la même chose pour un scénario ? J’ai testé sans succès et n’ai rien trouvé dans la doc
Là je pense pas qu’il soit possible de faire quoi que ce soit. Même si on trouve comment changer le niveau de log d’un scénario, il sera trop tard pour le faire si le scénario en question tourne (et donc sans log).
Par contre je pense que tu devrais pouvoir jouer avec plugin-logmanager
Il sera possible d’écrire des logs dans un ou plusieurs équipement de ce plugin si le trigger est un appel manuel.
Ah oui tu as raison
Je n’avais pas pensé à ça, le paramètre est lu en début de scénario et pas en cours …
Je viens de faire le test en modifiant le niveau de log directement en SQL (oui c’est pas beau et c’est ce que je voulais éviter mais c’est juste pour tester)
Quand j’actualise l’IHM je vois bien que le niveau de log à bien changé mais effectivement pour l’exécution courante c’est trop tard … Tu as raison @Bison
Oui j’utilise déja ce plugin Mais la c’était vraiment le log « brut » du scénario qui m’interessait. Pas grave, je vais me débrouiller autrement. Merci en tout cas de ta réponse
Bon par contre la ou je peux voir un petit interet quand même à pouvoir faire la manip, c’est de remettre automatiquement le log à aucun si jamais j’oublie de le faire manuellement suite à mes tests
à l’attention des autres lecteurs: non ce n’est pa documenté et non je ne vais pas le documenter, et oui ca aura un comportement bizarre, non ce n’est pas un bug car non ce n’est pas prévu d’être utilisé pour ca; et si quelque chose manque dans ce disclaimer, considérez que c’est également écrit ou arrêtez de lire ici
bref, si c’est ça alors c’est possible et ca sera pris en compte en live (donc non il ne sera pas « trop tard »)
et donc le « comportement bizarre » va être le suivant:
si tu utilises « realtime », tout ce qui aura été ajouté dans le log depuis le début du scénario sera immédiatement écrit même si le loglevel était sur aucun avant
pour les 2 autres, l’endroit ou ils sont placé dans le bloc code n’a pas d’importance, ce qui compte c’est la valeur de la config à la fin du scénario
donc suivant la valeur, le log sera écrit sur fichier ou pas et ce pour toutes les entrées depuis le début du scénario
edit: l’emplacement du bloc code dans le scénario n’a pas d’importance non plus.
dans tous les cas, avec cette syntaxe, la configuration ne sera pas sauvegardée.
Donc si tu sauves ton scénario en mode « aucun » et que dans un bloc code tu changes sur « default » (sans sauvegarder) en cas de déclenchement manuel, ton scénario va rester sur « aucun » pour la prochaine exécution (ou même d’autres exécution en // si lancement multiple)