Didn’t want to post this in the bug thread cause im not sure if its my house or switches or thread itself. I have about 18 switches I just installed a couple of days ago in my house, all connected to home assistant using an open border thread router running off a rpi zero w and nRF52840 dongle.
One thing I noticed is that switches further than about 10 feet from the OTBR are extremely flakey and drop on/off the thread network constantly. I have never seen more than 14 devices consistently on the topology of the network. I thought maybe its the OTBR but the switches themselves cannot seem to properly form a mesh between themselves either. Has anyone else seen this? Do I just have some odd interference I cannot see?
Same issue here, more or less. I can see the topology on my Home Assistant hosted SkyConnect OTBR, and there is a mesh being formed to some extent, but two or three devices at any one time will be dropping out of the network.
Not clear to me whether this is a OTBR bug, or interference, or something in the White series firmware that’s flaky, or a radio hardware fault…?
I would believe this to be a bug with the platform. I have 5 switches currently with the closest one being about 15 ft to a hub and the switches being spaced apart about 10ft from each other thru walls. I haven’t had a single disconnect. I’m using an Apple TV 4K gen2 as a hub and it’s integrated to home and home assistant. Hope that helps gathering information.
I went around my house and did the test for thread network strength (hold config button until green and observe color). Its approximately split between yellow and red but not consistent. The switches furthest from my border router are yellow and the ones closest are yellow, however some red switches are right next to yellow switches.
I really hope its not the platform because I like Open Thread Border Router
So I currently have Home Assistant running in my basement with a SkyConnect (most central area not on the main floor). I run Home Assistant in a VM on a rack server so I can’t really move it. But I do plan on adding another border router in the future that should have line of sight to most of the switches I plan on installing.
I currently have on my thread network:
Inovelli switch in my garage – 12-15ft
Inovelli switch outside my kids bedroom – 15-20ft
Eve door sensor on my front door – 20-25ft
Eve door sensor on the door to the garage – 12-15ft
Eve door sensor on my back patio door – 30-35ft
The Inovelli switches are currently the closest devices to my home assistant yet they constantly drop off the network. Half the time I’m able to get them to rejoin by tripping the breaker but even then they drop back off randomly.
All of the Eve devices reliably stay connected to the home assistant but the two switches drop off regularly and don’t reconnect for days.
I’ve already got more switches on their way and I’m hoping that will solve the connectivity issues but I don’t know. I’m also going to try and setup a 2nd Thread Border Router next week to see if that happens to solve or at the very least give me more information on signal quality.
Anyway, not sure if this info helps anyone or if anyone has any additional ideas on how to improve the connections?
Thankfully the switches closest to my border router stay connected and they are 10-20 feet. I moved my border router this weekend and 3 of my switches consistently disconnect but will reconnect occasionally on their own. Its easy to find them at least because the signal checker shows them as having a red signal while the rest, even directly next to the border router, show yellow.
Trying to judge the strength by distance from the OTBR isn’t a reliable indicator. The devices could be routing through another device. Also, the devices will dynamically recalculate routes from time-to-time as they measure signal strength, errors, and other factors.
Whether it helps will depend on the brand of border router. Regardless of the number of OTBRs, only 1 will be the “lead” (well, there are some unusual network arrangements that might cause two OTBRs to be active, but its pretty rare) - the remainder are just waiting in case the lead fails (in which case, another will then take over). Except 2 things: The other OTBRs will act as “regular” routers when they are not in the “lead” role, so that gives you some additional routes. Also, if you use Apple TV or HomePods as your border routers, they support an optional feature of the standard called Thread Radio Encapsulation Layer which, in essence, allows a thread packet received at the Apple TV / Homepod to be transported over WiFi / Ethernet to the lead OTBR which can increase network bandwidth. I think some Google OTBRs also support TREL. Supposedly, the next Thread release (i.e., version 1.4) will make TREL mandatory - that’s supposed to happen sometime in 2024, but who knows how long that will take to get into product.
I have the opposite situation where I believe Eve is the issue. I have about 70 matter devices, with 10 Inovelli switches. All reliable. Except, if I add my Eve Motion sensors (six of them), the entire network fails or goes into a mode of constant re-calculation of routes. I’m on HomeAssistant using 3 Apple TVs and 6 Nest WiFi Pro OTBRs. I’ve had the same problem with Eve before using the Inovelli devices. Including them in my network consistently causes network instability. I’ve done several test - removing them, adding them back, etc. and I’m 99% sure my issues come from Eve. I note that many Eve devices were built on the earliest Matter SDK (1.0, as revealed on the CSA device certification web site) which means they have the least refined software layer. I know you probably won’t want to do this but consider removing Eve devices and see if it impacts network stability.
Honestly I’m trying to rule out the SkyConnect itself as the culprit. So my plan is to get a 2nd Thread radio and just install Open Thread Border Router on a Pi and see if I can use that to get more information on the signal quality of my main border router / home assistant, or at least just find more information as to what’s actually happening. If I can prove it’s Home Assistant / SkyConnect causing the problem. If it is then I can look at some other TBR like a Nest Hub.
I then joined the new border router to the existing mesh and as soon as I got everything configured my thread topology instantly stabilized but now it’s the eve door sensors periodically dropping off.
Holding the config button to check signal quality shows green on both switches now.
P.s. I’ve got a dozen new switches coming today so I’ll see what if anything that changes once they are added to the mesh.
I am experiencing poor range as well. I have two switches in the same box and a Sky Connect in the basement right below the switches.
At first the Sky Connect was near the basement floor. I had everything paired and working great. Suddenly, the switches became unavailable and would no longer pair. I moved the Sky Connect up toward the ceiling in the basement and have been able to pair them and get everything working again.
Oddly, out of the two switches I have in the box, one shows green for signal strength and one shows yellow. Not sure why they would be different as they are the same distance from the Sky Connect.
Lack of range is disappointing. Not near as good as my Zigbee devices.
Multiprotocol will remain an experimental feature and is not recommended for use.
When we launched this device, we announced our intent to release firmware supporting multiprotocol, which allows the device’s Silicon Labs chip to connect to both Zigbee and Thread networks with one radio.
This experimental firmware has been available since December 2022. Through extensive testing, we have found that although it works in some circumstances, it has technical limitations that lead to a worse user experience. We now do not recommend using this firmware, and it will be experimental for the foreseeable future. Instead, we will focus on making sure the dedicated Zigbee and Thread firmwares for Home Assistant Connect ZBT-1 deliver the best experience to users.
If you currently have the multiprotocol firmware installed but don’t actively use it to connect to Thread devices, we recommend that you disable multiprotocol.
Nothing changes for current users of the multiprotocol firmware who are happy with their experience. The experimental multiprotocol firmware will remain available, but we will not recommend it to new users.
Out of the 18 switches I have deployed most of the ones with issues are in the same box as ones without any issues at all. From my count every dual or higher gang has atleast 1 perfectly working and 1 that constantly drops off. One will have yellow and one will have red always. I have 5 dual gang boxes, and 6 flakey switches in those, and then 2 flakey single switches that are < 5 feet to the transceiver.
Ordered a esp32-h2 based board to see if it fairs any better.
So far, the only switches I’ve had “drop off” problems with on the network are those which are multi-ganged also. E.g., I have a 4-gang with three of the White series in it, and one of those three may drop off at any one time. So far, the other 5 I’ve installed in other gangs scattered about have had no issues that I’ve been aware of.
Curious whether there’s interference between the radios playing a part here.
I’m having this same issue with a setup almost exactly like yours. I really think this might be an HA issue. I paired one of the switches directly to homekit, and there has not been one drop since install. switches paired to HA will just randomly drop. I have one switch, in a single gang box, about 5 feet from the skyconnect and it’s unavailable. what’s interesting is that I can ping it, so it’s there and addressable. when I look at the matter server logs (HA → Addons → Matter Server → Logs) i can see errors for that node. It pretty much always looks like this for a device that is “unavailable”
2024-08-30 08:44:17.860 (MainThread) INFO [matter_server.server.device_controller] <Node:40> Setting up attributes and events subscription.
2024-08-30 08:44:24.061 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:12146093 on exchange 51317i with Node: <000000000000002C, 1> sendCount: 4 max retries: 4
2024-08-30 08:44:27.485 (Dummy-2) CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 51317i with Node: <000000000000002C, 1>
2024-08-30 08:44:27.485 (MainThread) WARNING [matter_server.server.device_controller] <Node:40> Unable to subscribe to Node: src/app/ReadClient.cpp:682: CHIP Error 0x00000032: Timeout
I am seeing something similar actually. Its pingable but unavailable.
2024-08-30 10:09:35.688 (Dummy-2) CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 59905i with Node: <0000000000000011, 1>
2024-08-30 10:09:35.690 (MainThread) WARNING [matter_server.server.device_controller] <Node:17> Unable to subscribe to Node: src/app/ReadClient.cpp:682: CHIP Error 0x00000032: Timeout
it almost seems like (and this is all a guess from me) the device is still doing fine on the thread network why you can ping it and why you don’t have to re-pair it to get it working). HA/Matter Server failed to get details of the device and it goes to this unavailable state. Why it’s not retrying, or why this issue initially occurs, I’m not sure. maybe, at the particular time that it’s trying to get data from the device there is a thread network hiccup?? A hard reboot HA seems to bring it back, until another device goes unavailable lol
