I know it's kind of the same thread over and over
I just order a hubitat C5, should arrive soon
I just wanted to see what others have done when they migrated from ST to HE
i have mainly some zigbee devices (iris motion sensors, iris contact sensors, samsung leak sensors, samsung buttons, peanut plugs) along with hue bulbs (bunch of them using the hub bridge) linked to ST via the Hue B smart App. I also have some Zwave devices: Ecolink tilt sensor and few zooz switches
I read that some people use other hub bridge app. is there a way to exclude zigbee devices on ST IDE or app or I have to do it based on each brand/device
I think I know how to exclude the zooz (3 tap), I need to read how to do it on the ecolink tilt sensor
As far as Hue B Smart app, I believe there is a version that works for Hubitat so that will be good to have
Thanks for your inputs
Go slow, go use case by use case. (This controls that). Make sure it works solid.
Then Move on.
That has been confirmed by staff as not a great idea on Hubitat.
The official word is that Hue bulbs and some others don't act as good repeaters.
I had one on the outside of my network where it wouldn't be a repeater so I was fine, but if they're in the middle of the house, they could cause problems.
Sengled is supposed to play nice, so I'll find out soon now.
Search the forms, feel free to ask questions!
Welcome!
I heard hue bulbers are repeaters only in their own mesh (with hue bridge) that's why I want to link hubitat to hue via the hue smart b app. so you're saying this isn't a good thing to do?
all my smart bulbs are hue, most of them color. I can't change my whole set up too. why it's not a good idea on hubitat? because it involves cloud etc..?
Running hue bulbs on the hue bridge is the recommended way of integrating them with hubitat.
Just to say - even if it’s not the correct way - I have 14 hue G10 bulbs spread across my apartment in various places and have them connected directly without the bridge, and it’s working perfectly (so far!)
This may not be an issue if they are your only zigbee devices. You will probably start running into problems when/if you have a lot of other zigbee devices that need to route through the Hue bulbs. As others have said, hue bulbs are not great repeaters for many other non-Hue zigbee devices.
Well I’m using loads of zigbee socket switches, temperature sensors, contact sensors and motion sensors as well.
I guess maybe sometimes it’s just luck but everything is working well so far
As with any mesh, your mileage may vary. But many others have claimed the same previously until something like an extended power outage caused a mesh rebuild and certain zigbee devices don't play nice anymore. It's less of a directive and more of a word of caution (best practice if you will). Adding Hue (and quite a few other zigbee bulbs) directly to HE and ST hubs is somewhat like building your house on the sand.
So it's good to link hue Bridge to hubitat. Maybe the other person means just using that Hue B smart app isn't ideal?
I do like that app because I have probably 50+ hue bulbs and when adding hue Bridge to ST (official Way) every single bulb is added as a thing so it makes the list so long. With the Hue B smart app my hue rooms are added as a thing so the list is way shorter, even hue scenes can be added as a thing
I'm not sure how hubitat behaves when its linked to Hue
As far as adding hue bulbs directly to hubitat. I don't think I'm ready to go for such huge gambling. I have 50+ bulbs and I need to reset each one of them from hue Bridge. Definitely not ready for that
Yes, the recommended method is to link the Hue hub to HE. I believe there is a ported version of the Hue B Smart app as well but there were initial problems with how it interacted with Hubitat. I think @halfrican.ak can shed light on Hue B Smart and how it compares to the native integration.
Native integration is fastest and most reliable. Hue B Smart port has some random lag that's very annoying. I'm currently using stock integration.
The Hue B Smart app is local, just as the native Hue integration is local. I tried it on my test hub (I'm one of those weirdos) and didn't notice huge problems except slightly different behavior from the native integration that caused problems in some of my automations (e.g., a level of "0" was not necessarily a switch state of "off"). It's also third-party code that is unlikely to be as well tested as the native integration (nothing against the original author or the person who ported it; just a general recommendation to use native apps unless you require something specific they can't do--in this case, accessing scenes set up on the Hue Bridge, for example). I'm not sure if peoppe above thought you were pairing the bulbs directly to the hub, but that's the scenario I'd avoid with most smart bulbs due to their lousy behavior as repeaters on ZHA networks. You could certainly try Hue B Smart and switch to the native integration or vice versa if you don't like it, but you'll have to reconfigure your apps/automations to match the new devices.
To answer your other questions, I see you have a mix of ZigBee and Z-Wave devices. For ZigBee, you can usually just reset the device or put it in pair/join mode (in my experience often the same procedure for both) with the new hub. You can delete the device from the old hub at any time (or not if you don't care to clean it up). Z-Wave is a bit pickier. My recommendation would be to politely remove/exclude it from your current hub. If there's a separate "reset" procedure, I'd recommend that too. Then, put it in pairing/inclusion mode on the new hub. You'll likely need to look in the manuals for the devices to figure out how this works. If you've already force-deleted it from the old hub, a device reset might be enough, but you can also use any hub (ST or Hubitat) or any controller (Minimote, Z-Stick, etc.) to perform a general exclusion.
If you don't have a ton of devices, you might be able to do this all at once. If you have more than about 20 Z-Wave devices, support recommends breaking them up into smaller chunks. Haven't heard anything like that for ZigBee, but in any case I'd recommend just joining one device at at a time (going out and back in between each) to make it eaieer to tell which is which if you have several of the same device.
In order to exclude the Ecolink Tilt Sensor:
Unfortunately, you have to remove the battery, wait 10 seconds, then put it back in again.
I hope that it's in a convenient place!
It also allows you to diversify your control points via the Hue app. That is useful in the rare event that your hub should fail. You will have a second way to control your Hue lights.
really? you can pair the zigbee device to another hub without resetting it from old hub? I thought a reset is necessary
any idea if the native integration adds the bulbs one by one, I don't have the hubitat hub yet so I don't know how it will behave, not sure if you can add rooms. in the ST hub the Hue B app the Hue rooms are considered a thing so it helps consolidate all the bulbs in just few rooms
What you can do and what you should do is often different. 
For both ZWave and Zigbee, you do not have to tell the old hub about the change. It wouldn't treat it much differently from running out of battery.
If you're planning on migrating off the old hub and just wiping it when you get that far, not informing the old hub isn't a terrible idea. You can use it as a reference if you need to remember how an automation was written, since the dead/missing devices are placeholders.
On the other hand, if you do that to a Hub you hope to use, it's going to leave a lot of Orphans/Ghosts that will cause performance issues.
Did you mean "removing" rather than "resetting"? Removing is probably the safest option, but you don't need to--you just need to reset/(re-)pair the device on the new hub. The old hub won't "find" or "steal" the device back unless you have both in pairing mode at the same time. (This is actually handy if you move devices back and forth between hubs. I recently temporarily moved my ST 2018 button off of Hubitat to ST for a firmware update, then moved it back to Hubitat with all my automations intact because I didn't have to delete the Hubitat device.)
Z-Wave devices do need to be excluded from the old network before they will join a new one. The easiest way to do that is to do a normal exclusion using the old hub. On ST, this is the "Remove" button, and I say it's "easy" because it's clear from the UI (the dialog will go away) when it's successfully excluded. If you do a "Force Remove," which it will offer after a bit if a regular remove is unsuccessful, you'll only delete the device from ST's Z-Wave database but the device itself will still need to be either reset or have a general exclusion (doable from any hub/controller) done on it--or in the case of (at least) old GE devices, both--which you can also do if your ST hub isn't available at the moment.
In any case, unless the old device is "politely" (or forecefully for Z-Wave, with different concerns) removed from the hub, the old hub will still think its there. As @csteele mentions, this may cause problems, though if I had any "ghost" devices on ST I suspect they were the least of my problems. 
When you first set up the Hue integration (as well as any time after), it lets you choose indivudal "lights/bulbs" or "groups," the latter of which roughly corresponds to rooms in the Hue 2.0 app. You can go in at any time and add ones you did not originally add (have added to Hue since setting up the initial integration or have removed from Hubitat but want back, etc.). Support Hue scenes is the one thing I miss from this integration ("scenes" as configured in the Hue app; Hubitat has its own scene implementation you can certainly include Hue bulbs in, but if you use individual Hue bulbs rather than groups, you'll likely get some "popcorn effect"; I'm so used to it by now I honestly can't tell you if I've noticed; directly paired bulbs--one advantage here--have the ability to use ZigBee group messaging).
So you're saying. No need to go to ST hub and remove the devices. Just reset the zigbee device (depending on the brand) then go to hubitat hub and pair it, that way it will belong to hubitat, it will still be listed in the ST hub but not connected
In case I need firmware update of a Samsung button for example, do the above but on the ST Hub just to update firmware then repeat above again to pair it back with hubitat
Exactly! Though if you don't have a reason to keep the device on ST (e.g., referencing automations you made with it as you set up Hubitat), you might as well delete it--ST doesn't need any help misbehaving, and keeping "ghost" devices on it probably won't make it better. But what you describe is exactly what I've done on Hubitat. I moved several of my ZigBee devices to ST to get firmware updates (including the new ST Button because some people reported problems with it registering more than one press after being dormant for a while on the original firmware--and very recently my Zen Thermostat under the hopes that firmware v2.31 would fix issues I have with it reporting "54.9" when I set it to "55" and whatnot, which, FYI, it didn't fix). Then all you have to do is remove the devices from ST (or not, I guess, but might as well) and re-join them to Hubitat, and all your automations will still be intact!
Note that this only applies to ZigBee, as they have a factory-assigned device ID (plus a shorter identifier assigned by, or at least communicated to, the hub, which will probably change when you reset and re-join it, but Hubitat will automatically update it and there shouldn't be any problems). Z-Wave, as far as my limited knowledge is aware, has just a node ID assigned by the controller, and I don't think Hubitat has the ability to "replace" one node with another (I seem to remember seeing something that looked like it could do that in ST, but I never tried). Then again, I don't think ST does OTA updates of Z-Wave devices, so I've never had a reason to try something like that anyway.
