Addind a second hub and moving some zigbee devices-best practice

Hi I just put online my second hubitat !. I have linked them together using hub mesh..
I mostly decided for the second hub to add reliability and reduce the distance to zigbee devices.
I run critical piston in webcore for water and smoke detection.

  1. to move a zigbee device to the new (close by) hub I have to remove it from the main hub and add it to the new hub. That is going to create a mess in any app linked to the device. Is there a better way to move a zigbee device?
    2)I have few webcore pistons running in the main hub (15+). Should I move some pistons to the new hub? or leave them only in the main hub? I don't see any signs of cpu overload so far in the main hub. I have seem the log statistics but those numbers don't mean much to me I don't know what are the limits (ie: [webCoRE] 430,835ms is that ok?)
    3)If I have the option to create the same routine in rule machine or in webcore. Is it one easier on the hub than the other? or it doesn't matter? I am more comfortable with webcore pistons if it's the same for the hub.

Thank you very much I'd appreciate some directions

Maybe: you don't actually have to remove it from the first hub first. You can just reset the device, then pair it to the second hub. That way, it will still be around (but not functional), and you can swap out the original device with the Hub Mesh device at your convenience without breaking any apps that might freak out about deleted devices in the meantime.

The Settings > Swap Apps Device feature could also help with something like this. I seem to remember this not working with Hub Mesh devices in the past, but they are showing up for me now, so I may have been thinking about something else (you don't need it to swap two Hub Mesh devices with each other--that can be done in Hub Mesh itself...not sure if it was that?). If that works for you, it would save the need to manually swap the old Zigbee device with the new Hub Mesh device. Otherwise, the "old fashioned" manual method is certainly always an option.

I'd say whatever is easiest for you or suits your preferences best, unless you see some reason to do otherwise. Maybe you only want to set up webCoRE on one hub, or maybe you want to keep apps and devices on the same hub as much as possible. Either way can theoretically work.

Regarding the App Stats you reference, I don't know what particular statistic you provided, so it's hard to comment, but in general, you're probably OK if you don't notice performance issues on the hub (what these exist to troubleshoot in the first place) or, if you want to be proactive, nothing stands out extraordinarily (high percent of total is probably one of the most general stats, but again, there are no hard and fast rules for what's "high"--though FWIW, everything I checked just now for me was mostly well under 1%).

Rule Machine is generally probably more efficient, but how much that difference affects real use may not actually matter. (Again, if you do notice problems, App Stats is one place you can start checking.) The most efficient option is generally a purpose-built app, so I'd consider things like Notifications or even Basic Rule first if they meet your needs before either of these -- but lots of people use webCoRE with success on Hubitat, so you won't be alone. Its current de facto maintainer for Hubitat has done a good job at making it more efficient, and the warnings you see from a few years ago suggesting to avoid its use entirely or risk slowdowns, lack of support, etc. are generally no longer applicable (though Hubitat does not officially support custom apps, so it's still technically on you, whereas they can fix problems with Rule Machine ... though there's no fixing the fact that either allows you to create arbitrarily complex automations with the ability to impair your hub if you design things poorly :slight_smile: ).

1 Like

Thank you very much for your prompt replay
I'd definitely try the "reset device" and "swap app device" option.

When you mentioned "high percent of total" where do you find that value? here is a pic of my app stats and it looks that action tiles are taking most of it (but again it could be normal)

I hope hubitat doesn't decide to eliminate webcore one day it was one of the many reasons I left ST very disappointed.

ones again thank you very much for your help

It's the "% of total" column you see in the screenshot you provided. I don't use ActionTiles much anymore, but it being kind of high might be normal if you have lots of devices--it probably subscribes to all events (thus waking the app whenever anything happens, running its code) so it can always update the dashboard. If you aren't noticing any problems, I wouldn't be worried.

That would be diffcult for them to do--if and when you update your hub is up to you (though it's generally recommended to stay up to date, especially if you want help troubleshooting), so if it works now, there's no reason it won't keep working -- especially if you use a local webCoRE Dashboard, as the cloud option is out of both your and Hubitat's control, though I've seen no sign of that disappearing even though it originated on ST and that will soon be out the window there.

Thank you very much ! I am happy to report that I just successfully moved one old water sensor from the old ( distance ) hub to the new one. Like you said I reseted the device with out removing it from the hub. them I added it into the new hub. Enabled hub mesh and I could see it on the old hub.( I used a similar name)
I recorded all the places where this sensor was used including webcore pistons. Finally i used "swap app device" function and it replaced in all the location including rule machine, notification, HSM and webcore.. including inside the pistons (witch I was not expecting that to happen).
The swap option worked fine. It was a bit scared as it doesn't report where it changed it just did it.
In webcore I had to open settings, available devices page, and save it again to refresh that was all.
I hope this helps to other people as well.
Thank you very much for your help

2 Likes