good info in this thread on the HA and thread/matter issues. I’ve got 30 that I will be installing in a new build in about 3 months. It does seem like it’s more HA’s Thread/Matter issues, but some of the issues like poor signal at the switch side and double/triple gang install issues is a little worrisome.
Does anyone have more than 10 installed with HA with no issue? And if so, what Thread Boarder Router do you use?
I’ve yet to see any detail anywhere on TBR’s and how everything is supposed to “mesh”.
I’ve forwarded some these issues and concerns to our engineer to see what he says. I am curious to know if you have tried matter server 6.5. I believe it was just officially released today.
To be honest, I don’t think the beta testers were using the border router with SkyConnect. I thought during initial beta testing that the HA folks said that the local border router add-on was not their recommended configuration, but that was quite a while ago so it may have changed.
Just over this weekend I have had many matter issues and failures that ended up being from some faulty network equipment connected to my network (I believe). After removing the devices and rebooting everything things went back to normal. It seems there are some complexities to Matter that get hidden behind all the fancy marketing. I suppose that is true for all smart home protocols. I will let you know what I find out, but as @jvm33 mentioned, it seems like matter server 6.5.0 may be more stable for some users.
Yes, using Matter add-on 6.5.0 now, but I am not having problems with Matter specifically as far as I can tell. There is definitely a Thread connectivity problem going on, if the border router’s signal strength graphs are to be believed.
Also, yes, SkyConnect used to not be a recommended solution. I believe it is now recommended, though. (Rebranded now as “ZBT-1” FWIW.)
It is true that all of this is very “beta.” I just want to be sure we are dealing purely with software problems, not connectivity issues related to radios or firmware on the devices. Insofar as there’s anything going on with the latter, I need to resolve those before I install all these switches! Or at least know that the fixes are coming if firmware improvements are part of the solution.
I got some feedback from the engineer to share. The summary of his statements:
1. The transmission power is decided by the firmware at the beginning of its work. I suggest directly increasing the transmission power with a firmware update
2. Yes, if we force some devices to be routers, because the number of routers in each thread network is limited, not more than 32, it is very likely that the entire thread network will crash
3. Currently, no cluster on matter can read the RSSI of thread, but Thread Network Diagnostics (0x0035) is a cluster that can read some network information of thread
You can read whether the device is a router on this cluster. Our switch supports being a router. When the number of routers in the thread network is less than 16, it will become a router. A thread network leader decides which devices become router/fed
The engineer did try increasing the transmission power and he said the results were positive. I can get an updated firmware with increased power output.
If at all possible, in a future update, I would suggest letting the transmission power be configurable within allowed ranges (restart of the device may be required if changed, of course). I’m saying this because I think there is very often a strong benefit to having a weaker transceiver to avoid interference. Still, given what I have seen so far with the limits of the transceiver right now, I do think a stronger power as a default with the next update would be a huge improvement for the typical use cases. Very excited by this!
I want to be clear that I DO NOT think you should force a device to be a router (actually, I do not even believe this is possible in the Thread model). Instead, devices should be configurable to be either “Router Eligible End Devices” (REEDs) or “Full End Devices” (FEDs). When a device is a REED, it can be promoted to be a router by the network dynamically, as needed. When a device is a FED, and not a REED, it cannot be promoted to be a router. Thus, if you allowed the user to flip a bit via configuration that put the device in “REED” or “non-REED” mode, you would give the user the option to say “this device should never be used as a router.” In particular, in combination with an option to set the transceiver power lower, you could create a stronger network in which the REEDs have high power to reach other REEDs, while the FEDs could maintain lower power to avoid interference.
Thank you again for the responses! Very excited if we can get that update with the higher default power.
Just something of note, I believe the issue itself is in home assistant. I have the switches in apple home and home assistant and I have a switch in a multi-gang that goes “unavailable” while being fully responsive in apple home.
Both using the same border router ATV 4K 2nd gen
We bought five switches in the first preorder batch that we installed about a month ago and are all working as expected. We bought another 11 after testing the first batch and those switches arrived today. We’ve installed four of them so far, and the button mapping in HomeKit is different from the first batch.
In the first batch, Button 1 is the top button, Button 2 is the bottom button, and Button 3 is the small config button. In this new batch, that is true for two of the switches. For the other two, they don’t map that way. Button 1 is the bottom button and Button 2 is the top button.
We just reversed how these two switches are mapped so that things work as expected but ideally all switches would map the same way. Is anyone else having this issue?
Apple’s Matter implementation is pretty simplistic and a bit sloppy when it comes to more advanced features like this. Its one of a number of reasons I use HomeAssistant as my primary controller. Its more complex to set up initially, but it works (plus, you can still set up HomeAssistant to use iOS Home as a user interface).
I have had four switches become unresponsive to Thread and physical buttons, when power is cut and restored to them they factory reset themselves. I am then unable to commission them them again. It appears to be a firmware bug where the switch isn’t responding to BLE messages for the first step of Matter commissioning. I have sent 3 for RMA but the 4th one just happened this morning.
Some information about my setup:
Fabrics connected: 2 (Google and Home Assistant)
Channel: 25
Border Routers: 6 (4 Google Homes, 1 Apple Homepod Mini, 1 i.GL S20)
When you perform the factory reset, can you confirm that the switch reboots and the settings are at default?
Maybe try to change the switch to dimmer mode by holding the down button and then pressing the config button 3 times (LED should flash to confirm and holding the button up or down should dim). Then try to commission the switch after that and watch to see if the LED starts pulsing blue. If it does not, factory reset again and try one more time.
Yep when I factory reset the switch it reboots and settings are back to default.
I just tried switching it to dimmer mode and factory reseting again, and both times my phone (Android) is sitting on “Searching for Device” and times out. The LED bar never pulses I also tried pressing the config button 3 times but that was unsuccessful as well.
On other white switches than these four I am able to factory reset them and commission them without issue. My phone quickly switches from “Searching for Device” to “Connecting to Device” and commissioning continues as expected.
If there is anyone interested in testing a firmware update that increases the transmit power of the thread radio please PM me and we can try to sort out a way to get the update to you.
@EricM_Inovelli and @rubixhacker, I have had this exact same behavior on one of my White switches as well. I opened up a support case on Sunday (ticket #897) but I have not heard anything back yet.
Everyone that has seen this issue, have you been running the switch in “multi-admin” mode? Administering the switch from multiple hubs (joined to one hub and then shared to another).
Originally I was running in multi-admin with the switches joined to Google Home and then shared with Home Assistant. When this switched froze up, it was in this mode. Since then, I have factory reset all my White switches and they are only connected to Home Assistant.
@EricM_Inovelli@KenS@rubixhacker – Wanted to report that I, too, now have one of my White switches failing in the same way as described by KenS and rubixhacker. I’m unable to commission the device after a general Thread network outage kicked it off the network a few days ago. I have done factory resets and air-gap pulls over and over, and the BLE portion of the commissioning process won’t even start (never pulses blue).
Wondering if there isn’t a firmware bug that causes the Thread network credentials to not actually be cleared in some cases, thus preventing the process from kicking off…?
EDIT: Figured I should also add a little more diagnostic info I neglected. When the device originally fell off the network some days back, at the same time many other devices did, all of the other devices came back except this one. This one remained unreachable by the Matter server. So it’s perhaps something a little deeper than just a bug preventing commissioning – it’s as if the Thread network could not reach the device at all, thus perhaps a general radio disablement…
I wonder if the problem isn’t that the VTM31-SN is suffering from a radio failure that causes it to jabber on the Thread network and knock all of the other Thread devices off?
How does Thread deal with a jabbering node?
Can a border router vote a node off of the island if it detects a malfunction?
Just throwing out another possibility that I don’t recall being discussed yet…
Thanks guys!