Matter/Thread: connecting new device gets stuck in "Checking network connection"

Configuration Matter/Thread
2

Adding to the above:

The matter diagnose file shows this under “server”. Should there be credentials for wifi, etc.?

 "server": {
      "info": {
        "fabric_id": 2,
        "compressed_fabric_id": 13359909646136454457,
        "schema_version": 10,
        "min_supported_schema_version": 9,
        "sdk_version": "2024.7.1",
        "wifi_credentials_set": false,
        "thread_credentials_set": false,
        "bluetooth_enabled": false

I start to believe that HA is not communicating with the matter server

3

A bit long-winded but here it goes …

My understanding is that the HA Companion App uses the underlying Matter/Thread framework supplied by Android, and that the first phase of commissioning involves the underlying framework trying to contact the device via Bluetooth, and give it the Thread credentials for the device to join the Thread network, and if successful, the framework will continue to create its own Matter Fabric and get the device to join that Fabric via the mobile device’s WiFi. If this works, then in the next phase of commissioning, the HA Companion App will then talk to the HA Matter Server to commission the device by “sharing” the device with a newly created HA Matter Fabric via HA’s LAN port.

It is my understanding that the “Checking network connection” is the part where the underlying Android Framework has told the device what the Thread credentials are, and the device is trying to join the Thread network, but has failed. The likely cause is that the Thread dataset given to the device is not the correct one. Couple of things to check/try:

  • In HA Thread Integration when you have setup the “preferred network” with the OTBR, there should also be an icon of a box with a key inside it. This means the Thread dataset (i.e. “keys”) are the ones handed to the HA Companion App for Commissioning.
  • Syncing the Thread dataset in Android can have a false success. It has been mentioned that if you repeat the syncing process and get the same successful result, then it indeed was successful, otherwise you should get a failure.
  • Android uses and keeps the first Thread dataset that it learned about, and apparently does not do anything with any other Thread datasets it has. So if by chance there was a different Thread dataset used beforehand, then synching the datasets probably wont do any good. The fix is said to involve clearing out Google Play store which can also remove other data you may want to keep.

If all of that looks good, then the next possibility is that the mobile device was unable to receive mDNS advertisements from the HA OTBR advertising the newly joined Thread device. This could happen if the HA LAN is not bridged to the mobile device’s WiFi network.

Hope this helps.

1 Like
4

In particular, you might run into this issue: Update home-assistant network Thread credentials not possible · Issue #4146 · home-assistant/android · GitHub. If “Sync Thread credentials” → “:white_check_mark: Updated network from Home Assistant to this device” every time you suffer the problem. Check the workaround.

1 Like
5

Not sure that I understand this correctly. My network topology consists of a simple router that provides the WiFi and to which LAN devices are connected. WiFi and LAN use the same net.

I did this yesterday but didn’t recheck until now. Sadly, trying to connect a device now throws “Matter is not available” on the smartphone. Looks as if I damaged something.

I verified on the RpI5 and relaunched the server process with ha addons restart core_matter_server. to be sure. Server is running:

Add-on: Matter Server
Matter WebSocket Server for Home Assistant Matter support.
Add-on version: 6.5.1
You are running the latest version of this add-on.
System: Debian GNU/Linux 12 (bookworm) (aarch64 / raspberrypi5-64)
Home Assistant Core: 2024.9.3
Home Assistant Supervisor: 2024.09.1
…
2024-10-02 08:39:10.302 (MainThread) INFO [matter_server.server.server] Matter Server successfully initialized.

Then checked HA Companion on my wife’s Android phone, Matter is reachable, so definitely something messed up on my mobile.

Sigh…

6

Hello,

I had the exact same issue with my installation.

The only way to resolve the issue is by following @agners procedure Fix for issue of credentials sync

I succefuly paired the smart window to my HA…

I also did it using the Matter server UI (you go to comissionning, write the matter code and it should add itself without the phone)…

When you get it working let me know I have further questions about this smart handle :slight_smile: :

-Try to use the lock, what does it do on your side ? (me it does a tickling sound and then nothing) …

7

Salut Pierre,

I did go through these steps already yesterday. Now my Android setup is f**ed up and the phone tells me that Matter is not available. Shame that one has to erase all data to update Thread credentials on Android.

Meanwhile I removed Thread and Matter as well as OTBR on my HA and restarted. The OTBR is automatically set up again to link with the SkyConnect stick. I reinstalled Thread and Matter and will go through the credential fix once again.

I checked the logs, the OTBR shows some interesting mDNS entries that I don’t understand. Maybe @agners and @wmaker have an idea how to interpret this.

-----------------------------------------------------------
 Add-on: OpenThread Border Router
 OpenThread Border Router add-on
-----------------------------------------------------------
 Add-on version: 2.11.0
 You are running the latest version of this add-on.
 System: Debian GNU/Linux 12 (bookworm)  (aarch64 / raspberrypi5-64)
 Home Assistant Core: 2024.9.3
 Home Assistant Supervisor: 2024.09.1
-----------------------------------------------------------
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
s6-rc: info: service banner successfully started
s6-rc: info: service universal-silabs-flasher: starting
[10:09:22] INFO: Checking /dev/ttyUSB0 identifying Home Assistant Connect ZBT-1 from Nabu Casa.
[10:09:22] INFO: Starting universal-silabs-flasher with /dev/ttyUSB0
2024-10-02 10:09:22.583 RASPI-HA universal_silabs_flasher.flash INFO Extracted GBL metadata: NabuCasaMetadata(metadata_version=1, sdk_version='4.4.3', ezsp_version=None, ot_rcp_version='SL-OPENTHREAD/2.4.0.0_GitHub-7074a43e4' (2.4.0.0), cpc_version=None, fw_type=<FirmwareImageType.OT_RCP: 'ot-rcp'>, baudrate=460800)
2024-10-02 10:09:22.583 RASPI-HA universal_silabs_flasher.flasher INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
2024-10-02 10:09:29.832 RASPI-HA universal_silabs_flasher.flasher INFO Probing ApplicationType.SPINEL at 460800 baud
2024-10-02 10:09:35.973 RASPI-HA universal_silabs_flasher.flasher INFO Detected ApplicationType.SPINEL, version 'SL-OPENTHREAD/2.4.0.0_GitHub-7074a43e4' (2.4.0.0) at 460800 baudrate (bootloader baudrate None)
2024-10-02 10:09:35.973 RASPI-HA universal_silabs_flasher.flash INFO Firmware version 'SL-OPENTHREAD/2.4.0.0_GitHub-7074a43e4' (2.4.0.0) is flashed, not re-installing
s6-rc: info: service universal-silabs-flasher successfully started
s6-rc: info: service otbr-agent: starting
[10:09:36] INFO: Setup OTBR firewall...
[10:09:36] INFO: Starting otbr-agent...
[NOTE]-AGENT---: Running 0.3.0-ff7227e-dirty
[NOTE]-AGENT---: Thread version: 1.3.0
[NOTE]-AGENT---: Thread interface: wpan0
[NOTE]-AGENT---: Radio URL: spinel+hdlc+uart:///dev/ttyUSB0?uart-baudrate=460800&uart-flow-control
[NOTE]-AGENT---: Radio URL: trel://eth0
[NOTE]-ILS-----: Infra link selected: eth0
50d.08:29:29.202 [C] P-SpinelDrive-: Software reset co-processor successfully
00:00:00.045 [N] RoutingManager: BR ULA prefix: fde5:7041:2737::/48 (loaded)
00:00:00.045 [N] RoutingManager: Local on-link prefix: fd9a:ca06:c126:804::/64
00:00:00.059 [N] Mle-----------: Role disabled -> detached
00:00:00.064 [N] P-Netif-------: Changing interface state to up.
00:00:00.072 [W] P-Netif-------: Failed to process request#2: No such process
00:00:00.072 [W] P-Netif-------: Failed to process request#6: No such process
s6-rc: info: service otbr-agent successfully started
s6-rc: info: service otbr-agent-rest-discovery: starting
s6-rc: info: service otbr-agent-configure: starting
Done
s6-rc: info: service otbr-agent-configure successfully started
[10:09:37] INFO: Successfully sent discovery information to Home Assistant.
s6-rc: info: service otbr-agent-rest-discovery successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
Default: mDNSCoreReceiveResponse: Received from 192.168.178.109:5353   18 109.178.168.192.in-addr.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 109.178.168.192.in-addr.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from 192.168.178.109:5353   18 7.6.7.0.1.a.1.1.f.b.8.7.e.2.f.f.0.0.b.4.d.2.d.a.0.2.0.6.0.0.a.2.ip6.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 7.6.7.0.1.A.1.1.F.B.8.7.E.2.F.F.0.0.B.4.D.2.D.A.0.2.0.6.0.0.A.2.ip6.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from 172.30.32.1:5353   18 1.32.30.172.in-addr.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 1.32.30.172.in-addr.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from 172.30.32.1:5353   18 e.0.6.5.2.8.e.f.f.f.c.0.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 E.0.6.5.2.8.E.F.F.F.C.0.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from fe80::42:92ff:fe3b:da5f:5353   18 f.5.a.d.b.3.e.f.f.f.2.9.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 F.5.A.D.B.3.E.F.F.F.2.9.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from fe80::b8a4:7eff:fea6:2889:5353   18 9.8.8.2.6.a.e.f.f.f.e.7.4.a.8.b.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 9.8.8.2.6.A.E.F.F.F.E.7.4.A.8.B.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from fe80::7070:12ff:fea9:ba42:5353   18 2.4.a.b.9.a.e.f.f.f.2.1.0.7.0.7.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 2.4.A.B.9.A.E.F.F.F.2.1.0.7.0.7.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from fe80::f0a0:80ff:fe3b:679c:5353   18 c.9.7.6.b.3.e.f.f.f.0.8.0.a.0.f.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 C.9.7.6.B.3.E.F.F.F.0.8.0.A.0.F.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from fe80::9007:f5ff:fe3a:cf8d:5353   18 d.8.f.c.a.3.e.f.f.f.5.f.7.0.0.9.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 D.8.F.C.A.3.E.F.F.F.5.F.7.0.0.9.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from fe80::b477:91ff:fe34:36e:5353   18 e.6.3.0.4.3.e.f.f.f.1.9.7.7.4.b.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 E.6.3.0.4.3.E.F.F.F.1.9.7.7.4.B.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from fe80::8053:8bff:fe0f:704:5353   18 4.0.7.0.f.0.e.f.f.f.b.8.3.5.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 4.0.7.0.F.0.E.F.F.F.B.8.3.5.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from fe80::98ed:4eff:fec4:eeb7:5353   18 7.b.e.e.4.c.e.f.f.f.e.4.d.e.8.9.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 7.B.E.E.4.C.E.F.F.F.E.4.D.E.8.9.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from fe80::3472:92ff:fe89:37d1:5353   18 1.d.7.3.9.8.e.f.f.f.2.9.2.7.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 1.D.7.3.9.8.E.F.F.F.2.9.2.7.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from fe80::3461:a8ff:fe4b:32d:5353   18 d.2.3.0.b.4.e.f.f.f.8.a.1.6.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 D.2.3.0.B.4.E.F.F.F.8.A.1.6.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from fe80::b476:a7ff:feff:f39d:5353   18 d.9.3.f.f.f.e.f.f.f.7.a.6.7.4.b.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 D.9.3.F.F.F.E.F.F.F.7.A.6.7.4.B.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR RASPI-HA.local.
Default: mDNSCoreReceiveResponse: Received from 172.17.0.1:5353   18 1.0.17.172.in-addr.arpa. PTR RASPI-HA-2.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding   16 1.0.17.172.in-addr.arpa. PTR RASPI-HA.local.
00:00:27.026 [N] Mle-----------: RLOC16 b800 -> fffe
00:00:27.637 [N] Mle-----------: Attach attempt 1, AnyPartition reattaching with Active Dataset
00:00:34.137 [N] RouterTable---: Allocate router id 46
00:00:34.137 [N] Mle-----------: RLOC16 fffe -> b800
00:00:34.139 [N] Mle-----------: Role detached -> leader
00:00:34.140 [N] Mle-----------: Partition ID 0x823d949
[NOTE]-BBA-----: BackboneAgent: Backbone Router becomes Primary!
00:00:35.625 [W] DuaManager----: Failed to perform next registration: NotFound
00:18:38.942 [W] Nat64---------: incoming message is an IPv4 datagram but no NAT64 prefix configured, drop
00:18:48.966 [W] Nat64---------: incoming message is an IPv4 datagram but no NAT64 prefix configured, drop
00:49:09.417 [W] Nat64---------: incoming message is an IPv4 datagram but no NAT64 prefix configured, drop
00:49:19.431 [W] Nat64---------: incoming message is an IPv4 datagram but no NAT64 prefix configured, drop
01:19:40.056 [W] Nat64---------: incoming message is an IPv4 datagram but no NAT64 prefix configured, drop
01:19:50.068 [W] Nat64---------: incoming message is an IPv4 datagram but no NAT64 prefix configured, drop
01:50:10.720 [W] Nat64---------: incoming message is an IPv4 datagram but no NAT64 prefix configured, drop
01:50:20.734 [W] Nat64---------: incoming message is an IPv4 datagram but no NAT64 prefix configured, drop

SInce we are on IP addresses - pinging the local RPi5 address on the Pi itself connects to this weird IP4 :

PING raspi-ha.local (172.17.0.1) 56(84) bytes of data.

ON the Pi RASPI-HA is not resolved to 192.168.178.109 but to 172.17.0.1 instead…

8

The Thread credential issue has fixed itself. Apparently it takes Google a few hours to get synced after I deleted the Google Play Store stored data yesterday evening.

Attempting to add a new device still runs into time-out during the WiFi network check but at least doesn’t throw a Thread connection error anymore. So I guess that the problem lies somewhere on my Raspi system with Matter and Thread server not correctly communicating. No clue though where to look at. :innocent:

P.S.:

  1. The Raspi-HA-2 cannot be pinged anymore, it has disappeared from the system.
  2. Seeing this in the DNS log, referencing the ominous 172.30.32.1:
CoreDNS-1.8.7
linux/arm64, go1.22.2, a9adfd5-dirty
[INFO] 127.0.0.1:44194 - 20082 "HINFO IN 9012019513395874486.1317518116849365134. udp 68 true 2048" REFUSED qr,aa,rd 57 0.000995555s
[INFO] 127.0.0.1:54701 - 40951 "HINFO IN 9012019513395874486.1317518116849365134. udp 57 false 512" REFUSED qr,aa,rd 57 0.024114426s
[INFO] 172.30.32.1:51819 - 57439 "A IN raspi-ha.local.hass.io. udp 40 false 512" NXDOMAIN qr,aa,rd 40 0.001133065s
  1. nmcli output:
eth0: verbunden to Supervisor eth0
        "eth0"
        ethernet (macb), 2C:CF:67:34:81:07, hw, mtu 1500
        ip4-Vorgabe, ip6-Vorgabe
        inet4 192.168.178.109/24
        route4 192.168.178.0/24 metric 100
        route4 default via 192.168.178.1 metric 100
        inet6 2a00:6020:ad2d:4b00:ff2e:78bf:11a1:767/64
        inet6 fe80::da07:97a8:4279:1d0e/64
        route6 2a00:6020:ad2d:4b00::/64 metric 100
        route6 2a00:6020:ad2d:4b00::/56 via fe80::9a9b:cbff:febb:1eb9 metric 100
        route6 fe80::/64 metric 1024
        route6 default via fe80::9a9b:cbff:febb:1eb9 metric 100

lo: connected (externally) to lo
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
        inet4 127.0.0.1/8
        inet6 ::1/128

docker0: nicht verwaltet
        "docker0"
        bridge, 02:42:92:3B:DA:5F, sw, mtu 1500

hassio: nicht verwaltet
        "hassio"
        bridge, 02:42:0C:82:56:0E, sw, mtu 1500

veth0a0eccf: nicht verwaltet
        "veth0a0eccf"
        ethernet (veth), 9A:ED:4E:C4:EE:B7, sw, mtu 1500

veth13041ef: nicht verwaltet
        "veth13041ef"
        ethernet (veth), 92:07:F5:3A:CF:8D, sw, mtu 1500

veth1d56aa9: nicht verwaltet
        "veth1d56aa9"
        ethernet (veth), 36:72:92:89:37:D1, sw, mtu 1500

veth263f13e: nicht verwaltet
        "veth263f13e"
        ethernet (veth), B6:76:A7:FF:F3:9D, sw, mtu 1500

veth4c90eb0: nicht verwaltet
9

It seems there are two devices, RASPI-HA and RASPI-HA-2, with the same address?

10

No, that was temporary. See my PS above:

11

Hello,

if yo uwant to test that your HA installation is ok, please follow the guide here :
Add devices without a phone

I tried this feature recently and it work very well !

About the thread credentials, I managed to borrow an android from a friend , installing companion app and all, and it worked at first try !

I believe the reset of thread credentials is very very glitchy and once you poison your phone it’s very hard to change them…

12

It seems that the Bluetooth option has been removed in the current Matter (Beta) release. There is no way to define the Bluetooth adapter to be used by the Matter server. This option doesn’t exist:

In the Settings ->Add-ons → Matter Server → Configuration I then set the Bluetooth Adapter ID to 1:

The Matter documentation says

Although your Home Assistant server might have a Bluetooth adapter on board that the controller can use to commission devices, Home Assistant does not utilize that adapter. Mainly to prevent issues with the built-in Bluetooth integration but also because it is easier to bring your mobile devices close to the Matter device than bringing the device near your server.

Server access through the Web UI is also not there. I fully understand (and support) @agners approach to keep this process as simple as possible. Sadly I can’t overcome the “Checking network connectivity” hurdle.

13

We haven’t removed it, at least not consciously. It is still there for me :thinking: It is behind the “Show unused optional configuration options” switch…

What do you mean? In the add-on page, pressing “Open Web UI” opens the Matter Server Web UI for me :thinking: .

1 Like
14

Ah, there. I would have expected it to be accessed from the integration.

15

It is the Matter Server (add-on) which ultimately uses the Bluetooth adapter. And since we don’t advocate for this method currently (rather use the companion apps flow with the phones local Bluetooth), we didn’t really invest time in polishing this.

1 Like
16

I just tried again and it’s working on my setup !

I am using the bluetooth of the Rasb Pi 4

my versions are :

  • Core 2024.10.0
  • Supervisor 2024.09.1
  • Operating System 13.1
  • Interface utilisateur 20241002.2
17

Perfectly understood. Yet is probably the last resort for those whose network check is failing.

I was able to follow your instructions but now struggle with the Thread credentials. Which elements do I need to use from the Thread information panel to enter as Thread data set and Pairing ID?

ha-thread-12dc
Network name: ha-thread-12dc
Channel: 15
Dataset id: 01J94CK28HE8B0S6BR74RKSZ3N
Pan id: 12dc
Extended Pan id: 9aca06c1268c0804
OTBR URL: http://core-openthread-border-router:8081
Active dataset TLVs:
18

this one :

image
image1481×819 38.8 KB

19

Excuse-moi, je comprends vite, il faut juste m’expliquer longtemps :slight_smile:

Seriously, the dialogue is asking for two entries, the Thread ID and the pairing code. If I understand you correctly, the TLV is the pairing code. What is then the id, the Pan id?

20

please respond in english (yes i’m french too), but it’s more respectfull if everyone understand what we say … :slight_smile: no problem we are here to help.

no no you are 50% correct.

-Thread ID : “Active dataset TLVs” for example : 0e080000000000010000000300[…]etc

-Pairing code : the matter code on the device such as : XXXX-XXX-XXXX (associated with QR code )

Pairing code must be writen without the ‘-’

for example :

image
image1088×781 40.2 KB

1 Like
21

Thanks @Pierre84000 and @agners for your patience.

With your explanations I was able to connect the Siegenia window handle.There now is a new device “Smart window handle”. HA immediately proposed to update it from 1.0.0 to 1.0.1, which I just did. One has to rediscover it through “Interview”, but it works.

It does lock and unlock.