As stated in the article outlining the release of the C-5, the new radios are built in. It also states that the zwave/zigbee devices are tied to the radio. So, if we upgrade to another hub in the future, will we have to go through the process of un-pairing/pairing everything? I just purchased the new hub, but I might decide to go back to the old one if possible.
Probably.... I base that opinion off of the fact that you can't migrate from the C-4 to C-5 without re-pairing either *.
(* If you want to migrate from the USB stick to internal radios)
Its actually worse then that because then you have to go into every single automation and add the device back in.
Considering how this hub came about with all the ST issues I am really surprised with the release of the new hub that there was not a way to migrate or restore the entire database.
I had swapped Vera's and restored to a new device and all my devices did not need repaired. Im sure that's a feature they will eventually implement, but until they standardize the device, probably a difficult feature to support.
The issue is that the devices are tied to the radio. So, if the radio isn't migrating with the database, all of them would have to be re-paired and would therefore need to be re-added to the database. Ideally, there would be a global like-for-like replacement function where you could select two devices and replace all the instances of one with the other throughout the entire hub in all apps. After all, they're just data elements stored in a database, right? I'm sure the function would be complicated as hell but it's gotta be possible. Even if you had to do it in some "administration" mode where no apps were running at the time it would still be easier than replacing one for the other by hand in every single app.
At least with z-wave, you can transfer primary controllers to another radio/controller. That support has been in there for a long time. Now, how well it works, and the caveats involved are another story.
I don't know if there is a similar capability in zigbee - never looked.
Why not just get the USB stick and build your system off that in the C-5 version...then just move your stick to C-6. Seems the best route....until the USB radio stick dies....then..well.
That is the issue if the stick dies....
I'm not sure there is a graceful workaround for that.... Maybe by the time we get to C6 there will be?
Because I will want a stick with Zwave 700 by this time next year, making the old stick obsolete.
Hubitat is relatively far behind in this arena. Wink, Vera, StaplesConnect, etc. etc. all have the Low Level ZWave Tools available to facilitate a Controller Shift. Hubitat is lacking. Using third party tools to 'copy' the stick's DB is readily available. OZWCP and ZenSys Tools.
For Zigbee, the PAN and Extended PAN have to be copied to the new stick. I don't have much Zigbee, so for me, a re-pair and adjust automations would make a lot more sense, right now. I haven't looked for third party tools for Zigbee.
But might not be lacking by the time of the next hardware revision. They clearly saw a good reason to have a method for current customers to upgrade. I'm thinking by the time the C5 customers are ready to upgrade they will have a way. Again..it's a good way to keep someone on your platform. If you make them essentially start from scratch...much better chance they leave and go somewhere else.
Absolutely correct.
I think this is really the biggest issue with HE right now. Its a solid platform but far from user friendly and unless you have experience with platforms that are more hands on like Homeseer, Vera or ST, people will have a harder time embracing the platform. Even things like not having a mobile app, while if this is better/worse then the web interface is debatable, but most all other platforms have this and everyone is already used to mobile apps.
If you make them essentially start from scratch...much better chance they leave and go somewhere else.
Which is what I'm doing. Instead of getting the new smartthings hub, if I'm going to be re-pairing/recreating everything anyways, I'll just try something else. I'm migrating to hubitat mainly for the local processing, but I would be less inclined if I didn't have to re-pair all my devices when upgrading my smartthings hub...
Exactly. HE is not perfect and it's also new and growing. I've had my frustrations here...but I do believe in the team working on it. The big thing is they seem to care about the frustrations of users. I'm willing to be patient...as long as progress continues. If it continues to improve and the advancements get better...I'll be here to stay. Especially if upgrades are smooth and things just work. When I first started with HE my automations were terrible. I had lots of zwave problems that were inherent to how HE works. I believe the HE team does watch and see all of that...and continue to attempt to make the product more stable. After I manually fixed my zwave problems..things got better. I'm betting on this platform for the future and I hope I'm not wrong.
Don't forget the network key too.
At a minimum that along with a copy of the node address table I believe are the minimum requirements for such a move.
Thanks..
I haven't looked for tools as I said, but I thought the na table would rebuild if empty. But I did forget about the network key.
I'm sure the address table can be repopulated as nodes check in, but without it, the hub has no way to contact any devices.
I've already backed up my network keys, just in case...
I decided to do two mins of research on 'Zigbee tools' and of course found x-ctu for XBee and this advice:
"the Preferred ways to change a coordinator. That is simply issue a Global network reset (ATNR1) on a local node."
and this recipe:
- Powered off the old coordinator.
- Set identical PAN ID on the new coordinator.
- Issued an ATNR1 command from a connected router on the network.
It assumes that the new coordinator is already paired to the Zigbee network and I read it as a form of 'promoting to primary'. I don't think I'll be getting an XBee for my 7 node Zigbee network. But it doesn't sound like a hard bit of scripting.