### Describe the issue you are experiencing
About a month ago, I added a ZBT-2 …to my Apple Thread network using Home Assistant's OTBR add-on. In short, my devices went offline and didn't come back until I deleted the device. I set the device aside and then uninstalled the OTBR software. In the next day or two, I rebooted my HA host and from that point on I've experienced every-6-hour Matter "storms" where a portion of devices go offline and then come back.
I see others are having this same issue and anecdotally it appears that there are two things in common: A Unifi network and the OTBR software (or in my case, the uninstalled software). That's why I'm posting this here.
I've explored this issue every which way and have been able to find a source of the every-6-hour disruptions. I've checked my Unifi logs and Node Red automations (I only have a handful). I've set up pings to my Apple devices during the storms, and none go offline. I've tried removing classes of devices, and it made no difference. I've tried all of my Apple TBRs individually, and no change. I have of course restarted the Matter server, and still nothing.
Between the storms, the logs show normal operation with stable CASE sessions, active subscriptions, consistent operational IPv6 addresses, and regular attribute reporting across multiple nodes. At storm onset, the controller begins logging widespread no-response-timeout errors, indicating that requests are sent but expected responses are not received within protocol timeouts, followed by repeated retransmissions and retransmission-limit-reached errors across many unrelated nodes. During this same period, the log shows new operational addresses in different ULA /64 prefixes appearing (not just interface-ID churn within one prefix), frequent rediscovery events, and the creation of new sessions to updated endpoints, showing that existing peer addresses are being replaced while prior sessions remain present but fail to complete transactions. Communication failures occur simultaneously across a broad set of devices during this phase. As the storm subsides, error frequency decreases, new sessions stabilize, subscriptions and attribute reporting resume, devices are re-interviewed, and normal bidirectional communication and steady-state reporting are restored.
I've noticed that the number of ULA prefixes that devices route through has moved from 2 on 1/31, to 3 on 2/2, to 4 ever since 2/4.
A few notes:
The 6-hour window seems to be drifting later about a minute or so a day, indicating that the timer is paused and then restarts at a certain point.
The current times are around 09:50, 15:50, 21:50, and 03:50.
At least one time, the start of the timer seemed to coincide with the reboot of my HA host, but I have recently rebooted and it did not change the times.
The devices that go offline tend to be on the periphery of my mesh, and farthest from my TBRs. The mesh is very stable between the every-6-hour events, but something happens on the network that causes the weakest links to fail.
About 20 percent of my 102 devices go offline and the disruptions last about 10 minutes. I have matter.js installed and that improved things a lot. Previously with the python matter server, about 70 percent went offline and it took about an hour to rebuild.
All of my devices are powered except two smart locks. I have Inovelli White Switches, Sunricher RGB Controllers, Eve Energy smart plugs, and the Aqara smart locks.
Is it possible that the addition of the OTBR software and its removal left something behind that disrupts my Matter network every six hours? Are the IPv6 prefix changes in the log indication of network traffic being directed to ghost dead-ends? Can you think of anything that might occur every six hours that might be the cause of this?
### What type of installation are you running?
Home Assistant OS
### Which operating system are you running on?
Home Assistant Operating System
### Which app are you reporting an issue with?
OpenThread Border Router
### What is the version of the app?
See notes, it's been uninstalled. It was originally installed in mid-January.
### Steps to reproduce the issue
1. Wait until 09:50. Devices start going offline.
2. At about 10:00 most or all devices are back online.
3. Everything is smooth again until 15:50 pm, plus maybe a minute or so (the drift).
4. Repeat.
...
### System Health information
## System Information
version | core-2026.1.3
-- | --
installation_type | Home Assistant OS
dev | false
hassio | true
docker | true
container_arch | amd64
user | root
virtualenv | false
python_version | 3.13.11
os_name | Linux
os_version | 6.12.63-haos
arch | x86_64
timezone | America/Los_Angeles
config_dir | /config
<details><summary>Home Assistant Community Store</summary>
GitHub API | ok
-- | --
GitHub Content | ok
GitHub Web | ok
HACS Data | ok
GitHub API Calls Remaining | 5000
Installed Version | 2.0.5
Stage | running
Available Repositories | 2684
Downloaded Repositories | 2
</details>
<details><summary>Home Assistant Cloud</summary>
logged_in | true
-- | --
subscription_expiration | June 13, 2026 at 17:00
relayer_connected | true
relayer_region | us-east-1
remote_enabled | true
remote_connected | true
alexa_enabled | true
google_enabled | true
cloud_ice_servers_enabled | true
remote_server | us-east-1-7.ui.nabu.casa
certificate_status | ready
instance_id | f69f770cb1c148ec8df3cd52437b8e1a
can_reach_cert_server | ok
can_reach_cloud_auth | ok
can_reach_cloud | ok
</details>
<details><summary>Home Assistant Supervisor</summary>
host_os | Home Assistant OS 17.0
-- | --
update_channel | stable
supervisor_version | supervisor-2026.01.1
agent_version | 1.8.1
docker_version | 29.1.3
disk_total | 468.7 GB
disk_used | 15.1 GB
nameservers | 192.168.1.1, 2601:602:9200:edf6::1
healthy | true
supported | true
host_connectivity | true
supervisor_connectivity | true
ntp_synchronized | true
virtualization |
board | generic-x86-64
supervisor_api | ok
version_api | ok
installed_addons | File editor (5.8.0), Matter Server (8.2.2), Node-RED (20.2.4), Get HACS (1.3.1), Terminal & SSH (10.0.0), Advanced SSH & Web Terminal (23.0.1), Samba share (12.5.4)
</details>
<details><summary>Dashboards</summary>
dashboards | 3
-- | --
resources | 0
views | 1
mode | storage
</details>
<details><summary>Network Configuration</summary>
adapters | lo (disabled), enp1s0 (enabled, default, auto), docker0 (disabled), hassio (disabled), veth496bc7f (disabled), veth23b2b57 (disabled), veth6f748c8 (disabled), vethef01640 (disabled), vethd5f1941 (disabled), veth52e906e (disabled), veth18d08d8 (disabled)
-- | --
ipv4_addresses | lo (127.0.0.1/8), enp1s0 (192.168.1.168/24), docker0 (172.30.232.1/23), hassio (172.30.32.1/23), veth496bc7f (), veth23b2b57 (), veth6f748c8 (), vethef01640 (), vethd5f1941 (), veth52e906e (), veth18d08d8 ()
ipv6_addresses | lo (::1/128), enp1s0 (2601:602:9200:edf6:898d:da70:e415:eee8/64, fe80::b10b:7ddc:a774:3936/64), docker0 (fe80::c8bf:bfff:feba:89d3/64), hassio (fe80::c88:faff:fe4d:7089/64), veth496bc7f (fe80::3057:73ff:fe7f:fa1/64), veth23b2b57 (fe80::a4e5:b7ff:fee0:2465/64), veth6f748c8 (fe80::a819:a6ff:fef0:1f34/64), vethef01640 (fe80::a031:65ff:fe52:5f5c/64), vethd5f1941 (fe80::1821:bcff:fe3c:298d/64), veth52e906e (fe80::107c:1fff:feb7:11be/64), veth18d08d8 (fe80::1841:a9ff:fe01:890c/64)
announce_addresses | 192.168.1.168, 2601:602:9200:edf6:898d:da70:e415:eee8, fe80::b10b:7ddc:a774:3936
</details>
<details><summary>Recorder</summary>
oldest_recorder_run | January 26, 2026 at 02:45
-- | --
current_recorder_run | January 31, 2026 at 13:15
estimated_db_size | 276.78 MiB
database_engine | sqlite
database_version | 3.49.2
</details>
### Anything in the Supervisor logs that might be useful for us?
```txt
Nothing. I've never found anything in the Supervisor logs to correspond to these disruptions.
```
### Anything in the app logs that might be useful for us?
```txt
I have uninstalled OTBR and only have Matter logs to work with. I'm updated the logs from a recent storm below.
```
### Additional information
[matterjs-storm-2026-02-06_0918.log](https://github.com/user-attachments/files/25142602/matterjs-storm-2026-02-06_0918.log)
Here is a recent log file. You can see things start to go awry ar about 9:50 am.