hkControl : aqara m1S : ZHWG15LM Aqara Hub M1S Homekit Zigbee 3.0

Plugins Protocole domotique
1

Bonjour nebz,
De mon coté j’ai une aqara m1S : ZHWG15LM Aqara Hub M1S Homekit Zigbee 3.0 https://zigbeealliance.org/fr/zigbee_des-produits/moyeu-aqara-m1s/ 8
Elle est listé dans les produits possiblement compatible il me semble.
Le plugin la détecte bien mais je suis bloqué à l’appairage :

[2021-05-31 17:21:43][INFO] : Découverte de :{"name":"Aqara-Hub-M1S-1617","address":"192.168.1.17","port":"58737","c#":"1","ff":"2","id":"5B:0F:F3:82:XX:XX","md":"ZHWG15LM","pv":"1.1","s#":"1","sf":"1","ci":"2"}
[2021-05-31 17:21:43][INFO] : Modification de l'équipement Aqara-Hub-M1S-1617(5B:0F:F3:82:XX:XX)
[2021-05-31 17:23:33][INFO] : Demande de d'appairage... : id=5B%3A0F%3AF3%3A82%3AXX%3AXX&address=192.168.1.17&port=58737&pin=XXX-XX-XXX&typeId=2&name=Aqara-Hub-M1S-1617
[2021-05-31 17:23:33][INFO] : Appairage:ko-pairSetup

J’ai tenté ce jour avec le plugin en version stable ou beta j’ai le meme message d’erreur comme si mon code d’appairage était mauvais.
J’ai donc essayé avec un iPhone et l’appairage se passe bien (je la dé-appaire ensuite pour faire mes tentatives avec le plugin, j’ai quand meme essayé également appairé a apple ou en cours d’appairage, rien ne passe).
Je suis sous jeedom stable (y compris raspbian buster) à jour sur un RPI4 en 64 bits, et aucune erreur sur l’installation des dépendances du plugin.

Merci d’avance pour votre aide !!

JJ

2

Hello, peux tu fournir l’autre Log ? HkControl_daemon

3

Non non elle est bien compatible

4

Aucun soucis, je le trouvais un peu moins parlant :

31-05-2021 17:07:48 | Info | L'accessoire Aqara-Hub-M1S-1617 est éligible à l'ajout !
31-05-2021 17:08:10 | Info | Reçu une demande d'appairage...
31-05-2021 17:08:32 | Info | Reçu une demande d'appairage...
31-05-2021 17:08:40 | Info | Reçu une demande d'appairage...
31-05-2021 17:11:24 | Info | Reçu une demande d'appairage...
31-05-2021 17:11:44 | Info | Reçu une demande d'appairage...
31-05-2021 17:12:08 | Info | Reçu une demande d'appairage...
31-05-2021 17:12:09 | Info | Reçu une demande d'appairage...
31-05-2021 17:12:11 | Info | Reçu une demande d'appairage...
31-05-2021 17:19:07 | Info | Recu de jeedom: Demande d'arret
31-05-2021 17:19:07 | Info | Exit
31-05-2021 17:21:43 | Info | Démarrage démon hkControl...
31-05-2021 17:21:43 | Info | Démon prêt et à l'écoute !
31-05-2021 17:21:43 | Info | L'accessoire Philips hue - 28BD38 est éligible à l'ajout !
31-05-2021 17:21:43 | Info | L'accessoire Aqara-Hub-M1S-1617 est éligible à l'ajout !
31-05-2021 17:23:33 | Info | Reçu une demande d'appairage...
31-05-2021 21:00:24 | Info | Reçu une demande d'appairage...
5

Oui s’il est pas en debug :slight_smile:

Peux tu donc le passer en debug, puis relancer le démon et retenter un appairage ?

6

Oups, effectivement j’ai oublié de le repasser en mode débug une fois la version beta du plugin installé.
Voici les logs après deux nouvelle demande d’appairage:

01-06-2021 00:27:28 | Info | Recu de jeedom: Demande d'arret
01-06-2021 00:27:28 | Info | Exit
01-06-2021 00:27:40 | Info | Démarrage démon hkControl...
01-06-2021 00:27:40 | Debug | urlJeedom = http://192.168.1.100/core/api/jeeApi.php
01-06-2021 00:27:40 | Debug | apiKey = XXXXXXXXXXXXXXXXXXXXX
01-06-2021 00:27:40 | Debug | serverPort = 55073
01-06-2021 00:27:40 | Debug | logLevel = debug
01-06-2021 00:27:40 | Debug | pairingFile = /var/www/html/plugins/hkControl/data/pairings.json
01-06-2021 00:27:40 | Debug | pairings = {}
01-06-2021 00:27:40 | Info | Démon prêt et à l'écoute !
01-06-2021 00:27:41 | Info | L'accessoire Philips hue - 28BD38 est éligible à l'ajout !
01-06-2021 00:28:03 | Info | Reçu une demande d'appairage...
01-06-2021 00:28:23 | Info | Reçu une demande d'appairage...
7

On voit rien… ce qui n’est pas normal… tu peux me décrire ton réseau entre jeedom et ta gateway ? (Switch, routeur, box, point d’accès, etc)

8

Un seul lan, j’utilise deja deux gtw xiaomi ancienne génération avec le plugin xiaomi.
Ces 3 gateway sont connecté sur le meme point d’accès wifi (merci au 2,4 only) qui n’est pas en mode routeur (ne nat pas le réseau).

9

Et le plugin voit bien le changement de port de cette nouvelle gtw :

01-06-2021 00:34:38 | Debug | Aurevoir reçu : {"name":"Aqara-Hub-M1S-1617","address":"192.168.1.17","port":59032,"c#":1,"ff":2,"id":"5B:0F:F3:82:XX:XX","md":"ZHWG15LM","pv":"1.1","s#":1,"sf":1,"ci":2}

01-06-2021 00:43:12 | Debug | Aurevoir reçu : {"name":"Aqara-Hub-M1S-1617","address":"192.168.1.17","port":59032,"c#":1,"ff":2,"id":"5B:0F:F3:82:XX:XX","md":"ZHWG15LM","pv":"1.1","s#":1,"sf":1,"ci":2}
10

heu on ne voit justement aucun changement de port…
image
par contre elle se déconnecte… je pense quand meme à un problème de réseau…

ca ne réponds pas vraiment à ma question, peux-tu décrire tous les éléments réseaux entre jeedom et ta gateway ?
example chez moi :
ma gateway est en wifi sur un point d’accès unifi, qui est relié en réseau cablé à un switch unifi sur lequel est relié en réseau cablé ma jeedom. il y a donc un point d’accès et un switch entre les deux !

11

un autre utilisateur avait aussi des « au revoirs » qui venaient du matériel… peux-tu peut-etre tenter un reset de ta passerelle ? et la remettre sur le wifi ?

1 « J'aime »
12

Effectivement j’ai pris le mauvais exemple mdr :
01-06-2021 00:33:26 | Debug | Aurevoir reçu : {« name »:« Aqara-Hub-M1S-1617 »,« address »:« 192.168.1.17 »,« port »:46849,« c# »:1,« ff »:2,« id »:« 5B:0F:F3:82:2D:82 »,« md »:« ZHWG15LM »,« pv »:« 1.1 »,« s# »:1,« sf »:1,« ci »:2}
01-06-2021 00:33:26 | Info | L’accessoire Aqara-Hub-M1S-1617 est éligible à l’ajout !
01-06-2021 00:33:56 | Info | Reçu une demande d’appairage…
01-06-2021 00:34:38 | Debug | Aurevoir reçu : {« name »:« Aqara-Hub-M1S-1617 »,« address »:« 192.168.1.17 »,« port »:59032,« c# »:1,« ff »:2,« id »:« 5B:0F:F3:82:2D:82 »,« md »:« ZHWG15LM »,« pv »:« 1.1 »,« s# »:1,« sf »:1,« ci »:2}
01-06-2021 00:34:39 | Info | L’accessoire Aqara-Hub-M1S-1617 est éligible à l’ajout !
01-06-2021 00:34:39 | Info | Reçu une demande d’appairage…
01-06-2021 00:34:42 | Info | Reçu une demande d’appairage…
01-06-2021 00:35:47 | Info | Reçu une demande d’appairage…
01-06-2021 00:35:51 | Info | Reçu une demande d’appairage…
01-06-2021 00:43:12 | Debug | Aurevoir reçu : {« name »:« Aqara-Hub-M1S-1617 »,« address »:« 192.168.1.17 »,« port »:59032,« c# »:1,« ff »:2,« id »:« 5B:0F:F3:82:2D:82 »,« md »:« ZHWG15LM »,« pv »:« 1.1 »,« s# »:1,« sf »:1,« ci »:2}

sur celle du dessus il y a bien eut un changement de port .

Ces 3 gateway sont connectés en wifi à un point d’accès qui est relié en ethernet à un switch netgear sur lequel mon jeedom est également connecté en éthernet.
J’ai deja tenté un reset de la gateway sans succès mais je vais tenter à nouveau et tester sur un autre point d’accès (j’ai un wrt54gl qui traine quelque part).

13

Il est gerable ? Vérifie que tu laisses bien passer le multicast.

14

Les changements de ports sont gérés quand la passerelle est appairée, c’est la passerelle qui envoi son nouveau port, ça arrive quand tu ajoutes un nouvel équipement sur celle ci… mais ça doit être un « bonjour » et pas un au revoir… ce qui me fait encore penser à ton réseau qui ne relaye pas le multicast correctement, vérifie aussi dans ton point d’accès … les choses à vérifier :

Igmp snooping
mDNS
Multicast DNS
Multicast

15

Il est bien gérable et je laisse passer le multicast, d’ailleurs j’ai deja deux gateway xiaomi ancienne génération mais qui utilisent également le multicast et je n’ai aucun soucis avec.
Et oui dans les logs je n’ai que des au revoir, je n’ai jamais croisé un bonjour …

16

Un petit exemple avec mon ancienne gtw :

pi@JeedomBureau:~ $ sudo tcpdump -i eth0 -s0 -vv host 192.168.1.51 and net 224.0.0.0/4
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 byte
12:49:51.770737 IP (tos 0x0, ttl 255, id 51757, offset 0, flags [none], proto UDP (17), length 163)
    192.168.1.51.4321 > 224.0.0.50.9898: [udp sum ok] UDP, length 135
12:50:01.758917 IP (tos 0x0, ttl 255, id 51760, offset 0, flags [none], proto UDP (17), length 163)
    192.168.1.51.4321 > 224.0.0.50.9898: [udp sum ok] UDP, length 135
12:50:11.739012 IP (tos 0x0, ttl 255, id 51763, offset 0, flags [none], proto UDP (17), length 163)
    192.168.1.51.4321 > 224.0.0.50.9898: [udp sum ok] UDP, length 135
12:50:21.715692 IP (tos 0x0, ttl 255, id 51765, offset 0, flags [none], proto UDP (17), length 163)
    192.168.1.51.4321 > 224.0.0.50.9898: [udp sum ok] UDP, length 135
12:50:26.008804 IP (tos 0x0, ttl 255, id 51767, offset 0, flags [none], proto UDP (17), length 134)
    192.168.1.51.4321 > 224.0.0.50.9898: [udp sum ok] UDP, length 106
12:50:31.694318 IP (tos 0x0, ttl 255, id 51771, offset 0, flags [none], proto UDP (17), length 163)
    192.168.1.51.4321 > 224.0.0.50.9898: [udp sum ok] UDP, length 135
17

D’ailleurs je reçoit bien du multicast de la nouvelle gateway qui est en 192.168.1.17 :

pi@JeedomBureau:~ $ sudo tcpdump -i eth0 -s0 -vv host 192.168.1.17 and net 224.0.0.0/4
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes


12:50:58.600463 IP (tos 0x0, ttl 255, id 13418, offset 0, flags [DF], proto UDP (17), length 221)
    192.168.1.17.mdns > 224.0.0.251.mdns: [udp sum ok] 0*- [0q] 2/0/2 17.1.168.192.in-addr.arpa. (Cache flush) PTR Aqara-Hub-M1S-8F58.local., 8.5.F.8.5.2.E.F.F.F.4.4.F.E.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. (Cache flush) PTR Aqara-Hub-M1S-8F58.local. ar: 17.1.168.192.in-addr.arpa. (Cache flush) NSEC, 8.5.F.8.5.2.E.F.F.F.4.4.F.E.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. (Cache flush) NSEC (193)
12:50:58.619680 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
    192.168.1.17 > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 224.0.0.251 to_ex { }]
12:50:59.109033 IP (tos 0x0, ttl 255, id 13430, offset 0, flags [DF], proto UDP (17), length 169)
    192.168.1.17.mdns > 224.0.0.251.mdns: [udp sum ok] 0 [2q] [3n] ANY (QU)? Aqara-Hub-M1S-1617._hap._tcp.local. ANY (QU)? Aqara-Hub-M1S-8F58.local. ns: Aqara-Hub-M1S-1617._hap._tcp.local. SRV Aqara-Hub-M1S-8F58.local.:36281 0 0, Aqara-Hub-M1S-8F58.local. A 192.168.1.17, Aqara-Hub-M1S-8F58.local. AAAA fe80::56ef:44ff:fe25:8f58 (141)
12:50:59.368999 IP (tos 0x0, ttl 255, id 13445, offset 0, flags [DF], proto UDP (17), length 169)
    192.168.1.17.mdns > 224.0.0.251.mdns: [udp sum ok] 0 [2q] [3n] ANY (QM)? Aqara-Hub-M1S-1617._hap._tcp.local. ANY (QM)? Aqara-Hub-M1S-8F58.local. ns: Aqara-Hub-M1S-1617._hap._tcp.local. SRV Aqara-Hub-M1S-8F58.local.:36281 0 0, Aqara-Hub-M1S-8F58.local. A 192.168.1.17, Aqara-Hub-M1S-8F58.local. AAAA fe80::56ef:44ff:fe25:8f58 (141)
12:50:59.609559 IP (tos 0x0, ttl 255, id 13454, offset 0, flags [DF], proto UDP (17), length 221)
    192.168.1.17.mdns > 224.0.0.251.mdns: [udp sum ok] 0*- [0q] 2/0/2 17.1.168.192.in-addr.arpa. (Cache flush) PTR Aqara-Hub-M1S-8F58.local., 8.5.F.8.5.2.E.F.F.F.4.4.F.E.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. (Cache flush) PTR Aqara-Hub-M1S-8F58.local. ar: 17.1.168.192.in-addr.arpa. (Cache flush) NSEC, 8.5.F.8.5.2.E.F.F.F.4.4.F.E.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. (Cache flush) NSEC (193)
12:50:59.719176 IP (tos 0x0, ttl 255, id 13462, offset 0, flags [DF], proto UDP (17), length 169)
    192.168.1.17.mdns > 224.0.0.251.mdns: [udp sum ok] 0 [2q] [3n] ANY (QM)? Aqara-Hub-M1S-1617._hap._tcp.local. ANY (QM)? Aqara-Hub-M1S-8F58.local. ns: Aqara-Hub-M1S-1617._hap._tcp.local. SRV Aqara-Hub-M1S-8F58.local.:36281 0 0, Aqara-Hub-M1S-8F58.local. A 192.168.1.17, Aqara-Hub-M1S-8F58.local. AAAA fe80::56ef:44ff:fe25:8f58 (141)
12:50:59.979391 IP (tos 0x0, ttl 255, id 13470, offset 0, flags [DF], proto UDP (17), length 338)
    192.168.1.17.mdns > 224.0.0.251.mdns: [udp sum ok] 0*- [0q] 6/0/2 Aqara-Hub-M1S-1617._hap._tcp.local. (Cache flush) TXT "c#=1" "ff=2" "id=3D:4C:89:29:AE:21" "md=ZHWG15LM" "pv=1.1" "s#=1" "sf=1" "ci=2" "sh=91GK7A==", _services._dns-sd._udp.local. PTR _hap._tcp.local., _hap._tcp.local. PTR Aqara-Hub-M1S-1617._hap._tcp.local., Aqara-Hub-M1S-1617._hap._tcp.local. (Cache flush) SRV Aqara-Hub-M1S-8F58.local.:36281 0 0, Aqara-Hub-M1S-8F58.local. (Cache flush) A 192.168.1.17, Aqara-Hub-M1S-8F58.local. (Cache flush) AAAA fe80::56ef:44ff:fe25:8f58 ar: Aqara-Hub-M1S-1617._hap._tcp.local. (Cache flush) NSEC, Aqara-Hub-M1S-8F58.local. (Cache flush) NSEC (310)
12:51:00.989083 IP (tos 0x0, ttl 255, id 13526, offset 0, flags [DF], proto UDP (17), length 338)
    192.168.1.17.mdns > 224.0.0.251.mdns: [udp sum ok] 0*- [0q] 6/0/2 Aqara-Hub-M1S-1617._hap._tcp.local. (Cache flush) TXT "c#=1" "ff=2" "id=3D:4C:89:29:AE:21" "md=ZHWG15LM" "pv=1.1" "s#=1" "sf=1" "ci=2" "sh=91GK7A==", _services._dns-sd._udp.local. PTR _hap._tcp.local., _hap._tcp.local. PTR Aqara-Hub-M1S-1617._hap._tcp.local., Aqara-Hub-M1S-1617._hap._tcp.local. (Cache flush) SRV Aqara-Hub-M1S-8F58.local.:36281 0 0, Aqara-Hub-M1S-8F58.local. (Cache flush) A 192.168.1.17, Aqara-Hub-M1S-8F58.local. (Cache flush) AAAA fe80::56ef:44ff:fe25:8f58 ar: Aqara-Hub-M1S-1617._hap._tcp.local. (Cache flush) NSEC, Aqara-Hub-M1S-8F58.local. (Cache flush) NSEC (310)
12:51:01.619248 IP (tos 0x0, ttl 255, id 13531, of
18

oui tu en recois certains, sinon tu n’aurais pas de « au revoir » ou elle n’aurait pas été découverte, mais on dirait qu’il en manque…je vois pas alors… tu pourras m’envoyer un accès à distance en DM ? soit directement l’interface, soit teamviewer si tu préfères

19

Encore merci pour le temps passé à essayer de comprendre ce qui cloche.
Je reviens vers toi avec une infra minimaliste (wrt54GL + jeedom ethernet / gtw) .

Merci et bravo pour cette réactivité et le temps passé !!!

20

image
image713×363 14.4 KB

voilà, mon beta-testeur a désappairé et réappairé et ca fonctionne, modèle HM1S-G01 firmware 3.0.8.