Cyclical drop off of matter-over-thread devices using recommended method

[merry gazelle]

I have a single OTBR (a ZBT-1) attached to HAOS on a RPi5 based on advice I received on Github. I have over 48 wired router-capable lights through out my house (literally every light) that are spaced at most 4 feet from each other. Yet the response times are laggy if the lights are available at all and most of the time they are not. I've read this comment and this one and followed this thread on Github, but I am using the recommended approach it is still not working. Is this a manufacturer issue? All the lights are Nanoleaf essential downlights. Is this an issue that is part of the "wait for thread to deliver" problem? I've attached a graph of what I'm talking about regarding unavailable lights. Honestly its magical when it works but that is once is a blue moon.

[vale folio]

which firmware version are you nanoleaf devices on? have you updated them to 4.1.0/4.1.3? (If not, i don't recommend doing so)

[merry gazelle]

they are all at least on 4.1.0 but some aren’t updating to the .3 patch

[vale folio]

that's expected; nanoleaf is blocking updates from 4.1.0 to 4.1.3 for unexplained reasons.

the 4.x.x firmware releases were pushed out to add support for the new sense+ switch, but there have been a few people reporting that they are having more thread network issues with that firmware on the nanoleaf discord.

(which kind of makes sense - the new firmware runs the 802.15.4 radio with multiple protocols so it can talk over thread and to the remotes directly with a proprietary protocol...)

[worn fiber]

@merry gazelle , are you able to share any of the OpenThread logs from the OTBR instance?

[vale folio]

I think you meant to ask @merry gazelle? But yeah, OTBR or Matter Server add-on logs would be good places to start looking.

[worn fiber]

Oh yes, sorry, read too quickly.

[merry gazelle]

@worn fiber I'll grab logs next time there is a major outage

[merry gazelle]

@worn fiber I've attached the logs from both the matter and OTBR add-ons

[merry gazelle]

bumping this if anyone has any ideas. I've recently tried moving zigbee to channel 20 and thread to channel 25 which seems to help a bit, but still getting random spikes. I also had all my iot devices on 2.4ghz but started broadcasting 5ghz on the iot network to try and reduce traffic. when I first switched the channel and restricted my wifi to channel 1 I got pretty good stable results (with some random dropoff). as of recent, I'm back to huge spikes. one thing I found weird was that in a github issue, Marcel recommended having 1 thread border router instead of multiple (originally I had everything on the apple thread network with 2 border routers) and the devices were always available in apple home, but were unavailable in home assistant. now I switched to zbt-1 for everything with nothing on the apple thread network and now the devices are plain unresponsive most of the time. even today though, the documentation for thread in HA still says multiple border routers is better so now I'm very confused as to what to believe, Marcel or the docs? and if I believe the docs is there a clean way to merge the two separate networks?

[vale folio]

due to issues with communication between thread border routers sometimes being problematic with older versions of thread (hoping for thread 1.4 stuff to improve this at some point...) in some cases you can get a more stable thread network with a single border router.

but that relies on your one thread border router being able to keep up with realtime traffic properly, having reliable communications to HA, and being located somewhere that it gets clear signal to several thread routing-capable devices to get a stable mesh.

as far as i know there's no way to make an apple device join another vendor's thread network, but if you import the apple credentials into HA it's possible to have the HA OTBR join apple's network. if all your devices are currently on the HA network that would mean you have to re-pair them all.

it's rather odd that you were having problems when using only the apple devices as thread border routers. possibly some sort of network communication issue between ha and the apple devices?

if that's still an issue, having a local otbr join the same thread network as the other tbrs is unlikely to work well, since the thread border routers need to communicate, and HA needs to receive thread messages routed via any of the thread border routers.

[merry gazelle]

agreed. at one point it was working flawlessly (where the devices were on apple's thread network) in home assistant than one day everything was unavailable in home assistant but still available in apple home. however, there were no network changes

I'll see if I can get it to stabilize then maybe resort to re-pairing on apple which would suck because every time I do that it takes me like 4 hours and I've done it 3 times already.

[low spade]

Even though it’s off topic… Csn you please describe, what you did to get this „unavailable Matter lights“ counter graphic?

[merry gazelle]

@low spade its a template sensor:

{% set matter_entities = integration_entities('matter') %}
{% set guest_in_room_1 = is_state('input_boolean.guest_in_room_1', 'on') %}

{% set unavailable_lights = states.light 
  | selectattr('entity_id', 'in', matter_entities) 
  | selectattr('state', 'eq', 'unavailable') 
  | map(attribute='entity_id') 
  | list %}

{% set excluded_lights = 
  (states.light 
  | selectattr('entity_id', 'search', 'guest_room_1') 
  | map(attribute='entity_id') 
  | list if guest_in_room_1 else []) 
  + (['light.guest_bathroom_ceiling_light', 'light.powder_room_ceiling_light'] if guest_in_room_1 else []) %}

{% set filtered_lights = unavailable_lights 
  | reject('in', excluded_lights) 
  | map('replace', 'light.', '') 
  | list %}

{% if filtered_lights | length > 0 %}
  {{ (filtered_lights | join(', '))[:204] }}{% if (filtered_lights | join(', ') | length) > 204 %}...{% endif %}
{% else %}
  All Matter lights are currently available.
{% endif %}

I'm using grafana to pull the data from it but you achieve the same with just the history on the sensor

[merry gazelle]

reset every light again. cleared the matter devices from my iphone settings, deleted every affected device in home assistant. reset the otbr and joined it with the apple thread network and started readopting one by one through nanoleaf. 8 hours later, I successfully got 1 light working.

I've tried limiting 2.4ghz on channel 1, zigbee on 26, and thread on 15, 20, and 25.

now I'm resetting everything again, creating a new ha thread network separate from apple and trying to adopt directly into haos with the iphone app.

[merry gazelle]

I got 8/60 lights adopted direct to home assistant. I'm noticing this behavior:

1. factory reset light
2. adopt using matter in HA
3. it says "setting up"

OTBR

00:10:02.823 [N] MeshForwarder-: Dropping (reassembly queue) IPv6 UDP msg, len:1251, chksum:b16c, ecn:no, sec:yes, error:ReassemblyTimeout, prio:normal, rss:-68.0, radio:15.4
00:10:02.823 [N] MeshForwarder-: src:[fd3b:3272:730a:1:23c9:2564:9306:41f7]:5540
00:10:02.823 [N] MeshForwarder-: dst:[fd3b:3272:730a:1:63a6:70a4:a931:3f83]:38379
00:10:06.826 [N] RouterTable---: Release router id 4

4. it says "Unable to Add Accesory" then this log shows up:

Matter
2025-03-09 22:18:35.905 (MainThread) DEBUG [matter_server.server.device_controller.mdns] Discovered commissionable Matter node: AsyncServiceInfo(type='_matterc._udp.local.', name='3F7405525A3F91FC._matterc._udp.local.', addresses=[], port=5540, weight=0, priority=0, server='5AF9EC0C7A99D40B.local.', properties={b'VP': b'4442+65', b'SII': b'800', b'SAI': b'800', b'SAT': b'4000', b'T': b'0', b'D': b'1670', b'CM': b'0', b'RI': b'34004EC241BF52C95CF04EB14625E0ACD0DF', b'PH': b'36', b'PI': None}, interface_index=None)

this is a light that is 4 ft from another connected light

[merry gazelle]

Ok. I moved the thread network to 25 and my zigbee is on 26. for a different light with a similar problem as above, I got this:

otbr:

00:14:30.754 [N] RouterTable---: Allocate router id 18

then it got stuck in "connecting" and ultimately failed.

reset it again and got the mdns discovery happened before the error (and before adopting)