Tu imagines pas le nombre de demande que j’ai comme ça par jour. Faut je contacte Jeedom, trouve la bonne personne, lui en parle, lui explique il va avoir des questions faut je reviennes vous voir vous les poser attendre la réponse et leur redonner… Je peux le faire pas de soucis mais faut je m’enlève de la charge. De plus j’aurais pas plus de réponse que vous par ticket…
1 « J'aime »
Passe à un esp32 avec tasmota ou omg et tu retrouves un jeedom en pleine forme.
En debian 11 je n’avais que de l’instabilité avant et depuis c’est un régal de simplicité et de fiabilité.
1 « J'aime »
Ok, laisses alors, on va continuer les tickets.
Bonne fin de journée à toi
1 « J'aime »
Désolé mais c’est aussi efficace par ticket que mon moyen de communication avec eux ça a même plus d’impact je pense. Et clairement je préfère passer du temps a corrigé les bugs des plugins que je gère que faire passe plat a mon avis c’est plus utile.
Je ne parlais pas spécialement en mon nom.m.
Les esp n’ont pas la fiabilité d’un pi (portée ridicule, déconnexion réseau, à redémarrer et surtout : pas à la portée de tous pour la mise en service).
3 « J'aime »
C’est que je dois être très chanceux du coup 
où que j’en ai pris des bons quitte à payer 1 euros de plus. Aucun souci ou redémarrage depuis la mise en service 2023-03-27 sous Tasmota en tout cas.
Pour la portée, c’est placé sur une simple prise au milieu de la maison et mes capteurs de temp en blu sont à 10 mètres plus murs et ça se passe très bien. De toute façon à ce prix là rien n’empêche de les multiplier aux endroits stratégique.
En ce qui me concerne c’était (pour moi) la solution la plus efficace quand je suis passé à Bull11 et j’ajoute qu’à ma grande surprise des équipements qui n’étaient pas reconnus de Blea se sont inclus simplement et fonctionnent parfaitement alors que j’allais finir un jour ou l’autre par les sortir du tiroir pour les jeter.
Ca m’a permis d’avancer plus sereinement au lieu d’attendre la résolution d’un ticket et je ne suis plus dépendant d’un tiers.
Si moi j’ai réussi, c’est que c’est franchement à la portée de tous, je t’assure que je n’ai aucune compétence, je lis et j’applique en essayant de comprendre. Avec l’aide de vous tous sur le forum.
L’installation de Tasmota est automatisé et c’est ultra simple. J’ai été impressionné d’autant de simplicité qui a dû demander du travail en amont.
https://tasmota.github.io/install/
2 « J'aime »
J’exploite la partie Bluetooth de mes Shelly Gen2 (ESP32 inside) avec 4 Nuts depuis le début de l’année.
1 Shelly au sous-sol, 2 au RDC.
1 Nut au sous-sol et 1 au RDC qui servent quotidiennement.
2 Nuts, à l’étage, positionnés le plus loin possible en test.
Je n’ai que très rarement des faux négatifs sur les Nuts situés à l’étage.
Portée ridicule => Non, même le Shelly du sous-sol voit les Nuts à l’étage
Déconnexion réseau => Remplacer un Shelly Gen1 à l’étage par un Shelly Gen2
A redémarrer => Jamais eu besoin
Pas à la portée de tous pour la mise en service => Un simple copier/coller du script
1 « J'aime »
Idem je patiente sous buster tant que le plugin ne sera pas compatible.
pour info, BLEA fonctionne sous Debian 11 vu qu’il est codé en python 3, les seuls problèmes rencontré sont au niveau des dépendance mais une fois réglé, ca tourne sans problème
Bonjour,
Malheureusement beaucoup ont des problèmes de charge cpu qui augmente progressivement avec BLEA sous Debian 11.
ca, c’est un autre problème. il ne ne faut pas confondre non compatible et non optimisé. d’après ce que j’ai lu sur divers post, c’est pas des augmentations énormes de charge non plus. tout dépend aussi du matériel sur lequel tourne jeedom
Vu que l’augmentation de charge ne s’arrête jamais au bout d’un moment quel que soit ton hardware cela va poser problème 
Hello, ça sera pas tout de suite 
car de base il est sur du PHP 8.2, il faut vérifier toute la comptabilité du core de Jeedom
Sinon passer sur Debian 11, il y a aucun soucis sauf pour les plugins sous Python 2
Vous n’avez manifestement pas testé correctement !
Il n’y a pas de problème d’installation des dépendances, tout est ok de ce côté et le plugin fonctionne.
Mais il part en vrille sans fin, jusqu’à rentre inutilisable la machine (ram et CPU).
- Testé sur pi4 et VM.
C’est un bug remonté sur le github du projet bluepy, qui est le cœur de ce plugin.
Le projet étant abandonné depuis au moins 1 an, la correction ne sera pas sur le github d’origine.
TOUS les utilisateurs de Debian 11 rencontrent ce problème.
5 « J'aime »
Merci pour vos retours c’est ce que j’avais lu dans mes différents posts sur le forum.
Je vais du coup patienter et espérer une solution avec ce plugin indispensable pour mon utilisation.
Bonjour,
Est-ce que les problèmes de surcharge que vous mentionnez sont dus au processus « bluepy-helper » ?
Car j’avais eu un problème similaire avec ce processus qui « gonflait » et finissait par figer mes machines et je n’ai pas réussi à le corriger autrement que par un script de surveillance dudit process.
Oui c’est ça.
Ha ben je suis pas le seul alors LOL
Et pourtant je n’ai pas trouvé de topic via la recherche, je devais avoir la berlue …
Du coup j’ai fait un petit script que je vous partage si ça peut en aider certain le temps que ce soit corrigé en amont. Pas certain que nous ayons tous exactement le même soucis, mais avec un peu de bol …
Nota : mon script flingue le processus, mais il est relancé automatiquement peu de temps après, donc pas d’inquiétude, le plugin BLEA continuera à fonctionner.
Le voici :
#!/bin/bash
# ##### SCRIPT DE SURVEILLANCE D'UN PROCESSUS PLANTÉ
# Lance un check et kill le processus en question, puis écris dans un log.
# v1.0
# LMQT (forum Jeedom)
function f_check {
# On lit les processus actifs et on les sort avec durée, nom et PID,
# on les classe d'abord par leur durée la plus ancienne (il peut y avoir des doublons),
# puis on filtre sur le premier des processus correspondant au filtre (v_process).
v_retour=$(ps -eo etimes,comm,pid|grep -i -m 1 $v_process)
v_erreur=$?
v_duree=$(echo $v_retour|awk '{print $1}')
if [ $v_erreur -eq 0 ]; then
if [ $v_duree -ge $v_timing ]; then
v_pid=$(echo $v_retour|awk '{print $3}')
kill $v_pid
v_output="$(date +'%Y-%m-%d %H:%M:%S') / Le processus [$v_process]($v_pid) tourne depuis $v_duree secondes."
$(echo $v_output>>$v_log)
fi
fi
}
v_process="bluepy-helper" # Nom du processus à surveiller
v_timing=3600 # Nombre de secondes depuis lequel il tourne
v_log="/var/www/html/log/killer.log"
unset v_retour; unset v_erreur; unset v_duree; unset v_pid
f_check
Vous n’avez qu’à jouer sur les variables « v_timing » et « v_log » selon vos choix et mettre une ligne de ce style dans votre CRONTAB :
# Kill du processus bluepy-helper s'il tourne depuis trop longtemps :
*/15 * * * * root /usr/local/sbin/blpyhlpr-killer.sh
Nota : bien sûr, modifiez le chemin en fonction de là où vous allez créer votre script.
Et faites un
CHMOD +x /usr/local/sbin/blpyhlpr-killer.sh
pour le rendre exécutable.
Bonjour .
Merci. Mais c’est de la bidouille. Il faut créer une alternative à ce plugin. Ou que Jeedom le corrige, c’est un plugin officiel beaucoup utilisé.
Mips semble avoir bien avancé avec un plugin basé sur mqtt.
4 « J'aime »
Oui tout à fait, je suis entièrement d’accord.
Pour ma part j’ai quasiment abandonné ce plugin car il ne fait plus ce qu’il me faut et il n’évolue plus depuis plusieurs années. C’est dommage, mais je crois que c’est le lot de pas mal de plugins sur jeedom au bout d’un moment.
Je me sers de quelques scripts trouvés sur le net ou faits par moi-même.
Je n’ai plus que la détection de 3 GTags sous ce BLEA, et c’est juste parce que je n’ai pas encore eu le temps de les remplacer par autre chose ni de trouver un autre moyen de les détecter.