2 Google TBR and newly added nanoleaf TBR cause troubles on matter devices

Configuration Matter/Thread
,
1

I’m experiencing significant issues since adding a Nanoleaf Elements light to my Thread/Matter network and I can’t figure out why.

Here’s my setup:

  • Thread network: 2 Google Nest Hub Gen2 Thread Border Routers (TBRs), forming the backbone for 8 dormant devices.
  • Devices: 6 Eve MotionBlinds and 2 Nuki Ultra locks.
  • Integration:
    • Nuki Ultra: Used in HA as primary network member.
    • 6 Eve blinds: Using seamless multi-connection between Google Home and HA (Matter is running on HAOS VM in Proxmox).

For months, this setup was rock solid—everything was connected, responsive, and trouble-free.

The issue started after introducing a Nanoleaf Elements panel:
The Nanoleaf controller (Wi-Fi connected) sits physically between my two Google Nest Hubs and joins my existing Thread network automatically (as per Matter/Thread protocol—I can’t change this behavior).

Symptoms:

  • The entire network becomes unstable when the Nanoleaf is plugged in.
  • Extensive troubleshooting, restarts, and repairs haven’t helped.
  • If I unplug the Nanoleaf, stability returns; as soon as it’s back, instability and errors appear in the Matter server logs.

What’s strange:

  • The Google Home app still shows all 6 blinds as working, even with the Nanoleaf connected.
  • In HA, pings to “Unavailable” devices get a green response, but they stay unavailable.
  • Server logs fill with retransmission failures like:
    CASESession timed out while waiting for a response from peer <000000000000003E, 1>. Current state was 4
  • The Nuki locks work fine or rarely have issues—problems are mostly with the blinds, which are spread around the living room.

It feels like the network is trying to optimize routes via the Nanoleaf’s TBR, but something goes wrong there.

Has anyone seen something similar?
I’m running out of ideas for troubleshooting and would appreciate any advice or suggestions from the community!

[edit] By writing the message, I feel that I need to do more easy test.

Then I plug off the 2 Google Nest and keep nanoleaf up, all the devices are connected and usable in HA. Could be the multi-admin Matter capability give issue with nanoleaf ?

Keeping this for some hours to see.

2

I’m answering on my post to share my experience in the Thread/matter world.
Then you are aware that at that time of writing, there is an incompatibility between manufacturers and then potential big issues on your future mesh network.

I do some experiments and results are clear:

  • 1 nanoleaf TBR with my 8 devices with or without matter multi-admin is stable for days

  • 1 or 2 Google Nest TBR with my 8 devices with or without matter multi-admin is stable for days

  • 1 nanoleaf TBR + one Google Nest TBR without matter multi-admin in the same network with my 8 devices: in 10min, my 8 devices starting to disconnect. I also see 2 devices still being almost ok even after hours (Nuki) and for the 6 eve motionblinds, disconnection happen almost directly.

Re-pairing, stop/start etc. don’t change anything.

I look into HA Matter Server log and it’s clear demonstration of the interoperability issues between a Nanoleaf Elements TBR (firmware 12.2.0) and Google Nest Gen2 TBRs (firmware: 27.20250422.103.3600)

For instance, I activated the Google Nest TBRs, and 10min after deactivated them.
During this 10-minute period, I can observe:

  • Multiple retransmission failures (max retries reached)
  • Repeated CASE session timeouts
  • Loss of Thread device connectivity
  • Failed resubscription attempts

These errors immediately cease when I deactivate the Google TBRs, confirming the interoperability conflict between Nanoleaf and Google. The issue is 100% reproducible.

This sequence of logs perfectly demonstrates the multi-TBR interoperability problem.

It’s frustrating me that in 2025 where now Thread and Matter are well present on the market to not be able to have a stable mesh network between only 2 manufacturers/company where marketing claim another story.

3

Sharing the final post as a solution :slight_smile:

I contacted nanoleaf and google support and both recomment me to stop one of the device or stop one of the TBR which this option is not possible in their applications…
Nanoleaf propose me to leave the network and use the local Wifi AP to control the light.
Was not really an option for me.

After some hours of research, I finaly find a solution:
put firewall rules for the nanoleaf to perturb the Thread mesh functionnality and it works !

Put rules:
block all source UDP ports, reserved ip source of the nanoleaf to all traffic.
(port UDP 19788 is Thread MLE & UDP 61631 is CoAP Thread but was not enough)
To control the nanoleaf on HA, I need a rule to open only UDP 16021 port from reserved ip source of the nanoleaf to all traffic

This was still giving issues, then last rule solve all my issues:
block UDP/TCP port 5353 (mDNS) from reserved ip source of the nanoleaf to all traffic

This is now running fine since one hour :slight_smile:

2 Likes
4

Don’t know if the below is actually applicable in your case, but sharing the info …

5

Thank you to have share this. With all my tests and experience so far, I demonstrate what @marcelveldt answered.

Thread is real mess when you have more than one TBR manufacturer. The big problem is that you can’t stop or put off a TBR manually. As soon as the device is up, thanks to Thead, your mesh will be more robust … well not true today

See here Thread Group is finally fixing Thread border routers | The Verge

here is other good news from Thread Group, which announced a few more updates to the protocol for 2024 that are aimed at making Thread devices “more interoperable, reliable, and flexible.”

Well good news if it’s working but if not … you are in a troubles without any arms to stop it

Now to come back on my firewall rule test (IPV4), it was fully working during 6hours. Today morning, I was loosing 2 devices reported and unavailable.
If you do a power cycle, firewall rules doesn’t help as the network layer is working on IVP6. This have not help on solving issues…

As the matter server add-on seems to strictly following the correct matter/thread implementation, this is broken only with home assistant.
Between nanoleaf and google home, everything is functioning. May be badly but all are always available while in HA, devices are unavailable.

So my recommendation is to not buy any nanoleaf devices having TBR on it if you want to control them from HA. I think their firmware is not aligned with the latest Thread specifications but I didn’t get the information from the support.

Contacted google and nanoleaf support confirmed me after some exchanges that they don’t have any solution. As they know the issue, they should at least provide a way to stop the TBR.

And my final recommendation is to not buy from now any matter/Thread devices except if you are sure to work only with one TBR.

You also need to know network ivp6 and network in general as for instance, put enable IGMP on a switch can kill your matter experience.

1 Like
6

I recently upgraded my Synology router to the latest SRM 1.3 which is providing capability to create VLAN.

Then I created one VLAN with wifi as the only ressource.
Marked as isolated network.

I pair the nanoleaf with my phone connected on that specific VLAN.
When it was configured and working. I switched the phone to the main network and I was still able to access the light as the app reach the cloud.

I got one update from synology then device rebooted. I don’t know if it’s due to that or to the smartphone but somehow google and nanoleaf was seen the Thread network then start again having issues.

And strange thing happened on one of my Google Nest which is now completely dead. I tried a lot of reset procedure found on internet but still boot looping with G screen.

Putting the bricked device aside, I’m a bit afraid with those matter devices coming like the hue bridge pro. If companies don’t do effort to solve the multi TBR approach, this is going right to the wall if you think to use it with HA.