Another C4 to C7 migration question!

[juju]

I am planning to migrate from c4 to a new c7, but confused with the items below. Could use some insights. I have only zwave devices - no zigbee.

1. I don't mind recreating all my rules. Will that change the process of migration in any way? Most of my rules are setup on the old legacy rule machine and I had been planning to redo them using the newer rule machine.

2. I'd like to setup a hub mesh between the c4 and c7, and use the c4 for other things in the future. Do i setup a mesh first, before doing the migration?

3. Also confused about accessing each hub - is there a centralized dashboard / mesh interface where you see both c4 and c7 listed for management? Or do i get to each node using its own ip address? Does "meshing" provide some sort of centralized management plane ?

4. I am really dreading this move. I can't wrap my mind around going around each zwave device to reset and redo paring. I will have to dig up the manufacturers instruction for each of them. Isn't there an easier way to do this ?

[erktrek]

Check this out,..

Migrating a Z-Wave Network

Some people are going to find reasons to migrate a Z-Wave network by hand from one Hubitat Elevation hub to another one. There are steps you can take that will make this a little bit easier than just starting over. In particular, one wants to preserve automations that use Z-Wave devices, and not have to redo them. This would useful for migrating from a C-4 to a C-7. For C-5 to C-7, one can use the Hub Protection Service and avoid all of this work. First of all, familiarize yourself with thi…

[thebearmay]

1. If you take a back up of the C4 and restore it the the C7 the rules should come across but will need to be relinked with the new devices.
2. Can't setup the mesh until both hubs are up
3. Each node is managed separately but you can manage shared devices from either (except for delete/adds).

[csteele]

@juju

Also confused about accessing each hub - is there a centralized dashboard / mesh interface where you see both c4 and c7 listed for management? Or do i get to each node using its own ip address? Does "meshing" provide some sort of centralized management plane ?

Yes, interconnected hubs such as via Hub Mesh, is the answer. You mirror devices on one hub to the other and those devices go into your dashboard.

[juju]

I have seen that - supposes I didn't want to redo my automations. But I want to redo my automations as stated in my post.

[juju]

regarding # 1 - my question was, what if i wanted to redo my rules ? will that change anything in the process ?

[thebearmay]

You'll only be able to create new rules using the current RM, but should be able to edit the old rules in their creation version I believe.

[erktrek]

Sorry misread your earlier post ... Sounds like you want to do a straight up installation which is fine..

Yes you will have to exclude and re-include all your devices but that can be done from the new hub as long as the old one is off. I agree it's a pain to figure out the pairing/exclusion/factory reset process of different types of devices - this is one of the reasons I like to standardize on a particular vendor if possible - in my case "Zooz" for the toggle style switches.

In terms of HubMesh you can do that at any point so no worries there. Probably after everything has been done.. I have a C-5 I am using for my cloud/network devices and for exposing selected devices/device groups from my other hubs to Alexa.

For my setup I use Node-RED running on a separate server for all my rules... migration for me is just setting up a new hub and editing the sequences (rules). I would still use the migration service for C-5+ migration though to get the device pairings moved over. For the C-4 migration you have to do it manually but as mentioned should be able to do everything on the new hub.

[juju]

So it seems the process of migration from the c4 to c7 wont be any easier, regardless of whether I want to redo all my automations or not. I will still have to take a backup of the c4 and restore on the c7 etc ...

I am planning to look closely at node-red too - to help with ip control of my hegel and yamaha amps and a few other things. Does this mean you are not using rule machine at all? All your automations are in node-red exclusively? What server do you have it running on?

[erktrek]

Yes that is correct - I moved all my rules automations over to NR.. I like having greater control over my environment (memory/storage/processing power) and that it reduces overhead on my hubs - mostly no apps except groups and a few others.

I am currently running on a Raspbery PI 4 but you can also run it in Docker or a VM. Also am running Homebridge... It's definitely worth playing around with. The good news is you don't really have to commit - can run it alongside whatever else you are doing and it won't impact things. Also I think for simpler installations something like NR is overkill.

[csteele]

I run Node-Red on an always-on Mac Mini that was first built to be my Media Server. It has plenty of spare leftover power and running a handful of NodeJS apps (like NodeRed and Homebridge) doesn't tax it in any way. That's not a surprise given that Node-Red is most often deployed on RaspberryPi's. In fact, I started there too. After getting it running on a rPi, I was able to determine that it would be a useful part of my "distributed/parallel home automation system" and I moved it to the Mac Mini.

I continue to distribute rules across all my components. A lot of them are in Node-Red but I've also left a lot on Rule Machine because some Rules are more ideally suited to be 100% on the Hub that has all the actual connections. A Door Sensor that turns on a Light always, no If's, I'll happily leave in RM. Rules where the Z-Devices are on different hubs will need a "between" function. HubMesh, HubConnect and Node-Red all are able to solve this. I have reduced the number of RM rules that cross hubs and let Node-Red handle it. A lot of it is the copy/paste simplicity of Node-Red that drives this for me these days... I've already got a flow in Node-Red for the kinds of things that Simple Automation would do for me today. I can copy/paste one in Node-Red in a fraction of the time it would take in RM or any of it's derivatives.

In other words, once you use Node-Red and have enough of an understanding, you then can determine if it needs to augment or replace. I've landed (so far) on the augment side of the choice.

[juju]

@csteele @erktrek thx for pointing me towards node-red. I have a proxmox server and can spin up a vm to accomodate this. Just to tinker. I will hit both of you up for tips when I spin up the vm , if you dont mind. For instance, I have a vm running homebride now. But I see others with a homebridge app in hubitat - not sure what the difference is.

But for now, I'd like to nail down the process of onboarding the c7. I have it up and running now and the mesh setup. But I haven't uploaded the c4 back yet, because the process of redoing all the zwave pairing just intimidates me. Since I am going to redo my rules, how can i simply move over the devices ( without the rules ) ?

[csteele]

Homebridge is yet another in the long line of "bridge" tools. It is a product that sits in the middle of all the components that can't attach directly to Apple's Homekit architecture. SmartThings, HomeAssistant, cars, refrigerators, etc. all can use their own Homebridge Plug-In to become a device that gets reflected into HomeKit. There's a couple of Plug-In options for Homebridge on Hubitat allowing Hubitat devices to be seen in HomeKit and via virtual devices, get HomeKit device info into Hubitat.

[scottgu3]

I don't know if this will be helpful to you or not, but I used a method for migrating my C4 Zwave devices to 2 C7's that's a bit different than what @bravenel suggested. It works for me, but it may not help you.

I actually have 4 hubs, instead of the 2 you are considering, however the princiiple is the same, and you touch on the method in your questions 1 and 2.

The first thing I did was install my new hub in it's permanent location, and then turned on Hub Mesh on both my old hub and new hub, and shared all my devices from my old hub to my new hub.

Then, I rewrote all my rules on my new hub, using the Hub Mesh devices. I disabled and removed each old rule from the old hub. This reduced the overall workload on the old hub, and I reduced this further by moving my Sonos and Hue integrations onto the new hub.

Once that was done, I began moving Zwave devices from my old hub to my new hub, by using sound mesh building principles and starting with a new repeater installed right next to the new hub, and then moving outward. Fortunately, I had placed the first of the new C7s a distance from my old C4. This allowed me to build a new mesh by taking devices furthest from my C4 out of it's mesh, allowing me to build the new C7s mesh over time without massive disruption to my C4 Zwave network.

The trick of this technique, is that when you remove the devices from the original Hubitat, the Mesh marks them "offlline". When I subsequently added the devices to the new Hub, I named the devices very close to the same name as previously (Usually with a room prefix), and then by using the device details tab of each "Offline" device, I clicked on the rule(s) that device was used in, and replaced the "offline" device with the device on the new Hub.

Once all the "used by" links were gone, I deleted the "offline" device from the mesh, and moved to the next device or devices.

This way, I was able to transition my devices, at my own pace without breaking a lot of things for more than a few moments.

In my case, I already had all my rules running on a C5, and I'm transitioning my devices off my C4 to the two C7s at opposite ends of the house, gradually eliminating the C4 from the equation. But 2, hubs, 4 hubs or 7 hubs, the technique should be similar.

It really means I don't have to move everything at once!

S.

[juju]

@scottgu3

when you remove the devices from the original Hubitat, the Mesh marks them "offlline". When I subsequently added the devices to the new Hub, I named the devices very close to the same name as previously (Usually with a room prefix), and then by using the device details tab of each "Offline" device, I clicked on the rule(s) that device was used in, and replaced the "offline" device with the device on the new Hub.

@scottgu3 thanks for the detailed write up. This seems to be more in line with what I was looking to do - create new rules, instead of migrating everything from the old with a backup.
However, I got lost at the paragraph above. How are you removing the devices from the old and adding to the new? A simple zwave exclusion / inclusion without any device resets etc? can you elaborate a bit? This is great. thx

[scottgu3]

You are exactly correct.

I exclude the device from HUB-1, and then included it as a new device on HUB-2. No device resets (normally), although you may find it necessary in some cases. So far, this has proven to be really easy -- much easier for me than editing device IDs!

Scott

[juju]

@scottgu3 your solution seems to be working for me. Moved a couple devices so far. Will complete the move over a couple days then on to node-red tinkering!

[juju]

@csteele @erktrek - Thanks to @scottgu3 , I managed to transition to the c7 and rebuild my rules quite easily. And thanks to @thebearmay , i have a driver to control my hegel amp. Now, I have a new Yamaha receiver ( RX-A6A ). Looking to integrate it into my hub. I see there were previous attempts to develop a driver for it but was stopped. I just found a node-red implementation for yamaha amp and thought it will be a great way to get started on learning node-red with hubitat. Perhaps I should open a new thread and start the discussions there , but wanted to share the link and see what you think ?

https://github.com/PSeitz/yamaha-nodejs

Would really have been great to have a driver for the yamaha just like is available for denon and other receivers here. But seems like a massive undertaking , so perhaps the node-red route is easier?

[erktrek]

Yes that sounds like a great way to get into Node-RED. The nodes for musiccast currently seem more mature than the drivers here.

The good news is with NR you don't really have to commit to anything other than installing a Maker Instance in HE and have a server available - raspberry pi or any computer/vm/docker etc. Worst case is you shift back to using HE so no fuss no muss!

If you need help feel free to start a new thread and we'll be happy to assist or pm me whatever!

Note: I do not have experience with the Yamaha stuff but can definitely help on the NR side of things.

[juju]

@erktrek

Note: I do not have experience with the Yamaha stuff but can definitely help on the NR side of things.

I will start a new thread. But it just occurred to me that another route to go is to use the http post capability of RM . I just need to know if the amp is on or off, and toggle power , and change inputs. Thats it! But will do the node-red route just to learn. Thxx