Oui c’est ça, la serrure va poster directement en mqtt et le plugin va la détecter via le discovery.
Encore une fois, ce plugin n’est pas lié au bluetooth ni à theengs mais à mqtt 
Si tu tests avec ça m’intéresse de voir les configs et qu’on vérifie ensemble que tout est bien créé
btw, c’était déjà dans la documentation
Rapport à ta question Timeout défini à 5 secondes sur la fonction "exec" trop long > double voir triple "Gâchage" - #3 par 1suisse et ta question sur mqtt ici,
je ne comprend pas trop quel matos tu as du coup, car selon moi nuki smart pro est bien compatible mqtt et mqtt discovery mais si tu utilises le plugin-nuki c’est que tu as un bridge et je ne pense pas que le bridge supporte mqtt, en tout cas moi je n’ai pas trouvé cette option sur le mien
Bonsoir, un petit retour car tu es toujours en beta, j’ai reçu mes ESP32 et ton plugin fonctionne super bien avec l’antenne SENA et les 3 ESPs.
Bonjour
Merci à Mips pour le plugin MQTT Discovery que j’ai installé tout récemment.
Il est rare que j’installe un plugin en beta, mais après un mois et demi de « changelog » j’ai pensé que je ne courais pas de grand risque (NB : sachant que j’ai des sauvegardes, y compris de VM)
Ma config :
Jeedom : V 4.3.17
MQTT Discovery : version Beta 2023-10-19 01:01:51
2 x ESP32 AZDelivery
Dongle Sena UD100-G03
Modules BLEA : Nut Find 3 et Shelly BLU Bouton
Retour d’expérience :
Quelques informations complémentaires :
Comme je n’ai pas honte, je partage ma bévue
Avant d’installer le plugin MQTT Discovery, j’avais bien vu le topic « homeassistant » grâce à MQTT Explorer.
J’avais aussi lu la doc du plugin, où il est clairement mentionné que ce topic est nécessaire !
Mais comme j’avais fait des tests avec home assistant et une connexion MQTT avec Jeedom, j’ai cru que le topic venait de là… et j’ai effacé le topic « homeassistant » avec MQTT Explorer !
Evidemment, le plugin MQTT Discovery ne remontait aucun équipement
J’ai redémarré mes 2 ESP32 et le topic « homeassistant » a été recréé
… On est prié de ne pas se moquer 
Informations concernant le Shelly BLU Bouton :
Dans le topic « homeassistant », le module est reconnu comme un « sensor » avec les infos « packet », « batt », « press ».
L’équipement créé ne comporte alors que ces trois infos
En ajoutant le topic de mes ESP32 (« bt » en l’occurrence), l’information RSSI remonte et par conséquent la présence
A venir
Comme je souhaite continuer à utiliser mon Dongle Sena, j’installerai le plugin « Theengs gateway »
Comme ce plugin en beta est plus récent, dois-je attendre encore un peu ?
Merci encore pour ces 2 plugins
PS : et une bêtise de plus !.. j’ai cliqué sur répondre à Kwet 
Hello franchement j’ai installé le plugin bêta Theengs-gateway il fonctionne parfaitement avec ma clé Séna.
Après tu peux aussi installer l’application en direct mais perso je préfère tout directement dans jeedom et avec Mips c’est hyper bien suivi.
Merci pour le retour.
Concernant beta<>stable de mon côté les deux versions ont été remontée en stable et la synchro avec le market demandée. Autrement dit je considère la version actuelle des deux comme stable.
Les non-devs ne le savent peut-être pas mais avant la première stable l’équipe jeedom valide les plugins.
Donc c’est ça que j’attends (délai normal, je n’ai fait cette demande que fin de semaine) mais ca explique donc pourquoi ils ne sont pas (encore) disponibles sur le market en stable malgré ce que je viens d’expliquer; bref c’est juste un détail administratif.
Hello,
Comment la sélection automatique d’antenne fonctionne, normalement il sélectionne le rssi le plus intéressant ?
Je constate que c’est pas toujours le cas exemple :
Non c’est toujours le dernier reçu
Bonsoir.
Profitez en pour changer l’échelle du widget du RSSI.
Il faut mettre en maxi : 0 et en mini : -200
- Cela rendra le bargraphe vivant.
Oui en effet bien vue merci
J’ai changé le template par défaut en « core::line » depuis mais effectivement je devrais changer le min max par défaut 
Bonjour,
Mes nuts sont bien découvert par contre certains n’ont pas la totalité des commandes
Pour exemple un avec la totalité des commandes
Et d’autres incomplètes
j ai supprimé et recrée mais idem toujours une seule commande.
Une idée ?
En installant mon antenne distante , cela c’est corrigé.
Par contre autres interrogations:
Certains NUT ont les 2 rssi: local et distant
D’autres un seul rssi qui est le distant
Une idée ?
Bonjour,
On va tout doucement rebasculer dans un mode « 1 question = 1 sujet » la phase de beta-test se terminant.
Pour le rssi, l’info est ici ici plus haut dans ce post (juste quelques messages…) et dans le changelog.
=> Une commande rssi global et une par antenne ayant captée le nut.
Et ceci explique pourquoi au début le nut n’avait pas toutes les commandes, il n’est probablement pas à portée ou incorrectement envoyé par l’antenne locale ce qui explique qu’il n’a que le rssi pour l’antenne distante.
Ps: à l’avenir ca ne sert à rien de faire une capture d’écran de la config surtout si elle est tronquée. Il y a un bouton pour en faire la copie.
Hello j’ai vu le change log pour les paramètres min et max mais je suppose que ça prend en compte que pour les nouveaux équipements ?
Car hormis le paramètre que j’ai changé hier pour le rssi manuellement les autres rssi (de toutes les antennes Bluetooth) n’ont pas pris en compte
oui, de manière générale je ne modifie jamais la config d’un équipement déjà créé pour ne pas écraser les choix des utilisateurs.
Lorsque c’est un paramètre important alors je met en place une vérification genre « si il y a une config, on vérifie et éventuellement corrige sinon défaut et si pas défaut » mais ici c’est vmt un détail alors j’ai fait simple.
perso le rssi je m’en fiche un peu, pour moi c’est une info technique que je n’affiche même pas.
Bonjour
J’ai installé hier le plugin « Theengs gateway » afin d’utiliser mon dongle SENA branché en local sur mon serveur Jeedom
Installation rapide sur ma configuration basée sur un NUC
NB : j’avais arrêté le Demon du plugin BLEA
Je rappelle que le plugin MQTT Discovery fonctionnait déjà avec 2 x ESP32 sur mon Jeedom
J’ai constaté que le RSSI de mon Dongle (intitulé dans mon cas « rssi TGW_775 ») avait été ajouté automatiquement à mes équipements MQTT Discovery existants, sans intervention de ma part
Hier au soir, j’ai effectué un contrôle avec MQTT Explorer et j’ai noté que j’obtenais le topic « tgw/775/LWT », mentionné dans ma configuration « Theengs gateway » : [lwt_topic] => tgw/775/LWT
Par contre, je n’avais pas le topic « home/TGW_775/BTtoMQTT », mentionné dans la configuration « Theengs gateway » : [publish_topic] => home/TGW_775/BTtoMQTT
J’ai alors remarqué que le RSSI de mes équipements découverts par mon dongle SENA était figé.
Mes interventions ont été trop désordonnées pour avoir un quelconque intérêt : redémarrage de l’antenne, relance du Demon MQTT Discovery…
C’est après un redémarrage de Mosquito sous MQTT2, que le topic « home/TGW_775/BTtoMQTT » est apparu dans MQTT Explorer, avec les équipements détectés par mon dongle SENA, et les RSSI de mes équipements ont été mis à jour sous MQTT Discovery
Petite remarque :
On voit ci-dessus, mes 2 ESP32 : les identifiants étant récupérés par les valeurs de « SYStoMQTT »
L’équipement SENA n’apparait pas, l’adresse MAC n’étant pas remontée sous MQTT
Tout fonctionne bien et je vais pouvoir désinstaller le plugin BLEA (merci à Ludovic pour ce plugin qui m’a bien servi durant plusieurs années)
Je vais pouvoir entreprendre de passer de Debian 10 à la version 11
PS : j’ai bien noté qu’il va falloir ouvrir des sujets séparés… et je suppose que les tags adaptés aux 2 plugins vont suivre
C’est normal, theengs ne publie rien sur le discovery mais en même temps je ne vois pas ce qu’il pourrait publier vu qu’il n’y a aucune action vraiment possible donc ca ne servirait à rien.
pour une question oui, mais du coup ici il n’y a pas de question ou je me trompe?
dès que les plugins seront validés par l’équipe
Bonjour
En effet, c’est bien les commandes que j’obtiens à la découverte de l’équipement SwitchBot.
Mais en patientant un peu, on obtient des commandes action
J’ai testé les commandes « X1-mode On » et « X1-mode Off » sans résultat sur le SwitchBot
Certaines commandes me surprennent : la commande « info » « X1-mode » est en « binaire » et « X1-state » en « autre », les commandes « action » « X1-batt On » et « X1-batt Off » ?
Ci-après le fichier configuration :
{
"switch" : {
"F4653615XXXX-mode" : {
"stat_t" : "+/+/BTtoMQTT/F4653615XXXX",
"name" : "X1-mode",
"uniq_id" : "F4653615XXXX-mode",
"val_tpl" : " value_json.mode | is_defined ",
"pl_on" : "{"SBS1":"on","mac":"F4:65:36:15:XX:XX"}",
"pl_off" : "{"SBS1":"off","mac":"F4:65:36:15:XX:XX"}",
"pl_avail" : "online",
"pl_not_avail" : "offline",
"stat_on" : "on",
"stat_off" : "off",
"cmd_t" : "bt/Salon/commands/MQTTtoBT/config",
"device" : {
"identifiers" : [
"F4653615XXXX"
],
"connections" : [
[
"mac",
"F4653615XXXX"
]
],
"manufacturer" : "SwitchBot",
"model" : "X1",
"name" : "Bot-15XXXX",
"via_device" : "Salon"
}
},
"F4653615XXXX-batt" : {
"stat_t" : "+/+/BTtoMQTT/F4653615XXXX",
"name" : "X1-batt",
"uniq_id" : "F4653615XXXX-batt",
"val_tpl" : " value_json.batt | is_defined ",
"pl_on" : "{"SBS1":"on","mac":"F4:65:36:15:XX:XX"}",
"pl_off" : "{"SBS1":"off","mac":"F4:65:36:15:XX:XX"}",
"pl_avail" : "online",
"pl_not_avail" : "offline",
"stat_on" : "on",
"stat_off" : "off",
"cmd_t" : "bt/Salon/commands/MQTTtoBT/config",
"device" : {
"identifiers" : [
"F4653615XXXX"
],
"connections" : [
[
"mac",
"F4653615XXXX"
]
],
"manufacturer" : "SwitchBot",
"model" : "X1",
"name" : "Bot-15XXXX",
"via_device" : "Salon"
}
}
},
"sensor" : {
"F4653615XXXX-state" : {
"stat_t" : "+/+/BTtoMQTT/F4653615XXXX",
"name" : "X1-state",
"uniq_id" : "F4653615XXXX-state",
"val_tpl" : " value_json.state | is_defined ",
"state_class" : "measurement",
"device" : {
"identifiers" : [
"F4653615XXXX"
],
"connections" : [
[
"mac",
"F4653615XXXX"
]
],
"manufacturer" : "SwitchBot",
"model" : "X1",
"name" : "Bot-15XXXX",
"via_device" : "Salon"
}
},
"F4653615XXXX-mode" : {
"stat_t" : "+/+/BTtoMQTT/F4653615XXXX",
"name" : "X1-mode",
"uniq_id" : "F4653615XXXX-mode",
"val_tpl" : " value_json.mode | is_defined ",
"state_class" : "measurement",
"device" : {
"identifiers" : [
"F4653615XXXX"
],
"connections" : [
[
"mac",
"F4653615XXXX"
]
],
"manufacturer" : "SwitchBot",
"model" : "X1",
"name" : "Bot",
"via_device" : "Sena"
}
},
"F4653615XXXX-batt" : {
"stat_t" : "+/+/BTtoMQTT/F4653615XXXX",
"dev_cla" : "battery",
"unit_of_meas" : "%",
"name" : "X1-batt",
"uniq_id" : "F4653615XXXX-batt",
"val_tpl" : " value_json.batt | is_defined ",
"state_class" : "measurement",
"device" : {
"identifiers" : [
"F4653615XXXX"
],
"connections" : [
[
"mac",
"F4653615XXXX"
]
],
"manufacturer" : "SwitchBot",
"model" : "X1",
"name" : "Bot",
"via_device" : "Sena"
}
}
}
}
Merci par avance !
comment/où as-tu copier la config? depuis le plugin?
manifestement tu l’as modifié ensuite et le résultat est corrompu; mais je ne sais pas si c’est avant ou après tes modifs.
oui, c’est normal, « mode » semble être un switch on/off
je peux voir la config avancée de cette commande? surtout ce qui a été mis dans la « formule de calcul »?
par contre il a des problèmes dans la config envoyée je pense (mais comme le json est corrompu c’est compliqué à affirmer):
le même uniq_id a été utilisé 2 fois: pour la commande switch x1-mode et pour un « sensor » x1-mode => ce n’est pas possible, le décodage doit être corrigé.
il est indiqué une commande switch x1-batt, ca n’a pas de sens pour une batterie (en tout cas je ne comprend pas à quoi ca peut servir) et du coté des commandes actions ce sont les mêmes que pour la commande mode… ce n’est pas possible non plus
de nouveau le même uniq_id a été utilisé pour x1-batt: pour la commande switch et pour le sensor.
bref, il faudrait commencer par être certain de la config reçue