Démon local BLEA bloqué

Bonjour,

J’utilise BLEA avec une clé SENA en local dédiée.
En parallèle, 2 PI en antenne.

Depuis plusieurs jours, j’ai une erreur dans les logs

can only concatenate str (not « bytes ») to str

Et surtout j’ai remarqué que mes Gtag, NUT etc ne sont pas vues comme absents - le RSSI du local reste à une valeur qui le laisse en présent ; alors que les antennes, elles, voient bien l’absence du G-tag et du NUT.

Le seul moyen de m’en sortir est de désactiver l’antenne locale - d’enlever le hci0, redémarrer le démon ; puis réactiver l’antenne locale et le hci0 et là le statut est juste.

Côté santé, je tourne sur un vieux debian (certes), je dois le migrer à l’occasion ; mais ça marchait avant. Debian 10.13 à jour, Jeedom 4.3.23.

salut,
je ne saurais répondre à votre problème par contre si vous migrer debian 10 vers un version plus récente (11 et +) plugin-blea ne fonctionnera pas correctement (saturation progressive de la charge cpu) c’est un bug qui n’a jamais été corrigé dans une librairie de blea, et ne le sera jamais car ce n’est plus maintenu, donc le plugin-blea ne le sera pas non plus. Il faudra passer par une autre solution qui fonctionne très bien plugin-mqttdiscovery avec pour les antennes Pi plugin-tgw TheengsGateway.
J’avais aussi des Pi en antennes déportées (Pi 0 2w) ave blea puis avec mqttdiscovery+tgw mais trop de plantage de ces pi tout les qq jours donc je les ai viré pour des esp32 qui tournent sous opengateway et j’ai 0 perte avec le plugin-mqttdiscovery.

2 « J'aime »

Merci, intéressant, ton retour. Je me rappelle sous Jeedom du plantage à cause de BLEA… effectivement, ça n’a pas changé !
Par contre, mes antennes PI tournent parfaitement.
Je pense déjà revenir dans un premier temps à une simple VM légère de BLEA avec son antenne dédiée.
Je suis en train de migrer la VM actuelle sous Debian12. Et forcément, quelques petits trucs ne vont pas.
Je creuse.

Bonjour,

C’est peut être prématuré de déjà passer sous debian 12 non ?

L’ensemble des plugins ne sont pas encore compatibles

Alors si c’est pour tests ok, sinon je trouve cela risqué

Pardon, debian11.

1 « J'aime »

Je trouve ça fou l’histoire de saturation et que le bug ne sera jamais corrigé quand même…

Ben c’est le souci qu’ont les plugins qui se basent sur des librairies tierces abandonnées.

Et le cas est loin d’être unique !

Mais c’est plus de la saturation ram dans ce cas (memory leak) que CPU, donc un simple monitoring de la ram et hop un restart au-dessous d’un certain seuil et basta.

Officiellement Jeedom n’a rien dit, ni dans un sens ni dans l’autre :smiley:

Après il y a des plugins alternatifs qui fonctionnent très bien comme dit plus haut

Pour l’heure, j’ai effectivement ajouté un suivi mémoire de la VM dédiée à BLEA et c’est plié.
Merci le plugin proxmox qui fait le boulot.
J’ai eu un souci du passage de Debian10 et 11 mais j’ai trouvé le topic clé pour pour pip et bloquer la version à 24 et toutes les dépendances sont OK ; ouf.
Le portage a été fait en moins d’une heure.

ah moins de réécrire une lib eux même non il ne feront pas , surtout que Mips à sortit le bon plugin-outils pour utiliser des solutions à jour, fonctionnelle. Jeedom ils vont pas y passer des heures pour réinventer alors que çà marche autrement

Bon,forcé de constater que d’avoir migré en debian11 n’a rien solutionné.
J’ai déporté BLEA sur une VM dédiée, aucun souci de RAM mais pour autant, la VM en question continue de dire que les g-tag ou nuts sont toujours présents sur l’antenne en question.
Bon, je vais voir pour tout porter comme dit plus haut avec les 2 plugins en question.

Justement c’est en debian 10 que BLEA fonctionnait sans memory leak.
Donc passer en 11 :thinking:

Les vm et pi sont en debian 10.
Cest mon jeedom que j’ai passé en 11.

Ben pourtant, l’auteur du plugin intervient sur le code, ainsi que Loïc.
Donc il n’est pas abandonné

certe oui y a deux petites modifs récentes pour contourner le pb de memory leak, çà fait quand même plus d’un an (deux?) que le soucis avec debian 11 est remonté sans réponses jamais des devs sur des postes ou des tickets (j’ai plusieurs discussion off avec un modo embêté comme moi à l’epoque et qui n’avait pas de retour), et je ne leur tire pas dessus en disant ça, c’est juste un constat, ils ont sûrement leurs raisons sur des priorités autres ou manque de temps.

mais sinon à part reprendre la lib pour corriger le pb je ne vois pas comment le plugin pourrait évoluer bcp plus. sinon partir sur une autre lib, faire comme sur le combo mqttdiscovery/ tgw ou /ogw. Mais bon quand qq chose fonctionne déjà très bien pourquoi y repasser plusieurs dizaines d’heures ? a mon sens ça n’en a pas.

ça va aider temporairement ceux qui ne veulent/peuvent pas changer de plugin, mais c’est une rustine.

ce sont des pi quoi?

le plugin-tgw c’est une install auto depuis jeedom sur les pi, faudra peut-être repartir d’une install neuve des pi pour pas ajouter des couacs mais sinon c’est easy.
et mqttdiscovery va récupérer les infos des antennes et la gestion de présence est bien faites.

Le problème des PI, c’est qu’une de mes PI est un compteur d’eau et de capteurs secs via Jeedouino et pour le coup, ce plugin est bien abandonné j’ai l’impression.
Et j’ai peur de la réinstallation d’une PI qui tourne avec son OS depuis plus de 5 ans… ça doit être un debian7 ou 8.

1 « J'aime »

oui là c’est très risqué. Mais toujours moyen de faire un backup du pi et de tester puis si ça passe pas on remet le backup.

c’est ce que j’avais prévu de faire.
j’ai mis une antenne locale sur la VM Deb11 avec une première SENA.
je suis en train de déployer la seconde PI qui faisait qu’antenne BLEA avec une SENA.
il restera la PI extérieure… (qui fait boite aux lettres, contact portail, etc).

1 « J'aime »