After successfully adding three IKEA TIMMERFLOTTE Temperature & Humidity sensors to the Matter-over-Thread network, which is connected to Home Assistant, I bought two further TIMMERFLOTTE sensors and one GRILLPLATS ‘smart plug’ (primarily for its power monitoring function, rather than the ability to control the outlet – and potentially also to act as a mains-powered ‘range extender’ for the Thread radio network).¹

For some reason, these new devices are all consistently failing to Commission as Matter devices in Home Assistant, despite using the exact same procedure as worked successfully for the older devices. There’s no problem with the first stage of commissioning (“Connecting”) but the second stage (“Setting Up”) always times out. Since the first three devices are still working perfectly, there can’t be any issues with the basic set-up of Thread or Matter.

There are some other reports of this same issue when using the GL.iNet GL-S20 Thread Border Router, on both the Home Assistant and GL.iNet community forums:

• Issue adding multiple thread devices using GL-S20 Thread border router which reports problems with more than 3 devices
• Issue adding more than 4 thread devices with GL-S20 TBR which reports problems with more than 4 devices
• GL-S20 OPENTHREAD: Failed to add service which has issues with more than 4 devices and references a “Failed to add service” error message in the GL-S20 log file (which I’m also seeing)
• Cannot add Matter over thread device due to “mdns: Cannot allocate memory” (TZ-1433) looks to be closely related and refers to increasing the compile-time setting for CONFIG_MDNS_MAX_SERVICES

None of those discussion threads has any definitive resolution identified (apart from perhaps the last one, which isn’t GL-S20-specific). Other Home Assistant users have much greater number of devices working successfully using different TBR solutions, so it looks like it might be an isolated issue with the GL-S20 firmware.

While there is no newer ‘Stable’ release of the GL-S20 firmware available (as of May 2026), I tried the latest ‘Beta’ (2.0.1-B1 dated 2025-07-02) but that didn’t improve matters. (This version enables the OTBR API integration with Home Assistant, but GL.iNet do not seem to publish Release Notes for firmware updates so it is not clear what other changes might be included.)

Interestingly, after only a few months (I bought mine in November 2025) the GL-S20 seems to be no longer available for purchase and there also doesn’t appear to be much recent activity from GL.iNet in releasing new firmware for it. In particular, there doesn’t seem to be much prospect of them providing support for Thread version 1.4, which was released a few months ago.

Under the covers the GL-S20 uses standard Espressif chips closely following the reference design (as documented here). GL.iNet provide some guidance on compiling a very slightly adapted version of the standard Espressif ‘example’ firmware here. GL.iNet have also released an SDK for a variant of this firmware here.

More interestingly, Edoardo Pinci has released the source code for a fork of the firmware for the GL-S20 on GitHub at https://github.com/EPinci/ep-s20-otbr which has been updated to support Thread 1.4 and provide better integration with Home Assistant (via the OTBR API). It also appears to disable the WiFi interface – which is fine, because that’s not required in my use case (and avoids the risk of interference with the Thread network which runs on the same 2.4GHz frequency). Running firmware for which the source code is readily available is very appealing, to help identify where error messages might be coming from and to address the limited logging available by default with the standard GL-S20 firmware. I have enough experience of cross-compiling software for embedded platforms for this not to be particularly scary prospect.

While doing some preparation for testing this alternative firmware, including checking for connectivity via the USB console (which happened to require the GL-S20 to be relocated into the House, near a Linux desktop machine) it became apparent that the ‘new’ Thread devices could all be Commissioned successfully (since with the GL-S20 in this temporary location, the existing TIMMERFLOTTE sensors were out-of-range). That confirms the issue is nothing to do with the device hardware and probably not directly an issue with Home Assistant but instead appears to be a limit on the number of ‘active’ Thread devices, imposed by the GL-S20.

With the three extra devices commissioned successfully, moving the GL-S20 back to its original location resulted in two of the ‘old’ devices coming back online, for a total of four – and a couple of SrpServer “Failed to add service” error messages in the GL-S20 log file.

My current hypothesis is there’s a hard-coded limit on the number of ‘services’ that can be managed using SRP, the Service Registration Protocol. SRP is used within the Thread network, by Thread devices which register with the SRP server hosted on the Thread Border Router (which then broadcasts those same registrations on the wired network using mDNS). While it’s no surprise that such a limit exists, it is a surprise that only a very few devices can be active concurrently.

In some ways I’d prefer to continue using the vendor-supplied firmware, since that works with their Smartphone App (to enable extraction of the Thread network credentials) and I presume it will be necessary to re-create the Thread network (using the same details?) when running alternative firmware – but if there is a hard-coded limit in the firmware (and no prospect of GL.iNet releasing new firmware to increase that) there don’t seem to be many other options for continuing to use the GL-S20 hardware.

So while I’m slightly disappointed GL.iNet are not doing more to actively support a device which is only a few months old, their decision to closely follow the Espressif reference design such that the standard Espressif firmware cross-compilation and firmware installation tools can be used means the hardware can fairly easily run non-GL.iNet firmware – which ensures the hardware will be usable for many years to come.

1. The Node Roles and Types page in the OpenThread documentation explains the different types and sub-types of Thread nodes. The TIMMERFLOTTE devices are battery-powered and show up in Home Assistant as Thread device type “Sleepy end device” (which is a sub-type of “Minimal End Device”) – so these are definitely not able to act as a ‘Range Extender’ for the Thread wireless network. The GRILLPLATS devices are mains-powered and so more likely to be candidates for acting as a ‘Range Extender’. Home Assistant initially showed these as Thread device type “End device” without clarifying if this was a Full Thread Device or a Minimal Thread Device. The former would leave open the possibility of being a “Router Eligible End Device” (REED) which could be promoted to being a Router within the Thread wireless network (as distinct from a Thread Border Router). Some lists of Matter devices indicate these are FTDs which will act as Routers. Upon later inspection, the GRILLPLATS changed to showing as a “Routing end device” within Home Assistant which confirms it is routing. It’s not clear if this was in response to the placement of other devices nearby which wanted to use it as a router; the OpenThread documentation says that if there are fewer than 16 Routers in a Thread network, any REED joining the network will automatically become a Router. ↩︎