And they are functional.
However I cannot add IKEA Grillplats and/or Onvis S4 plugs.
In both cases the connection fails at very last stage: “Connection to the Thread Network” (or so, forgot waht was the exact message).
IPV6 forwarding is enabled.
Searching Google did not produce anything.
I am lost.
What I am doing wrong?
Which Phone are you using to add them (Android/Iphone)? So, if you already managed to connect 2 devices in the same way, your general configuration should be okay. Sometimes a simple Reboot of the phone itself can help.
Thread credentials have been synchronized in the companion app, right?
Android, Galaxy S23, phone was reboot few times. Originaly thread credentials was synchronized but only once. Do I have to resynchronize tham again? OK, I will try this and see what happens.
EDIT
Tryed to resync thread credentials. Still the same problem. It goes to “Checking connectivity to Thread network ha-thread-113a”, stays here for a very long time and finally fails.
The error is more symptomatic of the HAOS 17.2 release that disabled IPv6 forwarding, so double-check that it still is enabled. You can use the command ha docker options --enable-ipv6=true to reenable it, and restart HAOS to get it to take.
Yes it is enabled, but there is a difference between “enabled” and “forwarding”. “Forwarding” is what allows the system to forward IPv6 packets from your LAN to your Thread mesh network (and also in the other direction).
I don’t know if this will work with your SSH App/AddOn, but type the following: cat /proc/sys/net/ipv6/conf/end0/forwarding
If it shows 0, then forwarding is disabled.
First device is just an added new.
Now to my eyes it looks like something is not right with HA Thread.
I cannot imagine two plugs (Grillplats and Onvis S4) from different vendors are problematic. It looks like the HA has a problem.
As I suspected, the SSH AddOn/App doesn’t have access to that directory.
I actually don’t think there is a user friendly way to determine this. Anyway, it won’t hurt to try the ha docker options --enable-ipv6=true command, and reboot the system to see if it helps.
Yes, I already tried this command. It did not change anything.
Did you see my edited comment?
I have no problem to add MS605 sensors. It takes less than a min. No problems.
But two different plugs (Grillplats and Onvis) are failing exactly the same way. It is hard to believe both plugs are problematic. So, I suspect a HA Thread is a problem (whatever it is).
And BTW, there is no problem to add all these devices (MS605, Grillplats and Onvis S4) to the Alexa Echo4. But I don’t want Alexa to be involved …
Yes I did see the comment, and TBH, its very rather bizarre. The only thing that comes to mine, is that I have seen in old versions of iOS, that a “race” condition caused by the iOS made commissioning more likely to fail than to succeed. But its probably not the case here. I really don’t know how to solve this for you. Once Thread commissioning to HA works for one device, it should work for others.
2.4Ghz or 5Ghz is not important if it is still the same IP network behind.
And wmaker catched the reason for asking with the OTBR.
Regarding Onvis, then it is important to update them and it can be a bit tricky.
If you have an Apple Matter Hub, then it might be easier to do it that way and once they are updated, then factory reset them and join the HA network.
The first few iterations of the Onvis firmware was a bit bugged.
And with Grillplats make sure you do not get them reset to switch to Zigbee, which can occur, because the process is somewhat similar to the one used for factory reset.
When syncing Thread credentials on Android do it twice in a row.
The first one should say something along the line : “Home Assistant and the phone is now using the same credentials”.
The second one (or maybe the first one, if an earlier sync is still active) should say something along the line ; “Home Assistant and the phone is already using the same credentials”.
If the second message is not coming up, then your phone is bugged and you need to search for Google Play Cache in the phone settings and clear that. Beware It might clear other settings in the phone too!
Since I could not add a Grillplats and/or Onvis plugs but I need at least one Thread Repeater/Router I built DIY one based on XAIO ESP32C6 baord. Everything so far looks good but how i can be sure it is functional and doing its job?
Just in case here is a log from the device:
INFO ESPHome 2026.4.2
INFO Reading configuration /config/esphome/thread-router-01.yaml...
WARNING GPIO15 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq/#why-am-i-getting-a-warning-about-strapping-pins
INFO Starting log output from fdd9:3af5:524f:1:f255:d7b1:a489:1f97 using esphome API
INFO Successfully resolved xiao-thread-repeater @ fdd9:3af5:524f:1:f255:d7b1:a489:1f97 in 0.000s
INFO Successfully connected to xiao-thread-repeater @ fdd9:3af5:524f:1:f255:d7b1:a489:1f97 in 0.023s
INFO Successful handshake with xiao-thread-repeater @ fdd9:3af5:524f:1:f255:d7b1:a489:1f97 in 0.041s
[13:24:52.610][I][app:154]: ESPHome version 2026.4.2 compiled on 2026-04-24 12:33:59 -0400
[13:24:52.633][I][app:161]: ESP32 Chip: ESP32-C6 rev0.2, 1 core(s)
[13:24:52.633][C][logger:219]: Logger:
[13:24:52.633][C][logger:219]: Max Level: DEBUG
[13:24:52.633][C][logger:219]: Initial Level: DEBUG
[13:24:52.633][C][logger:226]: Log Baud Rate: 115200
[13:24:52.633][C][logger:226]: Hardware UART: USB_SERIAL_JTAG
[13:24:52.666][C][logger:235]: Task Log Buffer Size: 768 bytes
[13:24:52.699][C][gpio.output:010]: Binary Output:
[13:24:52.699][C][gpio.output:152]: Pin: GPIO3
[13:24:52.699][C][gpio.output:010]: Binary Output:
[13:24:52.699][C][gpio.output:152]: Pin: GPIO14
[13:24:52.726][C][status_led:063]: Status Led Light:
[13:24:52.727][C][status_led:152]: Pin: GPIO15
[13:24:52.727][C][light:093]: Light 'Thread Router Status'
[13:24:52.727][C][openthread:029]: Open Thread:
[13:24:52.761][C][openthread:031]: Device Type: FTD
[13:24:52.761][C][openthread:044]: Output power: 20dBm
[13:24:52.761][C][esphome.ota:071]: Over-The-Air updates:
[13:24:52.761][C][esphome.ota:071]: Address: xiao-thread-repeater.local:3232
[13:24:52.761][C][esphome.ota:071]: Version: 2
[13:24:52.762][C][safe_mode:026]: Safe Mode:
[13:24:52.762][C][safe_mode:026]: Successful after: 60s
[13:24:52.762][C][safe_mode:026]: Invoke after: 10 attempts
[13:24:52.762][C][safe_mode:026]: Duration: 300s
[13:24:52.794][C][safe_mode:043]: Bootloader rollback: support unknown
[13:24:52.795][C][api:235]: Server:
[13:24:52.795][C][api:235]: Address: xiao-thread-repeater.local:6053
[13:24:52.795][C][api:235]: Listen backlog: 4
[13:24:52.795][C][api:235]: Max connections: 8
[13:24:52.795][C][api:247]: Noise encryption: NO
[13:24:52.795][C][mdns:194]: mDNS:
[13:24:52.795][C][mdns:194]: Hostname: xiao-thread-repeater
[13:25:06.321][D][api:220]: Accept FDD9:3AF5:524F:1:EA08:830C:E55:440B
[13:25:06.355][D][api.connection:2409]: Home Assistant 2026.4.3 (FDD9:3AF5:524F:1:EA08:830C:E55:440B): connected
[13:25:36.311][I][safe_mode:091]: Boot seems successful; resetting boot loop counter
[13:25:40.636][D][preferences:136]: Writing 1 items: 0 cached, 1 written, 0 failed
INFO Processing unexpected disconnect from ESPHome API for xiao-thread-repeater @ fdd9:3af5:524f:1:f255:d7b1:a489:1f97
WARNING Disconnected from API
INFO Successfully resolved xiao-thread-repeater @ fdd9:3af5:524f:1:f255:d7b1:a489:1f97 in 0.000s
INFO Successfully resolved xiao-thread-repeater @ fdd9:3af5:524f:1:f255:d7b1:a489:1f97 in 0.000s
INFO Successfully connected to xiao-thread-repeater @ fdd9:3af5:524f:1:f255:d7b1:a489:1f97 in 0.033s
INFO Successful handshake with xiao-thread-repeater @ fdd9:3af5:524f:1:f255:d7b1:a489:1f97 in 0.044s
I was going to say that it looked fine based on HA being able to connect to it, but looks like the connection dropped, so not sure. Does HA see it as still being available? If yes, then keep monitoring whether HA takes it to the unavailable state (or not).
After fresh power cycle the log does not say it is connected.
So, something must be wrong but I have no idead where to look.
Just in case here is a fresh log:
INFO ESPHome 2026.4.2
INFO Reading configuration /config/esphome/thread-router-01.yaml...
WARNING GPIO15 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq/#why-am-i-getting-a-warning-about-strapping-pins
INFO Starting log output from fdd9:3af5:524f:1:f255:d7b1:a489:1f97 using esphome API
INFO Successfully resolved xiao-thread-repeater @ fdd9:3af5:524f:1:f255:d7b1:a489:1f97 in 0.000s
INFO Successfully connected to xiao-thread-repeater @ fdd9:3af5:524f:1:f255:d7b1:a489:1f97 in 0.022s
INFO Successful handshake with xiao-thread-repeater @ fdd9:3af5:524f:1:f255:d7b1:a489:1f97 in 0.040s
[17:21:41.493][I][app:154]: ESPHome version 2026.4.2 compiled on 2026-04-24 12:33:59 -0400
[17:21:41.518][I][app:161]: ESP32 Chip: ESP32-C6 rev0.2, 1 core(s)
[17:21:41.518][C][logger:219]: Logger:
[17:21:41.518][C][logger:219]: Max Level: DEBUG
[17:21:41.518][C][logger:219]: Initial Level: DEBUG
[17:21:41.518][C][logger:226]: Log Baud Rate: 115200
[17:21:41.518][C][logger:226]: Hardware UART: USB_SERIAL_JTAG
[17:21:41.542][C][logger:235]: Task Log Buffer Size: 768 bytes
[17:21:41.589][C][gpio.output:010]: Binary Output:
[17:21:41.589][C][gpio.output:152]: Pin: GPIO3
[17:21:41.590][C][gpio.output:010]: Binary Output:
[17:21:41.590][C][gpio.output:152]: Pin: GPIO14
[17:21:41.612][C][status_led:063]: Status Led Light:
[17:21:41.612][C][status_led:152]: Pin: GPIO15
[17:21:41.612][C][light:093]: Light 'Thread Router Status'
[17:21:41.612][C][openthread:029]: Open Thread:
[17:21:41.648][C][openthread:031]: Device Type: FTD
[17:21:41.648][C][openthread:044]: Output power: 20dBm
[17:21:41.648][C][esphome.ota:071]: Over-The-Air updates:
[17:21:41.648][C][esphome.ota:071]: Address: xiao-thread-repeater.local:3232
[17:21:41.648][C][esphome.ota:071]: Version: 2
[17:21:41.648][C][safe_mode:026]: Safe Mode:
[17:21:41.648][C][safe_mode:026]: Successful after: 60s
[17:21:41.648][C][safe_mode:026]: Invoke after: 10 attempts
[17:21:41.648][C][safe_mode:026]: Duration: 300s
[17:21:41.676][C][safe_mode:043]: Bootloader rollback: support unknown
[17:21:41.676][C][api:235]: Server:
[17:21:41.676][C][api:235]: Address: xiao-thread-repeater.local:6053
[17:21:41.676][C][api:235]: Listen backlog: 4
[17:21:41.676][C][api:235]: Max connections: 8
[17:21:41.676][C][api:247]: Noise encryption: NO
[17:21:41.676][C][mdns:194]: mDNS:
[17:21:41.676][C][mdns:194]: Hostname: xiao-thread-repeater
[17:22:25.467][I][safe_mode:091]: Boot seems successful; resetting boot loop counter
[17:22:27.375][D][preferences:136]: Writing 1 items: 0 cached, 1 written, 0 failed
That is about it. I don’t see any evidence anywhere that this device is actually doing its job.
