Matter-over-Thread: Low Limit on Number of Devices when using GL-S20 TBR?

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).1

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:

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. ↩︎

Rainwater Supply Interruption

The rainwater harvesting pump stopped working yesterday evening.

After a very dry spring and with a newly-planted hedge and a newly-seeded area of grass needing a significant amount of watering, the underground rainwater tank had emptied from a fully-filled 5,000 litres on 30th March to 1,300 litres on 26h April, with only 900 litres being replenished from rainfall around the middle of April.

After about 20 minutes of watering the grass seed using a hosepipe at around 8pm yesterday – while also running the ‘soaker’ hose along the hedge line – the water stopped flowing. First thought was that the pump had taken objection to running constantly for so long (though it had run for rather longer previously without any issues) but upon checking the pump controller its LEDs were all off; normally at least the green ‘Power’ LED is on.

Next thing to check was the circuit breaker (a dedicated 16A RCBO, supplying only the Rainwater Harvesting controls) – which had tripped. Upon resetting that it immediately tripped again. By that time it was getting late so further problem solving was left until the morning.

I’d made the decision to leave the supplied German plugs on all the RWH control units, connecting those to ‘Shucko’ socket inserts installed by the electricians, fed from the dedicated 16A RCBO via a 20A isolating switch. That made it easy to disconnect those plugs to try to isolate the issue (compared with if the plugs had been removed and the connections hard-wired). With all the plugs out there was no fault evident and the circuit breaker stayed ‘on’.

A quick check of the Pump cabling showed Live and Neutral had a suitably high resistance to Earth, though only about 5.5 Ohms between the two of them – which seemed a bit low, but not ridiculous for an electric motor. After reconnecting the Pump Controller and the Pump itself, the electrics were behaving fine but the pump wasn’t pumping. The red ‘Failure’ LED was lit on the Pump Controller, which is believed to be an indication the Pump had failed to supply pressure when powered up by the Controller. (I’ll come back to this later.)

There’s a second Schuko socket for the mains water top-up. That has a plug wired directly to the solenoid valve for the mains water supply which fits into a special intermediate adaptor plug which is wired to a float switch in the underground tank. The idea is that the valve stays unenergised (i.e. blocking the water flow) until the float switch closes (at low water level) – at which point the adaptor is made live and the valve opens. Plugging in the adaptor made the circuit breaker trip again. Checking the wiring inside the adaptor showed evidence of a short from Live to Earth, whenever the float switch was ‘closed’.

That explained the failure scenario:

  • With slightly more than the minimum level of water in the tank, everything was working normally
  • As water was used up, the tank level reached the minimum and the float switch switched – causing a short-circuit in the adaptor and tripping the breaker, thus removing power from the pump and stopping the water flow

The underlying issue turned out to be that the Adaptor has two sprung ‘clips’ which provide the Earth contact on the top and bottom of the inserted Plug. These clips move ‘outwards’ when the Plug is inserted and the lower one was very close to the wiring entering the Adaptor at the bottom. Evidently this clip placing pressure on a wire was enough (over time) to compromise the insulation and cause a short circuit. (It was the Blue wire which had failed. Normally that would be Neutral but here it’s acting as Switched Live.) The resolution was to leave none of the outer cable sheathing projecting beyond the cord grip, allowing the wires to be routed further away from the Earth clips, after the damaged wiring was cut off and re-terminated.

Wiring inside the RWH Float Switch Adaptor – after the earlier issue had been resolved

With the adaptor re-wired and re-fitted, the breaker stayed closed and the mains water top-up valve opened to add more water to the tank. I let it fill from 1,300 litres to 2,300 litres, which was enough to fully submerge the float switch (though that was still ‘closed’ – which is a separate problem).

I’m not entirely sure if the issue with the pump was caused by me removing it from the tank for inspection (letting air in and causing issues with it re-priming) or if it had separately had problems due to the low level of water in the tank. Even with an extra 1,000 litres of mains top-up it wasn’t managing to deliver any pressure when the Pump Controller powered it up. I could hear it trying to start pumping when the controller switched it on – I think it was spinning but ‘dry’ – but the overheat protection then kicked in (normally it gets cooled by water passing through its casing, past the motor windings). Tipping it over onto its side at the bottom of the tank let the air bubble out of the bottom, and it then started OK while still horizontal – and kept running when turned vertical again. I’m glad I left a ‘loop’ of pressure hose in the supply line to enable the pump to lie flat.

I’m still not sure what’s wrong with the float switch – which appears to be permanently ‘on’. Perhaps the switch contacts ‘welded’ closed due to the short circuit, before the breaker tripped (three times)? Wikipedia says the actual switching element is typically a regular microswitch, operated by a lever and a rolling steel ball (which you can hear). For now it’s easy enough to unplug the feed to the solenoid valve and keep an eye on the water level manually; maybe it will fix itself. There doesn’t appear to be any way to access the internals of the float switch without destroying its casing.

There’s finally been a bit of rain this afternoon. Only enough to add 400 litres to the tank – but at least the hedge and the grass seed don’t need watering today.

Update 2026-06-19

After allowing some time for the tank to re-fill from rainfall (to make it easier to re-prime the pump), a hot and sunny day seemed a good opportunity to get to the bottom of the float switch issue. I’d left the plug for the solenoid valve disconnected, but checking that periodically showed the switch was still ‘closed’ even with 4,000 litres in the tank.

Removing the pump from the tank made it possible to check the details of the float switch – shown in the photo below.

Markings on the original Float Switch supplied as part of the Mains Water Top-Up system

A bit of gentle shaking (moving the heavy ball inside the float) with the float still connected to its clamp around the pump had no effect – the switch was still permanently ‘closed’ – so I progressed to more vigorous shaking with the clamp removed from the pump. That did the trick, confirming my hypothesis that the switch contacts had ‘welded’ due to the brief short-circuit caused by the wiring fault.

The switch now seems to be working normally, and since it’s only handling a tiny load from the solenoid valve I’m relaxed about any long-term damage to the switch contacts.

Replacement float switches are available from Wisy and they’re a reasonable price. although buying one with 10m of cable adds significantly to the cost: https://wisy-water.com/en/float-switch-for-mains-water-top-up/