Présence Theengs: utiliser l’Apple IRK

rootard · Février 13, 2024, 7:48

Salut

N’ayant pas de Mac j’ai récupéré l’IRK de mon iPad avec un ESP32 via cette méthode
J’obtiens ca:

Si j’ai bien compris la clé (valeurs hexa concaténées sans les 0x) doit être encodée en base64 comme indiqué ici ?

J’ai testé avec la clé encodée dans l’ordre et dans l’ordre inversé, rien n’est remonté dans MQTT Explorer…qui me récupère bien mes autres devices par ailleurs
J’ai bien vérifié avoir enlevé les filtres APPLE_CONT,APPLE_CONTAT

@1technophile des suggestions? il faut mettre presence a true?

J’utilise directement l’image docker theengs:

{
    "host": "localhost",
    "pass": "xxxxx",
    "user": "jeedom",
    "port": 1883,
    "publish_topic": "theengs/blea_local/BTtoMQTT",
    "subscribe_topic": "theengs/blea_local/commands",
    "presence_topic": "home/presence/TheengsGateway",
    "presence": false,
    "publish_all": true,
    "publish_advdata": false,
    "ble_scan_time": 5,
    "ble_time_between_scans": 5,
    "tracker_timeout": 120,
    "log_level": "WARNING",
    "lwt_topic": "theengs/blea_local/LWT",
    "discovery": true,
    "hass_discovery": true,
    "discovery_topic": "homeassistant/sensor",
    "discovery_device_name": "blea_local",
    "discovery_filter": "[IBEACON,GAEN,MS-CDP]",
    "scanning_mode": "active",
    "adapter": "hci0",
    "time_sync": "[]",
    "time_format": "0",
    "ble": true,
    "enable_tls": false,
    "enable_websocket": false
,    "identities": {"xx:xx:xx:xx:xx:xx":"xxxx="}
}

Merci

DigiH · Février 13, 2024, 9:01

Salut @rootard

Avez-vous converti l’hex que vous avez obtenu en base64? Avec un convertisseur comme

des suggestions? il faut mettre presence a true?

Non, ce n’est pas nécessaire

"identities": {"xx:xx:xx:xx:xx:xx":"xxxx="}

c’est tout ce qu’il faut, avec l’IRk base64 correct.

Votre IRK se termine-t-il par …== ?

    "enable_websocket": false
,    "identities": {"xx:xx:xx:xx:xx:xx":"xxxx="}

De plus, la virgule doit remonter après false, mais cela ne devrait pas vous causer de problème.

rootard · Février 13, 2024, 9:31

Bonsoir

Effectivement j’avais utilisé la commande debian base64 et il n’y avait qu’un seul =
Maintenant ca fonctionne merci beaucoup

Par contre c’est bizarre mon iPad est détecté comme une iWatch?? Pas grave

{
  "id": "xx:xx:xx:xx:xx:xx",
  "rssi": -55,
  "rssi": -65,
  "brand": "Apple",
  "model": "Apple Watch",
  "model_id": "APPLEWATCH",
  "type": "BODY",
  "unlocked": false
}

DigiH · Février 13, 2024, 9:48

C’est bien que cela fonctionne maintenant

Par contre c’est bizarre mon iPad est détecté comme une iWatch?? Pas grave

C’est étrange, n’était-ce que brièvement, et est-ce que cela montre correctement

"model": "Apple iPhone/iPad",
"model_id": "APPLEDEVICE",

maintenant?

Si ce n’est pas le cas, pourriez-vous activer Publier les émissions Bluetooth et les donnés avancés, et postez un autre message?

rootard · Février 13, 2024, 9:52

Je ferai le test demain

rootard · Février 14, 2024, 6:18

Bonsoir @DigiH

Je suppose qu’il s’agit de -padv PUBLISH_ADVDATA ?
Apparament cette option n’est pas disponible en mode docker?

J’ai poursuivi mes tests
J’utilise la dernière release theengs/gateway avec docker sur raspbian buster:
theengs/gateway latest 05ebd70d673c 3 weeks ago 396MB

Mon iPad et mon iPhone sont sous iOS 16.6.1. L’iPhone est bien détecté en tant que tel par contre l’iPad est toujours vu comme iWatch. En soi ca ne me dérange pas.

Par contre pour les 2 devices contrairement au plugin-phone_detection la présence n’est détectée que quand le device est déverrouillé, donc c’est quasi inutilisable au quotidien…
De plus l’info unlocked est toujours à false ? Est ce normal?

écran verrouillé:

écran déverrouillé:

DigiH · Février 14, 2024, 7:34

Le PUBLISH_ADVDATA doit être disponible dans la version Docker.

-e PUBLISH_ADVDATA=true \

Avec ces informations supplémentaires, nous devrions voir pourquoi votre iPad est reconnu comme une Apple Watch

Cela se produit avec les iPhones et iPads de certains utilisateurs. Malheureusement, nous n’avons pas encore trouvé quel paramètre le fait fonctionner et lequel ne fonctionne pas.

La présence doit toujours être détectée, quel que soit l’état déverrouillé. Peut-être que la découverte actuelle de device_tracker ne fonctionne pas comme prévu.

Comment les autres utilisateurs de Theengs Gateway détectent-ils la présence et l’absence de leurs appareils Apple ou d’autres trackers? La découverte a-t-elle besoin d’autre chose en plus de device_tracker découverte?

1technophile · Février 14, 2024, 8:12

@Mips pourrais tu nous expliquer cette partie stp?

rootard · Février 15, 2024, 7:06

Bon c’est bien dommage tout ca… ca aurait été top de remplacer les 2 plugin-blea et plugin-phone_detection par un seul daemon theengs. 1 clé USB de moins!

J’ai regardé le code du plugin-phone_detection il utilise bluepy
@1technophile je suppose que theengs n’utilise pas la même lib? Y a t-il un espoir?

Mips · Février 15, 2024, 7:17

C’est la même question qu’ici je pense: Comment fonctionne la détection de présence avec Theengs Gateway / OpenMQTTGateway + plugin Theengs - #3 par Mips

dès qu’un rssi est remonté, le device est flag comme présent (commande jeedom)

après un délai configuré, le device est flag comme absent (tout ca géré par le plugin/jeedom)

Mips · Février 15, 2024, 7:19

Qu’est-ce qui est dommage? que ca ne remonte comme présent que si le device est unlock?
c’est un détail à fixer / comprendre j’imagine vu la réponse de DigiH:

rootard · Février 15, 2024, 7:40

oui ca ne servira pas à grand chose tant qu’on ne pourra pas faire la différence entre absent et déverrouillé

DigiH · Février 15, 2024, 9:46

Je pense que le problème est uniquement dû aux nouvelles versions récentes de Theengs Gateway. Depuis la version 1.3.0, et maintenant avec la dernière version 1.4.0, il y a une découverte device_tracker correcte envoyée, avec un nouvel argument timeout pour Thenegs Gateway.

Je pense qu’auparavant, avant la version 1.3.0, le plugin-mqttdiscovery devait créer un device_tracker à partir d’un binary_sensor!?!

Il devrait certainement être possible de remplacer les deux par Theengs Gateway, si tous vos appareils BLEA précédents sont compatibles.

Il ne nous reste plus qu’à comprendre comment les nouvelles fonctionnalités de Theengs Gateway s’articulent avec la découverte de Jeedom et les paramètres du Plug-In. Ce n’est qu’une question de temps

@Mips J’ai lu que vous avez deux Theengs Gateway et deux OpenMQTTGateways.Utilisez-vous le binary esp32dev-ble-mqtt-undecoded, pour transmettre les réceptions aux Theengs Gateways pour le décodage?

Mips · Février 16, 2024, 5:44

Non pas du tout
C’est comme je dis juste au dessus.

Le timeout qui existe dans theengs il existait déjà dans mqttdiscovery avant et peut être différent pour chaque équipement du coup je vais le garder mais il n’influence pas le « presence » remonté par theengs que je n’utilise pas pour cette gestion, c’est uniquement basé sur le rssi.

Non, chaque device est indépendant, décode et publie directement.
Ainsi si l’un est down les autres continuent de fonctionner.

DigiH · Février 17, 2024, 2:55

Merci, maintenant je comprends mieux - les messages de timeout de Theengs Gateway et OpenMQTTGateway, et aussi le timeout de mqttdiscovery.