Une lente différente, comme c’est un C3, il a besoin de la version de développement sans undecoded, mais ensuite non décodé peut être activé dessus par la suite.
je ne comprends pas ce que tu veux dire?
en fait je ne comprend pas l’intérêt de la version « undecoded » non plus dans ce cas précis.
Au contraire, je trouve que la version « full » est plus intéressante
j’ai:
2 pi0 avec theengsgateway
2 esp32 avec omg (version « esp32dev-ble »)
avec ce setup, je n’ai aucun point faible: si theengsgateway n’est plus dispo, les esp peuvent malgré tout fonctionner indépendamment et vice versa
Les 4 publient sur leur propre topic mqtt; c’est plugin-mqttdiscovery qui se charge de faire le lien avec l’équipement jeedom lorsque c’est le même device.
avoir la version undecoded veut dire que si mes pi avec theengsgateway ne sont plus dispo, plus rien ne fonctionne.
C’est vrai, mais ce n’est bon que si vous n’avez pas d’iPhone, d’iPad ou d’Apple Watch que vous souhaitez avoir comme un device tracker. Comme jusqu’à présent, seul TGW peut décoder des périphériques MAC aléatoires.
Et aussi pour tout autre appareil que vous utilisez comme device trackers.
S’ils quittent la réception d’un de vos OMG ESP32, un message AWAY sera envoyé, même s’il est toujours présent sur un autre ESP32 avec OMG ou TGW.
Cela pourrait être différent avec Jeedom, car je pense que Jeedom a son propre délai d’attente pour les trackers?!?
Si vous n’avez que des capteurs, pas de trackers d’appareils et pas d’appareils Apple, alors oui, votre configuration avec OpenMQTTGateways complet séparé est meilleure, car ils fonctionnent tous indépendamment, but @Heliospeed mais John a son iPhone.
J’espère que cela explique les différences dans les configurations.
effectivement, dans plugin-mqttdiscovery je n’utilise pas la gestion de présence et donc je n’utilise pas le message « AWAY », je « recalcule » l’info directement pour ne pas être impacté
Non pour moi elle n’est pas compatible avec TGW (enfin techniquement je ne sais pas comment le vérifier). Ce que je sais c’est que le pommeau ne remonte pas via le plugin-tgw. Il remonte dans les équipements inconnus. Je m’en sert pour détecter le début et la fin d’une douche avec la présence.
Via un scénario développé par @rootard, je fais une estimation du débit d’eau en fonction du temps (RTEX douche connectée Hydrao Blea - #11 par rootard).
Maintenant s’il y a une manipulation a faire pour récupérer des trames bluetooth, je suis preneur pour aider pour faire reconnaitre ce pommeau de douche.
Bonjour Mips,
Je ne suis pas sur de tout comprendre.
Le pommeau attend que l’application mobile se connecte pour émettre ces infos ?
Comment je peux vérifier ces informations ?
D’ailleurs j’utilise ton plugin pour récupérer les infos du cloud mais le problème c’est qu’il faut faire une synchro manuellement avec un mobile ce qui n’est pas pratique pour un suivi quotidien (car je ne le fais pas assez régulièrement).
il faudrait arriver à simuler une application mobile qui attend en permanence pour émettre sur leur cloud mais bon ce n’est pas idéal.
Ensuite, l’ESP32 avec OpenMQTTGateway non décodé ne fonctionnera pas en tant qu’extension.
Je ne sais pas si et comment Bluetooth peut être étendu à d’autres plug-ins Bluetooth dans Jeedom. Vous devrez donc peut-être suivre la voie RPi pour la pomme de douche.
Ou si vous pouvez toujours simplement ajouter l’adresse MAC à TGW pour activer / désactiver la présence.
Maintenant s’il y a une manipulation a faire pour récupérer des trames bluetooth, je suis preneur pour aider pour faire reconnaitre ce pommeau de douche.
Si les propriétés ne peuvent être obtenues que par connexion, ce n’est pas possible avec TGW, mais vous pouvez vérifier avec MQTT Explorer si la pomme de douche envoie des données publicitaires lorsqu’elle est active, en activant Données publicitaires dans les paramètres TGW.
Mais les détails de la connexion semblent également être disponibles, donc avec les fonctions OpenMQTTGateway READ et WRITE, il devrait également être possible d’obtenir les valeurs réelles par connexion Bluetooth locale - ou créez un plug-in de connexion pour Hydrao
@rootard Si je comprends bien, vous ne vous connectez pas actuellement?
Je ne sais pas si j’ai tout compris, mais j’ai activer l’option indiqué et effectivement le pommeau remonte mais il n’y a pas d’information de type « manufacturer_data ».
Voici un exemple de ligne qui remonte dans le plugin tgw:
et dans MQTTDiscovery : "8F6422954C21":{"name":"HYDRAO_SHOWER","id":"---MAC-ADDRESS---","rssi":-89}
Je n’ai pas rajouté l’adresse MAC à TGW, je ne sais pas si c’est possible depuis le plugin de Mips. En revanche dans le plugin MQTTDiscovery, j’ai l’info qui remonte ce qui permet d’avoir la présence de la couchette en fonctionnement.
EDIT : J’ai refais le même test en utilisant l’application HYDRAO, la couchette ne communique pas plus d’éléments via ce canal.
S’il ne s’agit jamais que de la seule information dans les données publicitaires, les propriétés ne peuvent être obtenues que par connexion.
J’ai juste supposé qu’Hydrao pourrait également envoyer des données publicitaires avec manufacturerdata et/ou servicedata, comme cela semblait possible ici :
Mais je dois aussi admettre que ma mauvaise connaissance du français a pu me faire mal comprendre certains des faits de l’autre fil de discussion d’Hydrao. Je m’en excuse donc.
Bonjour
Effectivement ce pommeau doit être interrogé si on veut obtenir les infos de durée et de volume. Ca fonctionnait avec le plugin-blea mais j’ai cru comprendre que ce n’était pas possible via tgw.
Pour ma part je me contente d’une estimation en mesurant le temps de connexion car sans eau elle n’est pas active. Je sais pas vous mais personnellement pour la durée de douche je ne suis pas a 30s près non plus…
Ne vous excusez pas, je pensais que vous étiez français à vous lire
La bonne nouvelle, c’est que d’après votre dernier lien côté HomeAssistant on dirait que c’est possible de se connecter pour récupérer l’info en bluetooth.
C’est peut-être portable dans jeedom.
Merci pour tes réponses j’apprend pleins de choses.
