Problème après reboot ou de configuration antenne

Salut @rootard,

Encore moi… Beaucoup de texte et de points car j’ai l’impression qu’il y a des liens entre chacun alors je mets tout en 1 seul sujet !

J’ai eu quelques soucis sur BLE scanner lors de l’installation de JeeZigbee (et rollback car je ne pouvais pas me permettre d’avoir tous mes protocoles off pendant plusieurs heures).
Donc après le rollback sans Jee Zigbee, j’ai identifié des points embêtants (donc sans lien avec JeeZigbee ! ) qui sont peut-être liés à ma configuration (ou pas) :

  • Lors du redémarrage de mon RPI3b, tous mes équipements BLE sont out et j’ai une erreur du plugin BLE Scanner « demon MQTT non démarré ». En relançant le demon de BLE scanner manuellement, c’est OK (la relance de ceux des plugins mqtt manager ou theengs ne changeait rien).

    (chaque ligne est un redémarrage).
  • Ca a peut-être un lien : Au redémarrage (et après), mon antenne locale n’est plus « présente ». Il faut la supprimer et refaire une auto-decouverte pour qu’elle réapparaisse comme présente (d’ailleurs je pense que la valeur de présence est directement mise à 1 sans réelle vérification?). Selon ma compréhension, soit j’ai loupé une config, soit c’est lié au fait que j’ai utilisé le plugin Theengs, mon antenne n’a pas exactement la configuration MQTT de ta doc : la présence de l’antenne est sur un autre topic que les devices et je n’ai pas trouvé comment la changer dans le plugin theengs (voir à la fin).
    mqtt explorer


    La commande indiquée sur l’antenne ne correspond pas à MQTT Explorer :

Cela dit, je n’ai pas besoin de savoir la présence de l’antenne locale sauf si cela a un impact sur l’erreur précédente ou sur d’autres fonctionnalités (voir point suivant)?

Quelques éléments de config :

Enfin avec mes multiples reboots et auto-découvertes, je me suis aperçu que ca me bouge des choses sur les devices existants, ce qui m’oblige à les reconfigurer à chaque fois :

  • l’ordre des commandes change presque toujours (je trie habituellement selon l’id parce que ca me va pour afficher la carte standard du device sur le dashboard).
  • la commande RSSI avec un nom plus long (il y en a 2 sur les Xiaomi LYWSD03MMC ATC et LYWSDCGQ mais c’est pas forcément le problème) se recoche « afficher » après re auto-decouverte

Et Bonne année bien sûr !

salut et bonne année également.
Effectivement si ca marchera pas si le LWT n’est pas sous le meme topic que BTtoMQTT.
Je n’ai pas testé le plugin-theengs depuis longtemps donc si pas moyen de changer ca va être un probleme…
je te suggère 3 autres solutions que j’utilise selon le contexte:

  1. installer l’image docker theengs
    voici mon docker-compose.yml (sur mon Pi3B+):
# docker-compose.yml
services:
  theengs:
    container_name: theengs
    image: theengs/gateway
    network_mode: host
    privileged: true
    restart: unless-stopped
    environment:
      MQTT_HOST: localhost
      MQTT_USERNAME: xxxx
      MQTT_PASSWORD: yyyy
      MQTT_PUB_TOPIC: theengs/tgw_local/BTtoMQTT
      MQTT_SUB_TOPIC: theengs/tgw_local/commands
      LWT_TOPIC: theengs/tgw_local/LWT
      BLE_TIME_BETWEEN_SCANS: 60
      SCAN_TIME: 4
      LOG_LEVEL: WARNING
      DISCOVERY_DEVICE_NAME: tgw_local
      DISCOVERY_FILTER: "[IBEACON,GAEN,MS-CDP]"
      ADAPTER: hci0
    volumes:
      - /var/run/dbus:/var/run/dbus
    healthcheck:
      test: 'hciconfig|awk "/hci0/{ print $0 }" || exit 1'
      interval: 1m
      timeout: 1s
      start_period: 5s
      retries: 3
  1. directement en python (ex sur mon PiZero). voici mon fichier theengs.conf:
{
    "adapter": "",
    "bindkeys": {},
    "blacklist": [],
    "ble": 1,
    "ble_scan_time": 5,
    "ble_time_between_scans": 60,
    "discovery": 1,
    "discovery_device_name": "tgw_remote",
    "discovery_filter": [
        "IBEACON"
    ],
    "discovery_name": "tgw_remote",
    "discovery_topic": "homeassistant",
    "enable_tls": 0,
    "enable_websocket": 0,
    "general_presence": 0,
    "hass_discovery": 1,
    "host": "192.168.1.94",
    "identities": {},
    "log_level": "WARNING",
    "lwt_topic": "theengs/tgw_remote/LWT",
    "pass": "yyyy",
    "port": 1883,
    "presence": 0,
    "presence_topic": "home/TheengsGateway/presence",
    "publish_advdata": 0,
    "publish_all": 1,
    "publish_topic": "theengs/tgw_remote/BTtoMQTT",
    "scan_duration": 60,
    "scanning_mode": "active",
    "subscribe_topic": "theengs/tgw_remote/commands",
    "time_between": 60,
    "time_format": 0,
    "time_sync": [],
    "tls_insecure": 0,
    "tracker_timeout": 120,
    "user": "jeedom",
    "whitelist": []
}

tu peux aussi regarder ce tuto qui explique tout

  1. un ESP32

Alors, pour le moment je n’ai pas tout changé côté theengs.
J’ai voulu essayer d’isoler chaque problème et en 1er lieu voir l’impact d’un changement de lwt_topic par une petite bidouille (j’ai modifié le php du plugin theengs là où ca définit ce topic).
Résultat :
L’antenne est bien vue online par BLE scanner (mais du coup, pas par le plugin theengs…).
Ca résout le problème des RSSI non visibles dans la liste des devices connus.
Update 2 janv : j’ai remis le plugin theengs en standard et j’ai fait un scénario qui duplique le LWT sur le bon topic => c’est pas optimal mais ca sera robuste, je crois. Et bon exercice MQTT :wink: )

En revanche, c’était mon problème principal d’origine, ca ne marche toujours pas au redémarrage du RPI, il y a toujours l’erreur dans les logs de BLE scanner : Démon MQTT non démarré. (et aucun device ne s’actualise)
Dès que je redémarre manuellement le démon de BLE scanner, tout remarche. (avant de relancer, j’ai l’impression qu’il était bien déjà lancé).
J’ai aussi essayé de cocher la case « Redémarrer le démon » en haut dans la partie log et surveillance mais ca ne change rien, même après 5min d’attente (heartbeat par défaut pour relancer?).

Ca vient finalement peut-être juste du Mosquitto local qui redémarre aussi mais pas aussi vite que ton plugin?
J’ai essayé d’arrêter Mosquitto et de relancer le démon de BLE scanner et j’ai bien le même message d’erreur. (bon il y a sûrement un tas de causes qui aboutissent à ce message)
J’ai aussi l’impression qu’en cas de coupure temporaire de Mosquitto (par exemple : une mise à jour?), BLE scanner tombe et ne remonte pas tout seul.

Qu’en penses-tu ?

salut
tu as clairement un pb d’acces a MQTT. sans logs difficile de t’aider…
il est géré par qui ton mosquitto? HA? plugin MQTT Jeedom? autres?
as tu bien indiqué le bon login/passwd? le port et l’url sont bons?
pas de conflit de port avec un autre service démarré (1883 par défaut)?
peux tu me poster une nouvelle photo de ton MQTTExplorer après ta bidouille LWT?
le démon devrait démarrer même sans LWT: pas de logs dans blescannerd?

Oui j’utilise le plugin MQTT Manager (MQTT 2) avec la config standard :


MQTT Explorer après « bidouille » (duplication LWT sur le bon topic via un scenario) :

Page santé de Jeedom au cas où :


(le 2 updates non faits sont ceux de jeedom 4.5.x et virtuel : avant, je dois finir de migrer BLEA [ca c’est BLE scanner] et zigbee [à passer vers Jeezigbee] )

J’imagine que s’il y avait un problème de port URL login password, je n’aurais pas les bonnes valeurs sur mes capteurs de temperature ?
Pour le conflit éventuel sur le port 1883, comment cela se manifesterait-il ?

En terme de log sur les 3 plugins, il n’y a pas d’erreur signalée en dehors de celle BLE scanner quand jeedom redemarre. Je le remets ici (chaque ligne apparait après un redémarrage) :

Je ne sais pas s’il y a d’autres logs à te fournir. Si besoin, merci de me dire lesquels et comment les trouver.

aussi la config de BLE scanner : est ce que je dois changer le socket de BLE scanner ?

bien vu pour la republication LWT oui ca devait régler ce pb.
ok je crois comprendre ce qu’il se passe au reboot: mqtt2 ne doit pas encore etre demarré d’ou le pb. je vais tester ca.
pour le port socket tu peux verifier s’il y a un conflit de port apres avoir désactivé le plugin blescanner avec:

netstat -a|grep 55036|grep LISTEN

En attendant partages moi la log du démon blescannerd en DEBUG

Voilà blescannerd en pièce jointe.

A noter :

  • A 17h00 49sec, j’ai lancé un redémarrage
  • A 17h02, redemarrage de BLE scanner qui indique tout ok dans ce log mais en vrai ca ne marche pas et j’ai le message d’erreur dans l’autre log (mais zut, je ne l’ai pas exporté et il est déjà tronqué, voir capture écran centre de message jeedom)
  • 17h05 : je relance manuellement le démon de BLE scanner (ca démarre bien et lance une auto-découverte)

A noter bis : en fait il y a une heure de décalage dans blescannerd, c’était 18hxx la vraie heure si jamais. L’autre log est à la bonne heure.

blescannerd.txt (106,5 Ko)

Pour la commande netstat -a|grep 55036|grep LISTEN :

  • avec le plugin coupé, je n’ai aucun retour
  • avec le plugin actif, j’ai ce retour (qui semble être normal si je comprends bien) :
    tcp 0 0 localhost:55036 0.0.0.0:* LISTEN

Donc, pas de problème pour le socket.

salut

Je viens d’uploader une nouvelle version avec le support de MQTT2 (dispo demain).
Dis moi si ca fonctionne chez toi

1 « J'aime »

@rootard : aie ca ne fonctionne pas et je n’ai pas fait de sauvegarde avant de faire l’update… (quelle nouille…)

2026-01-04 08_14_27-Greenshot

J’ai essayé de désactiver/activer le plugin. J’ai rempli le nouveau mode MQTT. J’ai redémarré aussi. Mais ca ne debloque rien : les blocs dependance et demon restent vides.
J’ai aussi modifié la config pour revenir sur la config d’origine (externe avec login mdp) mais ca ne marche pas mieux après desactivation/reactivation.
Et si je laisse activé le plugin, tous mes autres plugins tombent…

En mode debug sur le log blescanner, j’ai ca quand j’active le plugin :

[2026-01-04 08:28:04][DEBUG] : Lancement de : /var/www/html/core/class/../../core/php/jeePlugin.php  plugin_id=blescanner function=remove callInstallFunction=1
[2026-01-04 08:28:07][INFO] : Début d'activation du plugin
[2026-01-04 08:28:08][INFO] : Info sur le démon : {"launchable_message":"","launchable":"nok","state":"nok","log":"nok","auto":0}
[2026-01-04 08:28:09][DEBUG] : Lancement de : /var/www/html/core/class/../../core/php/jeePlugin.php  plugin_id=blescanner function=install callInstallFunction=1

S’il y a besoin d’une nouvelle version, tu me diras si je peux faire une modif débloquante via l’éditeur de fichiers.

Actuellement sur mon RPI, j’ai ca (ce qui semble normal) :

A noter : je suis en jeedom version 4.4.20 pour le moment.

Merci

@rootard :
L’IA m’a trouvé qu’il manquait la fermeture de parenthèse à la ligne 913 de blescanner.class.php !

Après plusieurs tests, c’est bon désormais avec la rectif php.

oups désolé… je modifie tout de suite

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.