ya i just ordered a hubitat to start playing around with as I want a more stable “user configurable” system moving forward.
i have the impression that the webcore and rule machine replacesments is what their new automations are supposed to be, so if you are planning on sticking with ST start playing with them to get used to it.
I looked into Hubitat when leaving Wink, and didn’t go for them because what if Hubitat is the next Wink? Hubitat is a small company that could vanish tomorrow. Sure Hubitat runs almost entirely locally, but there are a bunch of things it relies on a connection for, like firmware updates, etc. Samsung is a huge diversified company that I don’t think will go anywhere anytime soon. I think the only other option was Home Assistant on a raspberry pi, which was truly local and all user supplied hardware, but very complex to setup. I think all of us posting on here are the exception though. The average smarthome user wants to plug something in and work, and just thinks its good enough to ask Alexa to turn a light on. There aren’t a ton of options for advanced smarthome functions left out there, and a long list of hubs that turned into bricks when the company folded or abandoned them.
how about open hab. i do have servers running in my locations and also some qnap nas that can run it in docker…
the rule engine looks sufficient and there is dual zwave zigbee hw available… i dont see much liike various apps etc though
One thing the new V3 app did NOT do was combine everything into one rules engine UI. 
there are still multiple ways in the new app to create what is essentially the same automation, although each way may offer somewhat different features. And, yes, it’s just as confusing as classic in that sense. 
For example, if you want to have a motion sensor event trigger a light, in the new app you could use:
a custom automation created by tapping the + in the upper right of the home screen
A new smart lighting automation created by tapping the three horizontal line icon in the upper left of the home screen, then choosing smart apps, then choosing smart lighting. (Not available in all regions)
a new SmartThings Home Monitor alert (I think you can, I haven’t checked to see if alert with lights is still available in the new app)
Use The rules API. This is the most Webcore-like option, and is still in development. But it’s the one that looks more like a scripting language. See:
And of course that’s not discussing writing your own smartapp.
So there’s a lot to learn if you want to learn it all. 
Open Hab seemed neat too, I think that can run on the PI as well? More complex to setup but I heard it had more app options. I’ve never used either though so only am going by the reviews.
The lack of a nice app on the phone was also a problem with some of these other systems. There’s people with different skill levels using these things in my house. So far, Smartthings has been a perfect blend of easy to use while still supporting more advanced features. I just really hope it stays that way and am not sure this will be the case after the full transition, loss of the classic app, and loss of the IDE. There’s a lot they just haven’t worked out yet.
Here are my thoughts on the state/fate of existing custom ST code. I believe there are a few categories of developers to consider, as follows.
I believe a lot of developers from the early days of SmartThings are long gone, even though many of their SmartApps and DTHs are still actively used by many in the ST Community. These SmartApps and DTHs are not being actively supported, and thus will die on the vine, once the Groovy IDE is shut down.
I believe there is another group of developers who worked really hard to get their Groovy code working properly, and who are not very enthusiastic about having to rewrite their code, as it may be quite a bit of work. Especially SmartApps, which will no longer be hosted on the ST Cloud infrastructure. These developers are unlikely to stand up their own AWS servers to allow ST Community members to continue to run these ‘New ST API’ based applications. Users may need to self-host these new SmartApps on their own local or cloud infrastructure. As for DTHs, those are still Groovy for now… but eventually that will change as well. With no officially announced roadmap for the future of hub-connected DTHs, these developers probably aren’t too enthusiastic right now, IMHO.
And then there is a group of developers whose business is based upon selling SmartApps and Device Type Handlers to ST Users. These are folks like SharpTools (@joshua_lyon) , ActionTiles (@625alex) , Konnected (@heythisisnate), RBoyApps (@RBoy), and @yvesracine’s Apps and DTHs . They have financial incentive to figure out how to work with the New ST API. As such, I believe this group of folks is highly motivated and will be successful in adopting the New ST API. For SharpTools and ActionTiles, they are already hosting most of their custom apps on existing Cloud Webservers. This means their web applications simply need to be changed to use the New ST API as opposed to the current Groovy SmartApps that provide their endpoint connectivity. For all I know, this work may have already been completed and the change is transparent to the end-users. I am pretty sure Konnected may already be using the New ST API, as I do not see where they are asking users to install Groovy SmartApps/DTHs any longer. It appears that Konnected now has its own Cloud Server (someone please correct me if this wrong.) As for @RBoy’s and @yvesracine’s products- I really don’t know what the likely solutions are for their offerings long-term. Both are talented and will most likely come up with something. Without a clear picture of what the future is of Hub-Connected device handlers will be after Groovy is gone, it is hard to predict the future.
The last group are the new Community Developers coming to the ST Platform today, who most likely will adopt the New ST API immediately. It will be very interesting to see how these Community Developers approach the design, distribution, and maintenance of their Apps/DTHs.
Again, the above is just my current take on the changing landscape of SmartThings from a community member’s perspective. I believe the SmartThings Team really does want to build a better platform. And I believe they will be successful in doing so. However, like all major changes, there will be some negative impacts along the way. The days of the ST Groovy Developers are numbered, based on official announcements from SmartThings. Sounds like it’ll be a little bumpy over the next year or two until the dust settles.
Has anybody found out yet whether there will be a way for an individual customer to create a virtual device, such as the ones used to trigger Alexa routines, under the new architecture? Will that require setting up as a developer?
Inquiring minds and all that…
Mostly correct. We’ve fully embraced the new SmartThings APIs and have set up a “serverless” cloud service built entirely on AWS Lambda and AWS IoT. It talks to SmartThings via the ST-Schema.
This is actually much better for the end-user because it removes the complexity of loading and updating custom code, and enables us to push updates centrally when we need to.
All I have seen recently is this acknowledgement by SmartThings…
As for this portion…
This one is a little tricky, eh? Since Alexa Routines cannot be triggered by a switch, these virtual devices actually need to either be a Motion or Contact sensor at this point in time. So, the virtual switches must have both the Switch Capability to allow SmartApps to change their state, as well as Motion or Contact sensor capabilities that are mapped to ‘on’ and ‘off’ to allow Alexa Routines to work. So, this would appear to be something that 99% of users would probably never try to use, but it is very important to the 1%. BTW - numerous posts that the New ST Alexa Skill has broken using Motion and Contact sensors as Alexa Routine triggers for some users…
I know Hubitat has embraced virtual devices, making them easy to change the state of them by adding additional commands to them which can be called by Rule Machine, or any custom App. For example, the Hubitat Virtual Motion Sensor includes the active() and inactive() commands. This allows the device to only implement a single capability, while still being able to be manipulated externally.
However, Amazon Alexa can only change Switches, Dimmers, Fans, Thermostats, etc… in Alexa Routines. It cannot change the state of a pure virtual motion or contact sensor. So, I wrote my own custom Hubitat Driver that implements both the Switch and Motion Capabilities to allow my Ring Doorbell to act as an Alexa Routine Trigger (via native Ring Skill) , which then turns on my custom Hubitat Switch/Motion device, which then allows Ring Doorbell “Motion” events to be used like any other motion sensor. The custom virtual Switch/Motion driver also automatically turns the switch state back to off after a few seconds, which causes the motion to go inactive as well.
While the above seems simple to you and I, to the other 99% of users, what I wrote above is gibberish. I wonder how much effort ST is going to put into making this much complexity work with the New Platform…
I am still curious who is going to update the Lutron, Logitech, etc. integrations… (if they have not been updated yet to use the New ST Platform.)
Thank you for the clarification, Nate! Sounds like a nice solution for the end-users!
If Hubitat vanishes tomorrow, then all of the hubs they’ve ever sold will continue to work. The hubs run totally independent of the parent company or it’s infrastructure.
If Samsung decides to stop supporting SmartThings hubs, then all the hubs they ever sold will stop working - with no hope of resurrecting them.
In fact, since SmartThings has said Groovy is going away next year, then every custom SmartApp and device handler will stop working next year when that happens, unless some developer rewrites them for the new API. I suspect much of the currently rich custom environment will vanish next year.
SmartThings could also decide to start charging for cloud usage (in a move similar to Wink).
(Background: I’ve been a SmartThings user since 2015. I’ve been a Hubitat user for 10 days).
ActionTiles has developed a POC integration with the new ST API last fall, but the API was not ready for production use at that time.
This work is now resumed. It’s a little bit more involved than “simply use the New API” because there’s a lot of auxiliary pieces that need to be updated. Also, at the scale that ActionTiles operates it’s a lot more expensive to host our own app.
The migration of ActionTiles will happen in the near future. There are no showstoppers at the moment.
I’m also a recent Hubitat migrant (not done yet, still have some ST hubs in operation).
Is is true that it will continue to work, though? The automations should, but what about the ability to access dashboards remotely via the mobile app? That seems to be going through their cloud.
That’s not to say Hubitat is a bad choice – I feel comfortable having moved.
So I looked in to HomeKit… Having already being heavily invested in the Apple eco-system I jumped the gun and bought an Aqara hub and G2H cam which was my first camera ever (Something i didnt imagine getting as ST user), both act as a hub so from there having almost all of my “Things” (40+) based of Xiaomi / AQARA / YEELIGHT I had the easiest and the smoothest transition I could ever imagine!
Right after pairing no DTH BS and no googling for troubleshooting everything apeared in Homekit by the time I finished pairing a device with one of the hubs (I didn’t even need to open the app to pair!)
Right after pairing I could start setting up automations and altho there wasnt really an option to overly complex automation I 1:1 duplicated my whole Smartthings setup in just shy of 6 hours (re-naming things, arranging into rooms, testing and playing around too)
Something I noticed imidiatly is the reaction speed of the Yeelight bulbs, something that takes few seconds on Smartthings (and sometimes straight up fails) is INSTANT in HomeKit!
being connected to my home wifi makes the “Home” app open and show status of every “Thing” in an instant! no matter how many items I had! something that really bothered me about the Smartthings app (Samsung connect especially) where even opening the app was slow and frustrating to me…
no matter what was my intention was I wanted to avoid opening it just because of load times that followed by EVEN MORE load times
I feel like the next step for me is buying a Pi0 and installing Home Bridge to port over things left on Smartthings, Like my local weather, virtual switches, few Zigbee outlets, a Samsung TV and a Samsung vacuum (which lost its ability to automate in one of the updates!!!).
My ultimate goal is to trash the Smartthings hubs, get rid of the app mess which are the Classic and Samsung connect respectively and with time (…) replace the Samsung branded devices with HomeKit compatible ones
Am I happy with HomeKit? No. it’s limited to say the least and doesnt offer a wide variety of product categories (i.e vacuums)
Will I recommend moving to HomeKit or even choosing it in the first place? If you already have a device that can act as a “Home hub”… i’d lean towards yes.
While not perfect and open source as SmartThings it just… works… and flawlessly while at it!
I will keep following the forums just to be up to date with the state of SmartThings and I want it to succeed even if i’m not on board…
(sorry for rambling)
edit: saw the announcement of IFTTT moving in to paid sub. service and if I woudve stayed here 4 automations I use on daily basis would be dead unless I paid them.
so heres another reason to motivate you to switch platform if using ifttt is a must for you
You are able to access the dashboard directly via the local hub IP address. If they really disappeared, you could expose the local web server out your firewall so you’d still be able to access it remotely.
Absolutely, Hubitat’s local control is a HUGE plus over Smartthings. I really think the choice comes down to what are you using the hub for? If it’s primarily automations, and you’re not relying on the cloud to do much at all, Hubitat is a great choice. But if you need the rest of the control that relies on the cloud, and need an app on the phone to do things, and want stable Alexa integration (which is what my family mainly uses it for), Smarthings really outdid Hubitat for those options. The future is anyone’s guess, and if Smartthings bricks up or charges a subscription, I’ll have to deal with it at that point. I think though if you want truly local control without having to worry about the future of the company, Home Assistant or OpenHab on the PI seems like the way to go. If the Home Assitant cloud goes away you should be able to just flash some new software to the PI and switch to someone else. I hear people rave about Hubitat’s support, but like Wink, Revolv, and Iris, you can’t sustain a business model on the one time sale of hubs, and although the Hubitat hub will work locally if the company vanishes, there won’t be any support or updates for it anymore, and anything relying on the cloud won’t work. What in the world is Hubitat’s long term business plan for making a profit? Samsung on the other hand is a diversified company with a lot of money to throw around.
Selling hubs? Since the Hubitat hub is not very powerful (it’s about the size of a pack of playing cards), some people who have lots of automation buy a second or third so spread out the processing load.
I think this has been a banner year for them.
And a history of dropping less profitable product lines with little warning. (RIP Artik. 
)
I wouldn’t count on Samsung’s size as a guarantor for any specific product, including SmartThings.
I think SmartThings is of value to them for tech cred, but I’m sure they care a lot more about their television lines. Just sayin’…
It sure has been a great year for them with all the Wink refugees, but I feel Wink was in the exact place four years ago Hubitat is now. Great support and the sky was the limit for them a few years back, then the wheels came off and it turned to garbage. It wasn’t the subscription that made me leave. I know cloud hosting isn’t free, and was willing to pay a few bucks. It was their total lack of reliability, and the way they did it- you have two weeks to pay up or we brick your device. The backlash was so bad they changed course, but the damage was already done. Hopefully Hubitat keeps innovating and attracting new customers to keep selling hubs. Maybe their costs are lower with less cloud hosting than Wink and it might be a total apples to orange comparison. I know it’s a bit dated, but thought this was a good article explaining the whole hub market. https://staceyoniot.com/heres-why-smart-home-hubs-seem-to-be-dying-a-slow-painful-death/
Or their phones that catch fire or washing machines that explode. Look I’m far from a Samsung fanboy, just saying the hub market doesn’t have a ton of options and that given everything Smartthings was worked out best for me. Your mileage may vary…