HA Yellow - 2025.11.3 / Using onboard chip for Matter/Thread
OpenThread - 2.15.2
Matter Server - 8.1.1
I USED to have the HA and two Google Hub(s) in my preferred network, the other day, I noticed that ALLLLLLL my Matter devices were offline (5 Eve Energy, 5 Eve Door Sensors, some door locks, plugs, etc…). Checked my Thread network, and noticed that the Google Home hubs decided they were going to LEAVE the network and form their own little group.
Seriously, when I set this up - they were all under the “Google-0F8D” network, and now they decided to leave and join the “ha-thread-749f”, which I don’t even know where that came from.
Is there anyway to combine the networks again, or do I need to nuke this whole thing and start from scratch? And how do I stop them from running off and forming a new gang, again?
I don’t think I have seen this happen before from other Forum users, so don’t have any ideas as to why it happened. I do see that there are two Thread datasets in play, one dataset named Google-0F8D, and the other ha-thread-749F. One of course originated from one of the Google Nest Hubs (assuming you have no other Google Thread controller), and the other from HA when the OTBR AddOn was first added.
My guess is that somewhere along the way a “sync’ing” was performed with an android based mobile device which put the ha-thread-749F dataset on the mobile device, and which put the Google-0F8D dataset in HA from the mobile device, so now the mobile device has two Thread datasets.
AFAIK, Android mobile devices will always use the first Thread dataset it knew about when which likely was the Google-0F8D one. Why the Google Nest Hub changed over to the ha-thread-749F dataset, I’m at a lost for, but I would think this could be prevented if Android mobile device never got the ha-thread-749F dataset to begin with.
Yeah’ I’m starting to realize that matter is a piece of shit. I don’t know if it’s the HA or just the protocol in general, I’m more inclined to think it’s the protocal.
I should have just stuck with zWave/Zigbee, it worked solid with no issues - but nope - moved to this new house and decided to get better “automation”. Spend hundreds of dollars on new Matter door locks, sensors, light bulbs, switches, even the mains powered Eve Energy (was a recommendation from someone here) to “make the network healthier” and it’s a constant issue everyday that 90% of the devices are offline.
I restart the HA and Router, they come up for a good 9.7MS and then they’re unavailable again with this error in the logs:
2025-12-08 17:16:47.283 (MainThread) INFO [matter_server.server.device_controller] <Node:28> Setting-up node...
2025-12-08 17:16:47.284 (MainThread) DEBUG [matter_server.server.sdk] <Node:28> Attempting to establish CASE session... (attempt 1 of 2)
2025-12-08 17:16:53.702 (MainThread) DEBUG [matter_server.server.device_controller] read_attribute called for node 38 on path(s): ['1/319486977/319422478'] - fabric_filtered: False
2025-12-08 17:16:57.970 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:34029i with Node: <0000000000000000, 0> S:0 M:143450995] (U) Msg Retransmission to 0:0000000000000000 failure (max retries:4)
2025-12-08 17:16:59.433 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:34028i with Node: <0000000000000000, 0> S:0 M:143450994] (U) Msg Retransmission to 0:0000000000000000 failure (max retries:4)
2025-12-08 17:17:04.983 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from peer <000000000000001C, 1>. Current state was 4
2025-12-08 17:17:07.984 (MainThread) DEBUG [matter_server.server.sdk] <Node:28> Establishing CASE session took 20.7 seconds
2025-12-08 17:17:07.984 (MainThread) INFO [matter_server.server.sdk] <Node:28> Attempting to establish CASE session... (attempt 2 of 2)
2025-12-08 17:17:08.487 (MainThread) INFO [matter_server.server.device_controller.mdns] <Node:28> Discovered on mDNS
2025-12-08 17:17:08.487 (MainThread) DEBUG [matter_server.server.device_controller] <Node:28> Setup task exists already for this Node
2025-12-08 17:17:08.648 (Dummy-2) DEBUG [chip.storage] DeleteSdkKey: g/s/X0j9ujayw7gl514+tewgqQ==
2025-12-08 17:17:08.649 (Dummy-2) DEBUG [chip.storage] SetSdkKey: f/1/s/000000000000001C = b'\x150\x03\x10\xe5\xf0\x18\x05\xfa?Dk\x97w\xffP\xe5\xfc?D0\x04 \xab\tO\xec\xbbDn\x92#\x9f\x11\xeb\r\xa7=l\xaf\x83:\xd9x\xd5~\xb1\xb2\x1e>\xdf`\xbe3\x100\x05\x0c\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x18'
2025-12-08 17:17:08.649 (Dummy-2) DEBUG [chip.storage] SetSdkKey: g/s/5fAYBfo/RGuXd/9Q5fw/RA== = b'\x15$\x01\x01$\x02\x1c\x18'
2025-12-08 17:17:08.650 (MainThread) DEBUG [matter_server.server.sdk] <Node:28> Establishing CASE session took 0.7 seconds
2025-12-08 17:17:08.650 (MainThread) INFO [matter_server.server.device_controller] <Node:28> Setting up attributes and events subscription.
2025-12-08 17:17:08.858 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from peer <0000000000000017, 1>. Current state was 4
2025-12-08 17:17:10.011 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:34027i with Node: <0000000000000000, 0> S:0 M:143450993] (U) Msg Retransmission to 0:0000000000000000 failure (max retries:4)
