GL-S200 thread commissioning

IoT
1

Hello everyone

With the arrival of matter and thread I want to turn the house into a smart house. For this purpose I purchased for now one GL-S200 in order to test matter and thread together with home assistant. I also have an Eve Energy smart plug, which uses matter and thread.

I successfully set everything up, but the device commissioning step is so far failing. Commissioning via home assistant seems to fail quite late, but fails after a couple of steps which are outlined here:

  • I use the “add matter device” function in home assistant and scan the QR code on my phone (which runs the home assistant companion app)
  • I get the “Searching for device…” screen
  • I get the “Connecting to device…” screen
  • I get the “Generating Matter credentials…” screen
  • I get the “Checking network connectivity…” screen
  • and then it fails after 2 or 3 minutes with the error “Can’t reach device”

I guess this can be a home assistant issue or maybe a timeout issue of the eve plug, but it could also be related to the GL-S200 thread border router, so I tried to do the thread commissioning using the GL-S200, which unfortunately also fails. This is the main reason for me to write here.

The attempt I made to commission the eve plug is to do the following:

  • go to “Thread Commissioning”
  • click “Add”
    • add * for the Joiner EUI-64 (since I don’t know the eve plug’s EUI-64)
    • add the 11-digit code I read under the matter QR-code of the eve plug for the Joiner Credential
  • click “Apply”

After this unfortunately nothing happens and the eve plug is not added to the thread network.

So, the question is, how would I manage to achieve to add this device?

I would greatly appreciate any help.

PS: I found this, where people seem to have the same issue, just with other devices, on home assistant. Still, I believe it should still be possible to do the commissioning with the GL-S200 web interface.

2

Hi @t1nux
I have verified that HA(v2023.8.4) currently only supports Apple homepod/homepodmini as Border Router. We are contacting HA developers to see how to solve this problem.
The root cause is the lack of a configurable APP to set the Thread credentials obtained from the S200 to the iOS system. Then the Thread credentials can be shared with other apps/vendors via the iOS API.
The Thread commissioning feature on S200 is only available for pure Thread applications, not Matter.

1 Like
3

Hello @lancer
Thank you for your quick reply and clarifications. Apparently, I did not read about the topic well enough before diving in.

But just to be clear, I neither have or want an Apple homepod (or Amazon echo, or Google nesthub), and I would like to use matter/thread devices using home assistant exclusively :smile:. I guess I am a bit early for this to happen smoothly and hassle free, but I also do not mind to get things to work on a lower level, eg. using cli-based methods, instead of a polish UI.

In any case, I just bought those two devices to get my feet wet on the topic, so that at a later stage, when I replace all light switches, blind switches, heating thermostats, etc. in the whole house with matter/thread devices, things already run (more or less) smoothly.

So, if I can be of help to beta-test any efforts in this direction, I am very willing to help.

Do you think I should additionally write something in the HA forum? I am honestly not sure how to address this, and if there even is a solution that can be implemented on either side alone (NA or S200).

4

Hi @t1nux ,
There is currently a demo for Android systems. You need to configure Thread network information manually. You can try it. Release v2.2.0 · nrfconnect/sdk-connectedhomeip · GitHub

5

Hi @t1nux ,
HA team said that the iOS companion app doesn’t support Thread credentials synchronization yet. That feature is already in the plan, but it’s a couple of weeks out still.
The Android App can synchronize Thread credentials already. There is also an explicit synchronization in Settings → Companion app → Troubleshooting → Sync Thread credentials.

6

Hi @lancer
I will try the sync thread credentials in the companion app later today. Thanks.

I also tried the android app you posted earlier, but it did not work, or at least I did not manage to get it to work.

I will try a bit more tonight and report back.

7

Just a quick update.

chip tool on android

I tried the tool, but it did not allow to add the eve smart plug.

scan qr code in the app

Interestingly, the scan qr code feature gives me another “setup PIN code” when I scan the matter qr code. I used that different pin code in the GL-S200 commissioning web interface, hoping that this code might work to register the device in the GL-S200 thread network. Unfortunately, it did not work.

provision chip device with thread

Using this option, I can enter the thread network information (PAN ID, ext. PAN ID, channel and network key). I hoped that entering these pieces of information from the GL-S200 thread network would join the device, but it did not. The app tells me that it is connecting to the correct device, and recognizes it, but pairing fails.

syncing thread credentials on the HA companion app

Thanks for this suggestion. Unfortunately, it did not change anything. The procedure is exactly like initially described.

1 Like
8

Hello.

The situation has so far not changed. I regularly keep updating home assistant (currently on 2023.10.5) but as of now without success.

@lancer, do you have an idea what the actual problem is?

9

Hi @t1nux
The iOS companion App needs to store the Thread credentials in the system. We are consulting on the development progress of the HA companion App and will notify you when there is any news.

10

Hello @lancer

Thanks for your quick answer.

I am in fact using the android app, not the iOS app of HA. So, the Eve Thread device is actually not part of any Thread network.

My aim is to either have the Eve device join the Thread network via the S200 interface, or via the HA companion app. As outlined above, both approaches do not seem to work, so at the moment I am stuck.

11

Hello @lancer

I am still facing the same issue as I have since last August, and I would really appreciate help with this.

I have raised the issue also on home assistant, and the consensus was that the thread network cannot be reached.

Here a short summary of what the state is:

  • I am trying to add a matter-over-thread device to home assistant.
  • I have successfully created a thread network on the S200, and imported the TLV data into home assistant and the mobile app.
  • I set the backbone interface of the backbone router to eth0, and the S200 is connected to the backbone router with the WAN port.
  • I start the commissioning using the QR code.
  • I get “Searching for device…”
  • I get “Connecting to device…”
  • I get “Generating Matter credentials…”
  • I get “Checking network connectivity…”, where it finally fails with “Can’t reach device”.

According to some very nice people on the Home Assistant discord server, this seems to be a connection issue to the thread network.
I looked into this, and according to this I should be able to ping the OMR address of the S200, which I can’t. My network and the hosts fulfill all the conditions mentioned in that article though.

If you need more information, please let me know. I have ssh access to the S200 and can give you details.

Thanks in advance, tinux

12

Hi @t1nux ,
I am glad that in the latest version of the HA Companion APP on the Android system, has an integrated ability to add the device of Matter over Thread.
The S200 TBR and mobile phone need to be connected to the same main router as follows.

ee44bdf395df6ff850d5b116419f85e7
ee44bdf395df6ff850d5b116419f85e71170×2343 210 KB

In the testing, although I could ping the OMR address of the S200 and the Matter device from the mobile phone, the HA Companion App could not add the Matter device in the end. I tried using a Raspberry Pi as a TBR and had the same problem. It seems that HA does not fully support the third-party Thread Border Router.

13

Hi @lancer

Thank you for your quick answer.

In all my testing, I tried so many things, and I must have gotten some things confused. In fact, I can ping the OMR address of the S200 from within the network. Sorry for the false information. My network is as shown in the image you posted.

I am too getting the feeling that the issue lies on the HA side. I will try to investigate more on that side.

Thanks again for your help!

PS: Which app is it that you are using for pinging (your screenshot)?

14

The name of the APP is as shown below. It can support IPv6 connectivity testing.

1a917641f0c73f32c0a1c5f2def0d560
1a917641f0c73f32c0a1c5f2def0d560457×1280 81.8 KB

15

Hi @t1nux
GL-S200 can already be used with Home Assistant. You can refer to the documentation to try it.

16

Hi @lancer

I apologize for the long reply.

Thank you for posting the Home Assistant HowTo. Unfortunately, the howto does not work for me exactly, but I am pretty sure that this is not related to the S200.

I also started a thread over at the home-assistant forum (here is the solution), and I got my setup to work (very similar to the howto you linked), BUT, in my case, I had to disable the ISP-provided native IPv6 on my router. Once I did that, things worked smoothly, similar to your howto.

Do you have any idea how to test what is failing or what I can do to fix the issue when IPv6 is on? AFAIK, thread uses IPv6, so having to disable IPv6 seems totally counterintuitive to me.
I have no issues (other than this) with IPv6, and I use it quite a bit, so I cannot simply disable it (except for testing).

Any thoughts would be very helpful.

Cheers, t1nux

17

I just wanted to double check everything from scratch, so I did a complete reinstallation of everything. For this, I disabled IPv6 on my main Asus DSL modem/router (Asus DSL-AX82U as main AiMesh router and 5 additional RT-AC68U as AiMesh nodes). Like this, I set up Home Assistant with the S200 as Thread Border Router without problems and everything is working. I tested this with an Eve Energy (switching, and power readings work in HA).

Now, as soon as I enable native IPv6 on the DSL-AX82U, Home Assistant is not able to reach the Eve Energy anymore. But of course, it is still connected to the S200, as can be seen here:
image.
Also, here are the device details, but I cannot ping the IPv6 addresses anymore:

image
image1125×716 155 KB

This sounds super weird to me, as I can ping (and operate through HA) this device via IPv6 when IPv6 is disabled on the main Asus router.

Maybe you have a clue what I can do. At this point, I do not know anymore what to test.

Best wishes, t1nux

18

IPv6 does not really care if it's disabled on the router. Disable means only that the IPv6 WAN isn't reachable.

19

That indeed makes sense. I still do not understand why I can IPv6-ping the thread device (Eve Energy) when the main router's IPv6 is disabled, and I cannot ping it anymore when IPv6 is enabled.

20

I got a bit further now... I can get thread working in a reproducible (yet annoying) but not reliable way. I would like to ask for some help, as I don't know how to tackle this.

my normal IPv6 operation

If I use my normal IPv6-enabled configuration on my main router (native IPv6) and I reboot the S200 and continuously ping a thread device during the reboot, I get a few successful pings just when the S200 reboot has completed. This successful state lasts for a few seconds only though, and then it does not work anymore.
In this state, I ssh-ed into the S200 and looked at the output of a few commands to check.

root@GL-S200:~# ip route
default via 10.0.0.1 dev eth0 proto static src 10.0.0.79 metric 10
10.0.0.0/24 dev eth0 proto static scope link metric 10
192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1
192.168.9.0/24 dev br-guest proto kernel scope link src 192.168.9.1 linkdown
192.168.255.0/24 dev wpan0 metric 100

root@GL-S200:~# ip -6 route
2001:9e8:d7fd:9200::/64 dev eth0 proto static metric 256 pref medium
unreachable 2001:9e8:d7fd:9200::/64 dev lo proto static metric 2147483647 pref medium
fd47:b9f5:218c:b1ae::/64 dev eth0 proto static metric 256 pref medium
unreachable fd47:b9f5:218c:b1ae::/64 dev lo proto static metric 2147483647 pref medium
fd52:206a:9b8b:10::/64 dev br-lan proto static metric 1024 pref medium
unreachable fd52:206a:9b8b::/48 dev lo proto static metric 2147483647 pref medium
fdb6:8ad6:7399:26d7::/64 dev wpan0 proto kernel metric 256 pref medium
fdc1:8e0a:d4f4:1::/64 dev wpan0 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev wpan0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::ca7f:54ff:fe20:8f18 dev eth0 proto static metric 512 pref medium
default via fe80::ca7f:54ff:fe20:8f18 dev eth0 proto ra metric 1024 expires 595sec mtu 1484 hoplimit 64 pref medium

root@GL-S200:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
    link/ether 94:83:c4:2f:8a:ff brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 94:83:c4:2f:8a:fe brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.79/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fd47:b9f5:218c:b1ae:9683:c4ff:fe2f:8afe/64 scope global deprecated dynamic noprefixroute
       valid_lft 1644sec preferred_lft 0sec
    inet6 2001:9e8:d7fd:9200:9683:c4ff:fe2f:8afe/64 scope global dynamic noprefixroute
       valid_lft 593sec preferred_lft 593sec
    inet6 fe80::9683:c4ff:fe2f:8afe/64 scope link
       valid_lft forever preferred_lft forever
5: br-guest: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 42:f0:58:3c:e5:25 brd ff:ff:ff:ff:ff:ff
    inet 192.168.9.1/24 brd 192.168.9.255 scope global br-guest
       valid_lft forever preferred_lft forever
6: wpan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none
    inet6 fdb6:8ad6:7399:26d7:0:ff:fe00:fc11/64 scope global nodad deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fdc1:8e0a:d4f4:1:f549:983f:9bfd:17c1/64 scope global nodad
       valid_lft forever preferred_lft forever
    inet6 fdb6:8ad6:7399:26d7:0:ff:fe00:fc38/64 scope global nodad deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fdb6:8ad6:7399:26d7:0:ff:fe00:fc10/64 scope global nodad deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fdb6:8ad6:7399:26d7:0:ff:fe00:5c00/64 scope global nodad deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fdb6:8ad6:7399:26d7:e723:6e43:d596:6906/64 scope global nodad deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fe80::64ed:d924:d0ec:f112/64 scope link nodad
       valid_lft forever preferred_lft forever
7: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 94:83:c4:2f:8a:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.1/24 brd 192.168.8.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fd52:206a:9b8b:10::1/60 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::9683:c4ff:fe2f:8aff/64 scope link
       valid_lft forever preferred_lft forever

thread (kind of) working

The way I got thread working for longer periods is like this: I leave the S200 running after the reboot I described in the section above (so, no rebooting), and set my main router's IPv6 settings from stateless to stateful (nothing else). After that it typically takes about 30 seconds and thread works fine, and also for a longer period (several hours). However, if I reboot the S200 with the stateful IPv6 setting on the main router, things do not work anymore though.
In this state, the same commands as above with ssh into the S200 give me this:

root@GL-S200:~# ip route
default via 10.0.0.1 dev eth0 proto static src 10.0.0.79 metric 10
10.0.0.0/24 dev eth0 proto static scope link metric 10
192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1
192.168.9.0/24 dev br-guest proto kernel scope link src 192.168.9.1 linkdown
192.168.255.0/24 dev wpan0 metric 100

root@GL-S200:~# ip -6 route
2001:9e8:d7fd:9200::/64 dev eth0 proto static metric 256 pref medium
unreachable 2001:9e8:d7fd:9200::/64 dev lo proto static metric 2147483647 pref medium
2001:9e8:d7fd:9900::/64 dev eth0 proto static metric 256 pref medium
fd47:b9f5:218c:b1ae::/64 dev eth0 proto static metric 256 pref medium
unreachable fd47:b9f5:218c:b1ae::/64 dev lo proto static metric 2147483647 pref medium
fd52:206a:9b8b:10::/64 dev br-lan proto static metric 1024 pref medium
unreachable fd52:206a:9b8b::/48 dev lo proto static metric 2147483647 pref medium
fdb6:8ad6:7399:26d7::/64 dev wpan0 proto kernel metric 256 pref medium
fdc1:8e0a:d4f4:1::/64 dev wpan0 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev wpan0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::ca7f:54ff:fe20:8f18 dev eth0 proto ra metric 1024 expires 592sec hoplimit 64 pref medium

root@GL-S200:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
    link/ether 94:83:c4:2f:8a:ff brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 94:83:c4:2f:8a:fe brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.79/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fd47:b9f5:218c:b1ae:9683:c4ff:fe2f:8afe/64 scope global deprecated dynamic noprefixroute
       valid_lft 1522sec preferred_lft 0sec
    inet6 2001:9e8:d7fd:9200:9683:c4ff:fe2f:8afe/64 scope global dynamic noprefixroute
       valid_lft 516sec preferred_lft 516sec
    inet6 fe80::9683:c4ff:fe2f:8afe/64 scope link
       valid_lft forever preferred_lft forever
5: br-guest: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 42:f0:58:3c:e5:25 brd ff:ff:ff:ff:ff:ff
    inet 192.168.9.1/24 brd 192.168.9.255 scope global br-guest
       valid_lft forever preferred_lft forever
6: wpan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none
    inet6 fdb6:8ad6:7399:26d7:0:ff:fe00:fc11/64 scope global nodad deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fdc1:8e0a:d4f4:1:f549:983f:9bfd:17c1/64 scope global nodad
       valid_lft forever preferred_lft forever
    inet6 fdb6:8ad6:7399:26d7:0:ff:fe00:fc38/64 scope global nodad deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fdb6:8ad6:7399:26d7:0:ff:fe00:fc10/64 scope global nodad deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fdb6:8ad6:7399:26d7:0:ff:fe00:5c00/64 scope global nodad deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fdb6:8ad6:7399:26d7:e723:6e43:d596:6906/64 scope global nodad deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fe80::64ed:d924:d0ec:f112/64 scope link nodad
       valid_lft forever preferred_lft forever
7: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 94:83:c4:2f:8a:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.1/24 brd 192.168.8.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fd52:206a:9b8b:10::1/60 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::9683:c4ff:fe2f:8aff/64 scope link
       valid_lft forever preferred_lft forever

Could it be that the MTU setting is causing this? If so, how should I set MTU for this to work? As I am using a DSL connection, I cannot put this to 1500.