I am currently migrating to Hubitat. It is a bit painful with over 100 devices and about 100 pistons. The new instance of Webcore in Hubitat has access to all my instance of Webcore on ST, so I can just copy my pistons over from the Hubitat Instance and update devices and piston execute calls.
I am moving things over in logical groups based on piston dependency for devices and executing other pistons, so basically one “area” at a time. I plan to be done by the end of October, with very little down time.
I am using Hubitat virtual motion detectors as Alexa buttons to trigger routines. Set the sensor to return to inactive after 5 seconds.
I am very happy with Hubitat so far. I have Echo Speaks back, something I really missed after the ST ban. I feel very at-home with the groovy environment. I now have local execution of devices and Webcore pistons. Everything is faster, and there is no long piston load or save times in Webcore like there was with ST Webcore.
@chrisb23, same situation here. 140 odd devices, Webcore, HUE integrations. The move to Hubitat has taken some time for sure, but I’m quite happy with the outcome.
Rather than wait for most of my house to break, I figure moving over to Hubitat means I have gotten everything working now, and there is no frustration over what will 100% be a mess after Groovy is turned off. Yes, it will eventually get sorted, but I’m done with ST. I had a few FGK-10x (older firmware) contact sensors that I use with DS18B20 temperature probes for our solar pool heating automation that I knew were going to be problematic…but a very helpful Hubitat user sorted a working driver for me.
The GUI of the Hubitat new lighting app is a bit clunky, but I’ve realised now just how powerful it is to deal with my more difficult lighting chores, namely disabling motion activation on devices during manual scene changes, theatre integration etc.
Finally, Hubitat’s Harmony hub integration along with standard HUE/Harmony integration took care of anything related to our living area and extensive theatre automations.
They also have a few things sorted that should 100% be part of very hub:
Backup and Restore.
Multiple Hub integration so you can use a 2nd hub to extend your network over LAN.
Translation: the end of SmartThings has arrived. No complaints on value - I bought my hub long ago and it’s paid for itself over and over again. Granted, I spent a lot of time fixing what SmartThings broke over the years.
I wish everyone who stays the best of luck - hang in their, Bluetooth is right around the corner, they promise. For those interested in leaving, HA on rPi works with Bluetooth out of the box, and with the easy add of a Sonoff Zigbee dongle, HA works with all of the ST devices, too - even better than ST does today and has for the past few years
SmartThings/Aotec - maybe I’ll rethink my decision and buy your new hub and new sensors, you know, if you ever actually release something new for me to even buy. Until then, I wish you luck with your next product management team, and appreciate the little outgoing reminder of how great you’ve been here these last few years.
This is a strange sentiment. It seems, to me, that this is a VERY strong new beginning, not an end. SmartThings has invested extensive amounts of resources and time to moving to a new and more advanced platform with Edge. They’ve done that to increase capabilities, improve reliability with local execution, and guarantee the future of the platform by making it financially sound (hosting unlimited apps at no cost was unsustainable).
I can’t imagine they would be going through this type of extreme investment and effort towards the project if they intended to abandon it or not foster its growth. Quite frankly that makes absolutely no sense.
I understand the growing pains have been frustrating. But I will say now that I have fully converted to Edge drivers I have not lost any core functionality and have in fact gained capabilities and reliability. And Edge isn’t even fully launched for 2 more months.
I am moving things to Home Assistant (HASSIO) because the Rules API is limited. They should’ve had the functionality of WebCore before they started this transition. It’s not like they were not aware of WebCore and what it can do. Not allowing you to query a website is so dumb. HASSIO with Node-Red is a fairly simple way to create automations and it is very flexible.
They never committed to this. They showed a Proof of Concept at SDC of webcore generating the JSON for rules API and they used webcore as an example of a community created app. They never committed to integrating or taking over webcore in any official capacity.
There is a community member working on one, but it’s still in the alpha stage. Not sure what all the features will be, though, but so far it’s the only browser-based interface to the API that I’ve seen. It’s possible this will just end up being a substitute for the IDE, though, not a rules creator.
I still wish smartthings would come up with the one they were originally working on, of course.
@TAustin we need some clarification. @JDRoberts is telling users now what your goal is with SmartThings API Browser+, that once it comes out of alpha, eventually it will be able to allow users to harness the full power of Rules API, and create advanced rules similar to webCoRE, like the discontinued Rules Creator was set up to do, is this true?
This is not accurate. It is an API browser tool in its current form. I have done little to incorporate the ability to create things like rules, which would be a huge project in and of itself. Currently the one exception to that is I do have the ability to create virtual devices.
The fabled rules creater/builder or whatever it was called would be awesome to integrate somehow. If Samsung isn’t going to continue with it, then maybe they’d be willing to make it open source??
UPDATE: My API Browser now includes the ability to create a rule by submitting a preconfigured JSON file.