Et je me rend compte qu’il va manquer un point si je voulais vraiment remplacer blea, sauf si j’ai loupé une fonctionnalité et c’est pour ca que je l’expose ici: le retour d’état.
Pour les nut, il n’y a pas vraiment d’info pertinente qui remonte, rssi etc on s’en fiche un peu (en tout cas moi je m’en fiche, ce qui m’intéresse c’est uniquement la présence)
si on le capte => il est présent et
si on ne le capte plus pendant x secondes/minutes => on considère qu’il n’est plus là, car forcément, le nut n’annonce pas qu’il est parti (ou alors il l’a fait mais personne ne l’a entendu, j’hésite encore )
Bref: y a-t-il moyen sous jmqtt de faire un retour d’état après x secondes?
ou autrement (mieux?) d’avoir une commande binaire sur un équipement (lui-même lié à un topic spécifique) pour savoir s’il y a eu un update sur le topic (ou un des sous-topic) depuis les x dernières secondes/minutes?
dans le cas du nut, si update récent cela voudrait dire « nut présent » et si pas « nut absent »
j’ai peu être pas tous saisie, mais si je comprend bien, il n’y a pas vraiment d’état (présence) qui remonte ?
justement si cette info ne t’est pas nécessaire, pourquoi ne l’utiliser comme une présence en le passant en binaire (abs) ? et ainsi utiliser la gestion des valeurs (Valeur retour d’état) dans la configuration de la commande. cela implique d’activer la gestion des répétitions, mais sa devrait faire le job ?
Je pense que l’info brut de présence comme tu l’évoque @Mips n’étant pas présente dans le json du topic alors non pas possible.
Il faut travailler autour du RSSI pour le coup si 200 alors pas là si différents alors présent voir même plus la valeur est petite plus on est proche de l’antenne.
Bref ensuite il faut demander au dev OMG s’il peuvent ajouter aux infos déjà existantes celle ci qui arrange bcp de monde au final
Alors ce que tu demandes ressemble quand même vachement à un virtuel avec une valeur à « stateDuration(#cmd_nut#) < 120 » et un update toutes les minutes
Mais sinon, oui, la fonction de présence d’OMG est peut-être encore un peu rudimentaire. Il faudrait, pourquoi pas, proposer un PR pour intégrer un timeout sur ce qui a été annoncé comme présent.
Il y a effectivement pleins de pistes intéressantes, mais le virtuel reste simple et rapide. Tu as regardé ce que fait l’application Android/iOS OwnTracks ? C’est assez puissant et géré « dans l’autre sens » : connaissant sa position GPS et les différentes zones, le tel publié directement où et dans quelle zone il est !
C’est une idée, mais il y a des cas où tu ne le verra pas un NUT à <-80dBm, par exemple si tu l’enfermes dans un micro-onde (cage de Faraday), un coup il sera à 70dBm, un coup plus là. Ce serait à OMG de garder une liste de tout ce qu’il a vu de « présent » et, disons 2 minutes plus tard, de les déclarer non présent si plus rien.
De ce que j’ai vu dans la gestion BT d’OMG, c’est les évènements BT qui déclenchent les envoies de messages mqtt, il n’y a pas de conservation des choses présentes ou non à date
Le problème n’est pas d’avoir une info présence, ça c’est facile, mais bien de savoir qu’il n’est plus là car justement le nut n’est pas capable de prévenir qu’il est parti puisqu’il est parti.
Je ne pense pas que ça soit à omg de le gérer, même pas sur que ça soit possible, il est stateless lui.
C’est bien le retour d’état que @Phpvarious propose que je cherchais; hier j’étais convaincu que ça existait mais je ne trouvais plus, je devais être trop fatigué
Je pense que ça peut faire l’affaire.
Cool nous pensions avec @Phpvarious que tu voulais éviter ceci mais pas que tu étais fatigué
Tu nous diras si ça marche nous recevons le matériel dans les heures qui viennent pour certain et mardi pour ma part.
Cela va compléter le tuto de @Bad du coup
J’ai configuré ça ce matin pour tester sur la journée
Bémol: il faut effectivement activer la répétition de valeur sinon le retour d’état n’est pas « prolongé » (si c’est la même valeur qui se répète le retour d’état reste programmé à l’heure d’origine, ce qui n’est pas super logique pour moi mais soit, probablement difficile de changer ce type de comportement sans impacter 50% des users)
Mais activer la répétition des valeurs a un impact sur la suite (scénario etc).
D’un autre côté il faudra de toute façon un virtuel au-dessus si on a plusieurs « antenne omg » pour combiner les infos de présence et donc on peut désactiver la répétition des valeurs dans le virtuel.
(idée en passant: à tester ce qu’il se passe si on configure plusieurs omg pour publier sur le même topic , avantage de simplifier la remontée des infos des équipements sans devoir multiplier les config mqtt mais collisions sur les données des omg)
Tout ça reste quand même beaucoup plus de config à faire à la main que blea, on manque d’un concentrateur qui ferait cette réconciliation d’info pour nous.
En fait, on travaille sur jMQTT pour pouvoir souscrire à un topic type bt/+/BTtoMQTT/beacon et donc récupérer directement les valeurs en provenance de plusieurs gateways. C’est déjà le cas pour HA ou autre…
Ça répondra au besoin de « fédération des infos ». Mais oui, il n’y a pas jolie carte où de remontée/consolidation directement dans OMG.
Par contre, il y a eu un PR super intéressant sur OMG il y a quelques temps pour remonter les infos BT en raw et les faire analyser par un programme en central. L’intégration d’antennes OMG pourrait être un ajout sur le plugin BLEA.
Super intéressant tout ça
Cela contribue grandement à I’usage du mqtt avec le BT
Reste à accepter les RFXCom et une très grosse partie des protocoles traditionnels seront mqtt
Il m’avait semblé qu’en MQTT, il y avait des topics qui permettaient de savoir si l’équipement était en ligne ou non.
C’est le cas avec les shelly et les dingtian.
)
:
mais pas que tu étais fatigué 
, avantage de simplifier la remontée des infos des équipements sans devoir multiplier les config mqtt mais collisions sur les données des omg)