When you say synchronizes devices. Does it mean that one device can be controlled from both Hubitat and ST both way?
The other question. Will you have Harmony and Ecobee support any time soon?
Thank you!
Kevin's solution creates virtual devices in ST for every device in Hubitat. But every device in ST is NOT created in Hubitat, though that should be possible. Once ST has the virtual devices, updates are sent from Hubitat to ST and ST to Hubitat. So you can control things from ST in Hubitat.
I will leave that to the Hubitat staff to answer that. @bravenel @mike.maxwell @bobbyD should be able to answer.
1 Like
Since Hubitat is mostly local you probably wanna have it as primary.
If Smartthings doesn’t have internet their virtual switches are in the cloud and nothing will work.
If Hubitat doesn’t have internet, local automation still works only smarttings connection will be down.
2 Likes
I’m actually moving all my already local automations from smartthings to Hubitat.
In Smartthings I’m leaving cloud solutions like Cameras, Ecobee, Skybell, Samsung vacuum…
because if the cloud doesn’t have internet anything works anyway.
There is also huge benefits of Hubitat backup
and Smartthings are preparing big switch to Samsung accounts
and that didn’t go well in the last beta, I can handle fix couple of disconnected clouds but over hundred local devices malfunctioning will be difficult to WAF
1 Like
Where can I find the app for this?
1 Like
Links to everything are on the Wiki:
I had the exact same experience.
A reboot and a bit of time to let the subsequent boot complete resolved the issue for me.
Another issue I faced was around Zigbee devices not pairing easily. For this one, I just had to follow the oft mentioned guideline of having the hub to device distance less then ~5 feet, to have the device pair successfully.
Great job Hubitat guys! Impressed with how well the first iteration of your product works 
Would love to contribute and support this platform to grow much more!
P.S: Has anyone exposed the Hub externally (outside the LAN) via port forwarding or from behind a VPN?
Were there any issues faced in the process?
1 Like
Please do not port forward your hub. VPN access is the best way to access it remotely for now.
Thanks for clarifying that 
I too realized the same after discovering that there is no password protection for accessing the Hub built in.
I am.
I joined my shiny new Hubitat to my existing ZWave network and all my devices show in Hubitat.
But it was using a technique not everyone will want to try. I have a large bundle of Hope that the Hubitat Team will include the technique I used in some future release.
Could you share your technique?
I’m just wondering how you early adopters of this product are getting on.
Is it proving reliable for the devices you have connected?
Are there devices you cannot connect yet?
Are you finding the ‘Rule Machine’ adequate for your needs?
Just how things are going in general.
I’m in the UK where it hasn’t been released yet but the idea of local processing really appeals to me.
I’m the earliest of early adopters – Ha! Been running Hubitat in my own home for over a year. 200+ devices, 150+ apps, including 55 rules. Now, obviously I’m partial to it, but I can honestly tell you that my wife’s whole attitude went from negative to positive when I moved the house to Hubitat.
Our UK release will happen during the first week of March. Stay tuned!
4 Likes
Thanks for the reply.
Here is a question for you.
I currently use some Lightwave Rf devices integrated into ST.
This is done with a Smartapp that sends commands through my ST hub over my LAN to a Raspberry Pi which then forwards the commands over the same LAN to the LightwaveRF hub.
In principle do you think this could be achieved with Hubitat?
In principle, yes. One of our early users ( @ogiewon) quickly got something similar working using Arduino, and he’s the sort to help out with this sort of thing. His Arduino stuff also came from ST.
1 Like
OK. Thanks. This is looking more and more appealing.
I have moved all 70+ devices over. They are a combination of lights, fan controllers, door sensors, temp sensors and a thermostat. They are also a variety of Lutron, Zigbee and Z-wave. Everything works great and fast. I still use WebCore for a couple of complex expression comparisons and some HTTPS calls to outside vendors (e.g. my alarm company and my mattress which drives virtual switches. With the latest release I can now see those ST virtual switches (4 in all) in the Hubitat environment and use them in a few of my rules. The calls will migrate in as I figure out how to create the device drivers.
This is easily one of the best purchases I’ve ever made.
3 Likes
- functioning is about same like elsewhere
- no platform outages
- Configuration in web browser is just so much easier
- Local processing eliminates internet dependence.
- Looks like most early adopters here have 50+ devices
because with that many devices you cant handle manual control,
you need automation for everything. A side effect of that is:
a) more devices with fewer users = devices testing and adding go much faster
b) more experienced users = better bug reporting - Backup possibility
a) if hardware fails you can just upload backup and running without downtime
b) On another hub is eminent migration to different platform, in beta testing transfer didn’t go so well,
fixing more than 100 devices and many more automation rules after borked migration without backup
choice will be time intensive and wife will kill you in process
1 Like
Like the other answers given, I have 74 devices in Hubitat. However, I did my migration 100% in the opposite way. I joined my Hubitat to my existing Zwave network. All 74 of my devices are controllable from either/both SmartThings and Hubitat at the same time. The key word is ‘control’ - if I want to tell a switch to turn on or off, or automate those switches, either/both can do it. In fact that led to an amusing “failure” (amusing as in slap your forehead “OMG was I really that lost?”) in that I left a WebCore function running in ST while also coding a Rule on Hubitat in RM. I chose “a better” delay value in RM and was very frustrated when it kept shutting off “early.” Well, you already know the end to this story… halted the piston and it started working “as expected.”
For the down side to this method, all my “status only” devices, door/window sensors, motion, etc… devices that just sit there and have one job, to tell the controller something happened, they don’t tell Hubitat. How could they? When they got added to the ST ZWave network, the Hubitat wasn’t there. I had to go to each and then on Hubitat, start the Discover Devices process and then ‘kick’ the sensors into re-joining the network. Their ID number does not change in this process, it’s NOT an exclude/include cycle. They are still visible on ST. But now they send their status to Hubitat.
Let me give a more specific example… Aeon MultiSensor 6. I have a dozen of these that are used for motion and temperature. On ST there’s a DH that exposes the config registers of the Multisensor. I can set, for example, that the PIR resets after X seconds. Default is 4 mins, but for most of what I do, I want it in the 30 second range. That feature of being able to set the PIR Reset value does not (yet) exist in Hubitat’s DH. Therefore, if I want to set that value, I must use ST, but once that feature is added on Hubitat, I could set it from either. The motion and 5 other sensor values never show in Hubitat. Until I put Hubitat into Discover (Include mode) and click the button on the back of the MultiSensor (sometimes more than once to get it to go.) Almost right away, certainly within 2 mins, the status shows up in Hubitat. And most also send status to ST.
Now I can create Rules in RM that make use of the sensor values, and as mentioned, Pistons still work. My process is not better or worse than the Exclude/Include cycles everyone else is doing, it’s a lot of the same hassle… climb up, get the MultiSensor down, clicky stuff, climb up, put it back. The difference for me is that I have 4 Controllers, not one SmartThings. I have a Z-Stick and a Wink and a StaplesConnect all operating together to give me the home automation I think I need. Another example… my StaplesConnect was my first but it’s been “demoted” to being a Lutron Hub. About the only task it still does is receive Lutron Pico button pushes and via it’s rules, turn on and off stuff. I won’t give up my Pico’s!! 
(I have a Lutron Hub Pro on it’s way.) My self imposed difficulty is that I have all those Controllers and Exclude/Include 4 times WOULD be worse. I have 4 of them to overcome the local/cloud issue and to support Automation that wasn’t possible any other way (on that day.) My Z-Stick is 100% local, always has been. My StaplesConnect has always been local. So for those things that are really really annoying via the cloud, I’ve already had a means to get it local.
Bottom line, overall, Hubitat is quite good. It’s still early adopter phase to me, and therefore I will not complain about what it’s not. We’re all seeing both early bugs and far more important, fixes. Hubitat will, allow me to shut Wink, StaplesConnect and maybe my Z-Stick. I’ll end up just like “you” with two. SmartThings + Hubitat.
My Z-Stick is run via OpenRemote software that is quite a challenge to use, but once you’re over the hurdle, is really effective in the WAF arena. Via OpenRemote I’ve created fully custom IOS interface to my home. Should anyone in the house need it, they can whip out their Phone and have an interface in which everything is “up front.” Having already invested in making that, it’s going to be hard to train family to use the Hubitat interface, too many clicks, so the Z-Stick seems like it will stay. Still, 3 Controllers is better than the 4 I had, 5 now with Hubitat joining my home.
4 Likes
