Antenne BLEA - Comment empêcher les messages vers la console physique?

[LMQT]

Bonjour,

Depuis que j’ai configuré une machine en tant qu’antenne BLEA, sa console physique (un petit écran) se rempli du message bien connu "Bluetooth: hci0 advertising data length corrected plusieurs fois par seconde :

juin 19 07:47:57 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:47:57 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:47:58 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:47:58 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:47:59 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:47:59 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:47:59 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:48:00 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:48:01 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:48:01 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:48:01 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:48:02 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:48:02 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:48:03 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:48:03 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected
juin 19 07:48:04 NUNUX2ND kernel: Bluetooth: hci0: advertising data len corrected

Donc forcément, ce qu’est supposé afficher l’écran est totalement illisible et inutilisable

Puisqu’on ne peut pas éviter ce message (dû à un périphérique Bluetooth dont je ne peux me passer mais qui envoie des trames incomprises par le pilote de la clé USB Bluetooth), j’ai cherché comment rediriger ces messages ailleurs que vers la console physique, mais je n’ai pas trouvé
J’ai du essayer quelques dizaines de manips avec les « stdout » et « stderr » trouvées ici ou là, mais ça ne fonctionne pas, ou alors je n’ai pas trouvé le bon fichier pour les inclure.

Est-ce que quelqu’un aurait une idée de comment supprimer cette sortie de messages d’erreur Bluetooth (uniquement elle si possible) vers l’écran SVP ?

PS : je ne veux pas désactiver complètement la sortie écran, il faut que je conserve les messages du boot notamment.
PPS : ce n’est pas sur un Raspberry Pi, mais sur un mini-PC Intel x64 avec Debian Buster (10) +Grub.
Nota : j’ai bien essayé GRUB_CMDLINE_LINUX="loglevel=3", ça fonctionne, mais ça bloque également les autres messages, pas seulement ceux du Bluetooth, donc ça ne me va pas car trop global.

[Bad]

Hello,

Il est possible de configurer le service syslog pour ne pas loguer ou loger dans un autre fichier certains messages, les commandes et quelques exemples ici :

RSyslog Documentation - rsyslog

How to supress specific message in syslogd 1.4.1

Par contre, ayant eu plus ou moins les mêmes problèmes que toi avec le Bluetooth jai arrêté d’utiliser le plugin Blea et suis parti sur 2 ESP32 avec OpenMqttGateway :

OpenMQTTGateway v1.6.0

Les 2 ESP sont idéalement situés chez moi pour tout couvrir et remontent directement les scans en sur mon Broker MQTT local, ce qui rends la solution très légre et peu adhérante à Jeedom.

Bad

[LMQT]

Bonjour,

Merci (à retardement , désolé, c’était complexe pour moi et j’ai eu plus urgent à faire sur ma domotique) car j’ai enfin réussi grâce à ton orientation

Donc pour ceux que ça intéresse, voici en résumé ce qu’il est possible faire pour s’affranchir totalement des ces fichus messages :

Modifier le niveau d’importance des messages d’erreur affichés sur la console :
Utile par exemple pour désactiver les messages du Bluetooth « Bluetooth: hci0: advertising data len corrected » qui sont envoyés sur un niveau d’erreur de niveau 4, donc on va brider l’affichage du 1er au 3ème seulement.
Voir ici, c’est expliqué en détail : https://linuxconfig.org/introduction-to-the-linux-kernel-log-levels

Action temporaire mais immédiate :
=> sudo sysctl -w kernel.printk=3

Action définitive, mais après reboot :
=> sudo nano /etc/default/grub
ajouter le paramètre « loglevel=3 » à la ligne « GRUB_CMDLINE_LINUX= », exemple :
GRUB_CMDLINE_LINUX="loglevel=3"
puis reconstruire Grub :
=> sudo update-grub

Pour afficher le niveau actuel (le 1er des 4 chiffres est celui de la console) :
=> sudo sysctl kernel.printk

Bloquer le log d’un type de message précis (exemple avec le fameux « Bluetooth: hci0: advertising data len corrected ») :
Créer un fichier de règles avec un indice de priorité élevé (‘01’ ici) :
=> nano /etc/rsyslog.d/01-bt_filter.conf
Lui ajouter ces lignes (je laisse tous mes commentaires pour les novices comme moi, ça aide beaucoup quand on revient sur un sujet quelques mois ou années plus tard ) :

# filtrage des messages d'erreurs de BLEA

# NOTA : pour rendre les règles actives, lancer la commande :
#       systemctl daemon-reload && systemctl restart syslog.socket rsyslog.service

# Ici on les envoie dans un log à part :
#:msg, contains, "advertising data len corrected" {
#  /var/log/bluetooth_filter.log
#  stop
#  }

# Ici on les supprime complètement :
:msg, contains, "advertising data len corrected" stop

# De même avec un second message d'erreur qui revient souvent :
:msg, contains, "bt_err_ratelimited" stop

Recharger les fichiers de config et lancer les services :
=> systemctl daemon-reload && systemctl restart syslog.socket rsyslog.service

Et voilà, ce méchant message ne vous pourrit plus les logs ni la console
(juste le log kernel, mais bon, ça c’est inévitable je crois)

[Bad]

Hello,

Naturellement, parmi les solutions que tu évoques, je préfère la seconde. Elle est un peu plus complexe à mettre en place initialement, mais au moins ne planque pas sous le tapis des logs du même niveau qui pourraient être important.

Et la solution que je préfère par dessus tout, reste de passer à Open MQTT Gateway

Bad

[LMQT]

Malheureusement, comme ce sont des messages issus du kernel, ce sont deux choses différentes et l’une n’empêche pas l’autre.
Tu peux bloquer les log, ça n’empêchera pas l’affichage sur la console.
Et tu peux bloquer l’affichage sur la console, ça n’empêchera pas les logs.
Donc il faut voir ce qui nous « gêne » afin de choisir une des deux solutions de masquage, ou bien les deux