One thing you can do it prep is make sure all of your devices are compatible with HE, either natively or using a community-based driver. Chances are you'll be fine. The only thing that caught me was my Lutron Caseta switches, which on HE require the PRO version of the Lutron hub.
@user2228 Also look at this prior to migration. Some of it may save you headaches. Especially the stuff in the z-wave section.
3 Likes
Another resource is the Hubitat tutorials. I found them to be helpful. There is one entitled Beginners' Guide to Switching to Hubitat Elevation.
Welcome to the Community. I switched from SmartThings 2 years ago and I am glad I did.
5 Likes
Thank you all. Lots to take in but I think this is the best option going forward.
3 Likes
I jumped over from ST a couple years ago -- welcome to HE!
First researching your existing device compatibility is a good idea -- that gives you the luxury of time to address any compatibility issues instead of discovering it mid-implementation and forcing yourself into a hurried fix. Then read the recommended stuff about building solid ZW and ZB meshes.
Setting up & managing ZW devices on HE tends to be more finicky / less-forgiving compared to ST -- the "why" a long story, but in terms of prepping your conversion gameplan ahead of time, pay particular attention to z-wave related best-practices. That planning & prep helped me a lot, and I didn't have any issues bringing my stuff over.
I know it seems daunting to do a whole "do-over" as part of any conversion, but it's also a good opportunity to optimize things from the ground up -- after all, you're smarter on this stuff now than when you first started -- take advantage of that 
2 Likes
I one thing I would add is don't be afraid to use Smartthings as a cloud integrator. There are two great ways for bringing things in from Smartthings into HE that use the new Smartthings API. I use HE as my primary HA system, but do lean on Smartthings mainly for cloud integrations that just exist in HE.
The methods are:
- A driver is written to poll the Smartthings API and then populate the device in HE or send the command to Smartthings. This has been primarily setup for appliances so far, but has allot of potential to expand to pretty much anything. It can be located at Drivers for Samsung Appliances controlled via SmartThings Cloud API -
Custom Apps and Drivers - Hubitat
- A always on PC(even a raspberry pi will work) with Node-Red using the Hubitat and Smartthings Automation Studio Pallets. This combination if setup properly can event use event triggers from Smartthings to get near instant notification of events and not use polling. Here is the thread I created discussing this method. Node Red with Smarthings using Samsung Automation Studio -
Get Help / Integrations - Hubitat
I have Node-Red with the suggested pallets above setup to manage integration with Arlo Cameras as my example. I wouldn't do this for anything that can integrate directly with HE, but it is a decent solution for things that aren't supported in HE but work in Smartthings.
One last question folks. Now I know ( think ) everything runs local on Hubitat? Is that true?
Does this even include community made drivers for devices that are not natively supported by Hubitat?
And if everything runs local, does that mean that if anything were to happen to Hubitat ( an outage there end, or worst case, they close shop) everything would still run in my home?
Thank you.
1 Like
Community-made drivers for zigbee/z-wave devices run locally on the hub. Community-made drivers for locally-controlled WiFi devices are also not internet dependent. Community-made drivers for cloud-connected devices are cloud dependent.
Cloud integrations would stop working (eg. built-in integrations for Alexa, GH, ecobee). However, everything else would remain working as it was before.
2 Likes
This is true except for third party cloud-based services (Alexa, Ecobee, etc).
1 Like
Thank you guys. Yeah I assumed things like Alexa etc would stop working but lovely to hear the rest all run local regardless.
2 Likes
I think there may need to be a distinction made to about services that use Hubitat's cloud to interface with external cloud tools vs cloud connections between the hub and lets say Govee's cloud. I think there is even a community google home integration that i wonder if it would work if hubitats systems were down.
So given that I have all of my devices currently on ST. Before I go through the tedious job of unpairing everything , is there a way to go through Hubitat and start making my rules and automations without pairing them just now, leaving them on ST so things still work just now, whilst I make all of my automations on Hubitat? I suspect the answer is no but I part of me hopes I could set them all up prior and them just go back into them once paired to Hubitat and insert devices into the rules.
You can create virtual devices and create rules using those devices. Then, after resetting the actual devices and pairing them to Hubitat, you can swap them with the virtual ones.
2 Likes
Yeah that was my thinking. Thanks.
All the virtual devices have buttons to simulate an action or to set a value, so you can easily debug your automations in Hubitat without the actual devices.
"Swap Apps Device" is in the Settings menu on the left.
2 Likes
Sorry folks I know I’m being a pest here but rather than me starting a new thread I figured I’d post here because I’m trying to weigh up the pros and cons from moving to ST to Hubitat.
As I want to make everything run local as much as I can, one thing I can’t figure out is, is there a way to change the status of a mode automatically if there is no internet. So with ST I use me and my wife’s mobile phone through life 360 as a presence sensor to switch from away to home when we arrive, but if the internet happens to be down at this time then this won’t change, which can be a disaster as thing will run when we get home because ST still thinks we’re in away mode and there’s no way to change this during internet down.
What’s the best way to tackle this with Hubitat, is it possible to still use mobile presence this way even if internet is down?
Thank you.
No, because presence from the mobile app is internet dependent.
That being said, you can aggregate presence from multiple inputs, such as connecting to your WiFi network, using a particular lock code, disarming the alarm with a specific code etc etc
All of the options make establishment of presence independent of a geofence event.
3 Likes
Ah yes makes sense. 
So how could you have the mode change by connecting to your wifi if said internet was down? This seems a really good way to fully automate rather than having to input codes etc but fail to see how that work work.
Thanks.
EDIT.
Or rather , let me ask. What way are you all changing modes from when your out to when your home? I assume most folk here are wanting to make this local too.
1 Like
Welcome aboard. Great questions, keep them coming, is better to prepare ahead, instead of trying to sort out the problems you may face for the lack of planning.
I remember the days when modes were stuck one way in the cloud, and one way locally. Those weren't fun days, to say the least. With Hubitat, that will never happen, because we don't have to keep the local hub syncronized with a virtual hub running in the cloud, which most cloud based platforms must do.
As @aaiyar mentioned above, even if the cloud presence fails to change the mode because the hub has no internet, Hubitat offers countless ways to recover. You can use a button, a contact sensor, a switch, a virtual presence that can be triggered from the hub's local interface or a rule to change the mode in absence of a cloud dependent presence sensor.
3 Likes
I use the wifi presence method @aaiyar describes. It requires a bit of tweaking because iPhones have a habit of dropping wifi to conserve power but I’ve never had a false positive - in other words if wifi presence says you’re there, you really are. It does not require internet but it does require a network connection.
4 Likes
