I’m not sure, I don’t know how it all this works. But from what I’m reading here: How do I Unify thread networks? , it seems that the older 1.3 Thread network (over the 1.4) allows for you to unify the Thread Network by making it the preferred network, but mostly with the help of Home Assistant or other similar methods and that would allow this to work. Most cases though they seem to only work with Main Hubs, not the Appliance based Hubs. Not only this, but it could be due to fact that all but Main Hubs (other then the new V4 Hubs) required to be connect to a network via an ethernet cable. But again, I’m not sure on how all this completely works, I just understand the basics.
I get that, I’m not too sure how it works either. I’ve also never got a chance to unify two ST Hubs, but I do remember unifying my HomePod and Soundbar Hub wasn’t possible (on Galaxy) because HomeKit doesn’t have an interface to do so (input the one time thread code). Although using the iPhone it happened automatically, which I am assuming is due to the fact that the device has stored the credential. My theory is the same thing would happen on a Galaxy, I try to unify two ST hubs and it happens without the interface/inputting codes, since the phones stores the credentials.
Two SmartThings v3 hubs in one Thread network and Aeotec Smart Home Hub 2 (v4 hub) in second Thread network
Aeotec Smart Home Hub 2 (v4 hub) is the hub where is this issue No credentials found in your shared keychain
SmartThings Hub v3 has been replaced with Smart Home Hub 2 using Hub Replace. To Smart Home Hub 2 has no Thread devices added after Hub Replace.
Is your Aeotec Smart Home Hub 2 connected via Wire or are you running it Wirelessly? I know that all V4 Hubs can run either way, all V3 Hubs and older had to be Wired, and all Built-in Hubs other than TV’s I believe run Wirelessly. The other odd thing again is both V4 Hubs and Built-in-Hubs don’t have Z-Wave, but I don’t see how this would prevent the Thread Credentials from not saving.
Via Wire
V4 Hub has also in Settings WiFi (5 GHz) but I think that the hub is not using WiFi.
I’m not for sure, but I think when the new V4 Hubs and TV’s with Built-in-Hubs and are connect via wire, if they are setup while having a saved Wi-Fi Network within the SmartThings App that it uses that saved Wi-Fi Network as a back up say the wire were to fail or get cut. So if this is true it would only switch to Wi-Fi in this scenario. If I’m wrong that setting is more than likely there just to show what Wi-Fi Network it is on if you had set it up to run wirelessly.
My V4 Hub has always been connected using Wire.
I think during the hub setup the ST app copied my phone’s WiFi settings to the V4 Hub.
But that’s only for networks where the credentials are already stored, isn’t it? You still need the smart home platform app to store them or use the Home Assistant app.
The only option I have in Google settings is to save them to Google Cloud, but that’s not storing the credentials in the keychain, that’s just a backup in the cloud if you change the phone or is damaged or lost.
This is what I noticed, what’s even weirder is my Google Hub(s) don’t even show up as a Preferred Network like @TapioX showed in their screenshot above, but does have stored credentials. Is the Preferred Network a SmartThings only thing though?
Do you have a mesh wifi system? I do and I cant find the thread network unless im near the disc which is closest to the Thread Border router. Dunno why that should be the case but it seems to be
… by the apps that use this API. At one point, the ST app must have stored the credentials there and when I used the Aqara Home app to add the G350 camera hub (TBR), it must have retrieved them from there.
The cloud sync is just a nice to have backup.
Exactly, that’s what is missing for people here, SmartThings app originally never used the APIs to share the credentials with Android or iOS, nor read them to join other networks.
Maybe by the time you configured the new hub v4 the SmartThings app already started to share the credentials. Or it or Aqara’s did when trying to join another TBR indeed. Before that, the companion app of Home Assistant was the only way to get Android to store the credentials and be available for other apps / platforms.
I do and don’t, one Thread Network the Hubs run off a meshed Wi-Fi, but all devices are closer to the main wireless router (inside house, the other wireless router is meshing outside on the siding of a steel polebarn about 100 feet away). As for the second Thread Network it is running off a non-mesh router that is directly wired to a Wireless AP directly from the original Wireless Router, then running wirelessly of that. Here is a crude drawing of my setup. I know it’s more than what is necessary, but it works for me.
I’m not sure what this means, but my HomePod network shows up (not greyed out) when I switch the band to 5 ghz, also it’s supposed to be apart of my thread network with my Soundbar. Trying to connect to the mesh always fails though, citing something about my wifi network.
Do you have a mesh wifi system? I do and I cant find the thread network unless im near the disc which is closest to the Thread Border router. Dunno why that should be the case but it seems to be significant
I do not, when I said mesh, I was referring to what it says in the app, connect to mesh (thread network).
While I found out something. If the hubs are within a hub group or setup individually I get the error message on both devices (phone and table). But the second I add them via the “Manage Thread Network” and “Unify Thread Network” the error goes away as I have to use a passkey to unify the network. This only works for the device I initiated the unification with though (in this case my phone). The other device (Tablet) still has this error. Now this maybe due to the fact that I am the main user of the Tablet as it’s a family device and the actual user account is of another family member. I don’t know if this is the case though, but it does sound more like what @orangebucket was saying with their personal vs admin phone than user account related.
I should note that a change of handset has made me far more likely to use my admin phone of late and that behavioural change might correlate with ST starting to save credentials as mentioned earlier.
The tool has a flaw in the way it finds Thread networks. The tool treats the Thread network name as an identifier rather than just metadata. This is fine as long as the Thread network name is never changed and therefore the label matches the network stored in Google Play Services and the network key can be found. But if the Thread network name is changed, the tool can’t locate a network with that label and therefore says it can’t find the credentials. In reality, the network hasn’t changed since it’s identified by the immutable values of network key, Extended PAN ID, PAN ID, and dataset timestamp. The tool should really query for TBRs using mDNS and then extract the immutable values from the responses to locate the credentials and not rely on the network name.