Will this allow me to get my Homey Pro 2023 to join an existing Thread mesh, without needing to factory reset and start from scratch?
On Slack they said, it supports basic Thread 1.4 but explicitly not Credential Sharing and it’s therefore also not Thread 1.4 certified…
@Doekse Can we expect credential sharing in the near future?
@Doekse Any comment please?
Credential sharing isn’t quite as straightforward for us to implement, but it’s something we’re currently looking into.
The biggest challenge is that Thread and Zigbee share the same radio. If Thread joins another network that operates on a different channel, Zigbee may need to switch channels as well. This could potentially break the existing Zigbee network, as not all Zigbee devices support changing channels after they’ve been paired.
Personally the direction I’m more interested in is some other TBR joining Homeys Thread network, so Homey not having to change the channel at all. But I assume this would still require both Homey and the other TBR to support credential sharing.
That should already be possible, if I’m not mistaken. Usually, this can be handled through either iOS or Android, provided the platform supports it as well.
Homey can already join an existing Thread network, but currently only during the initial setup. During setup, Homey checks for saved Thread credentials on your phone and, if available, will attempt to join that network.
This is what I was hoping this update would solve, alas we wait 
My reading of “isn’t quite as straightforward for us to implement” is that, with the current architecture, it may simply not be reliably feasible.
If Thread and Zigbee share the same radio, then Thread credential sharing is only part of the problem. You also have to deal with the fact that both networks may want to operate on different channels.
Software can probably coordinate some of this, but I don’t see how it can fully solve the underlying limitation. Changing a Zigbee channel is technically possible, but in practice it can be messy because not every Zigbee device follows a channel change reliably.
So when you say that you are “currently looking into it”, does that mean you are also reconsidering the hardware architecture for future Homey models?
Because with one shared radio, I find it difficult to see how software alone could make this completely transparent and reliable for the user.
Oh, it definitely is. We just need to find a good way to clearly inform users that their Zigbee network may need to be reset and that all devices would then need to be repaired.
In the backend, we’ll first need to check which channel the Thread network Homey wants to join is operating on and compare that with the channel Homey is currently using. If the channels match, that’s easy: Homey can simply join the existing Thread network.
If they don’t match, Homey will need to switch channels. Since Zigbee and Thread share the same radio, the cleanest approach would then be to reset the Zigbee network and bring it up again on the new channel.
We’re currently working out the best UI/UX for that process, especially around clearly explaining the impact to users before they proceed.
Yes. My Home Assistant also joined the Thread network that was originally created by Homey.
A Thread network is largely self-organising. The devices share the same operational dataset, including the network credentials and channel information, and the network does not fundamentally belong to a particular Border Router.
That is one of the important differences compared with how many people think about traditional hub-based networks.
If one Thread Border Router is switched off and another remains available, that should not create a new Thread network. The remaining Thread devices and routers should continue operating as the same network.
Thread also supports channel changes as part of the network operation. If the network moves to another channel, the devices are expected to follow that change rather than creating a separate network.
So simply starting one TBR and shutting down another should not, by itself, change the Thread network.
I don’t really consider that a proper solution.
For users who are already mostly on Matter and only have a handful of Zigbee devices left, this may be acceptable. In my case, for example, I have already moved away from Zigbee completely.
But what about users with 50, 100 or even more Zigbee devices?
Are you seriously expecting them to reset their entire Zigbee network and pair every single device again just to make Thread credential sharing possible?
For a large and mature installation, that can mean hours or even days of work, including rebuilding device assignments, checking automations and verifying that every device has joined correctly again.
A migration path that requires destroying an existing Zigbee network is therefore difficult to call a real migration path.
I understand that the shared Zigbee/Thread radio creates a difficult technical constraint, but from a user’s perspective the solution should ideally preserve the existing Zigbee network rather than require rebuilding it from scratch.
On the latest OTBR update in HA, V3.2
“Thread 1.4 Credentials Sharing (ePSKc): share Thread network credentials with other devices directly from the Web UI”
My reluctance to a factory reset with Homey Pro 2023 is that I will lose over a year’s worth of energy monitoring data, just to be able to ask Homey Pro to join my HA Thread mesh, which isn’t an acceptable sacrifice.
We’re not talking about a full factory reset here, only a reset of the Zigbee network.
As an end user, the only thing you would need to do is repair your Zigbee devices. All existing device data and settings will remain intact, and your Flows will continue to work as before.
Those users will have the option to join another Thread network or simply leave their current setup as-is.
Another option would be to have the other Thread Border Routers join Homey’s Thread network instead. In some cases, that might actually be the easier approach.
Unfortunately, there isn’t much we can do about this, as many Zigbee devices don’t support channel hopping.
If we changed the Zigbee channel without resetting the network, the end result would effectively be the same. The difference is that the devices would still appear as if they could be controlled, even though they would no longer be reachable.
Again, we’re currently working out the best UI/UX for handling and clearly communicating this to users. And I want to press; It isn’t mandatory to join another Thread network, just an option we want to offer.
Sorry, but I see this from a different angle.
The limitation may be real, but it also comes from the hardware architecture that was chosen.
In my view, the single-radio / single-antenna design was already a questionable choice for the 2026 model. A future Homey model with separate radios for Zigbee and Thread could avoid this entire class of problems and allow both networks to be handled independently on their own hardware.
That would make it possible to migrate Zigbee and Thread separately, instead of trying to force both technologies through the same radio constraints.
So I see the current approach less as a real solution and more as trying to make the existing architecture fit with a crowbar — while the users are the ones who have to adapt around its limitations.
For a future hardware revision, I would strongly prefer fixing the architectural limitation itself rather than designing more workarounds around it.
Sorry, but I was answering the question from the original post. I wasn’t referring to any potential future hardware designs.
For the current generation of products, specifically Homey Pro (Early 2023), Homey Pro (2026), and Homey Pro mini, this is how we’ll most likely implement Thread Credential Sharing.
I understand, but it is still not something I would call a solution. I have nothing more to add to this point.
