I am facing the exact same conundrum as the OP…
Stay with ST and just ditch the idea of persisting all my WC pistons somehow altogether, losing all that functionality I have spent ages building. This would make me cry and is not really a feasible option for me.
Make the move over to Hubitat completely. From what I have read, seems like a great move to do. Local execution. Reliable platform. Could still use WC and all my existing WC pistons. Aside from the pain of migrating devices etc. across to the new platform, minimal disruption to my smart home.
What’s not to like? Well, the answer to that is the HE mobile app; it is terrible. The ST mobile app is quite polished (in my opinion) and I would miss it a lot. Also, will Hubitat continue to support Groovy SmartApps such as WC forever…who knows?
Run ST and Hubitat in parallel (2 hubs). Use Hubitat as my master hub and migrate all devices etc. across to that. Use the HubConnect SmartApp to bi-directionally send/receive device messages between a master Hubitat hub and slave ST hub. This would mean I could benefit from the brilliance of Hubitat (local, reliable) and still get to use the more polished ST mobile app. Sounds great, right? Except for the problem that the HubConnect SmartApp is a Groovy app, and would therefore fall foul of Groovy being shut down on the ST side. So not really an option after all.
Explore the possibility of using SharpTools instead of WC, and keep everything on SmartThings. I already have. I registered for my free account as I was impressed by what I had previously read about SharpTools’ rules engine and its capabilities. However, the very first WC piston I attempted to migrate across to SharpTools - at random from my collection of pistons - instantly met with a blocker. It appears that SharpTools doesn’t (yet?) have the functionality to remember a device’s state before performing some other action.
Example: my Ring doorbell button is pressed, WC piston is triggered, a certain set of Hue lightbulbs’ states (dimmer level, colour, on/off etc.) are remembered by storing the states, then the aforementioned lightbulbs are turned on and made to be blue for 5 seconds, to visually indicate the pressing of the doorbell button in case I failed to hear it for some reason, after those 5 seconds the lightbulbs are each returned to whatever their previous states were (on/off, dimmer level, colour etc.) before the doorbell button was pressed.
WC does this just fine. SharpTools doesn’t appear to be able to remember device state, so I cannot migrate that particular piston functionality from WC to SharpTools. Of course, I’m not going to be a total idiot and simply write off SharpTools altogether just because it fails to mimic the functionality of that 1 WC piston (that I’ve found so far), but I do want to retain some order in my smart home and try to keep everything in a single-ish place. WC lets me achieve that, SharpTools - at the moment - will not.
I have read a lot recently, given the impending doom of losing Groovy SmartApp execution in ST, that between the ST mobile app’s built-in Routines/Scenes and new Rules API, I could probably manage to migrate all of my WC piston functionality into that architecture. Adding to my confidence in doing so is that the new Rules API was apparently designed with WC in mind, as ST knows how important WC is to its power users. The original author of WC, Ady, was also involved in the design of the new Rules API, so I have read. I have even stumbled across some old SDC presentations, where the new Rules API was said to be being built with WC’s power and functionality in mind. This is all great so far.
But Ady has left ST. Nobody on the WC side seems to be visibly doing anything to get WC working with the new Rules API. And the SDC presentations I have watched appear to show a design direction that “seemed a great idea at the time”, but hasn’t made any movement towards those goals since. I might be wrong.
I am comfortable with JSON, as I use it everyday in my job, but in order to achieve some complex WC piston functionality and logic in that JSON for the new Rules API, it seems I need to be able to write God-level JSON and place all my faith in not getting confused too quickly by the new Rules API’s JSON constructs and getting lost in it all. On the face of things, it would seem to lead to a debugging/troubleshooting nightmare too.
I have also read about the “SmartThings Rules Manager”, and seen a demo of it on the glitch.me website (that link, by the way, was extremely difficult to find amongst all the noise on the various forums surrounding this impending issue). However, I have no idea how to use it.
I would happily try to gradually migrate all my WC pistons into the new Rules API, if only there were some decent documentation to begin with. It just seems non-existent, other than mentioning the API endpoints and JSON schema. Is there any dashboard/GUI thing for using Rules API?
Just my contribution to this thread really. Many people seem to be in the exact same boat with this, yet there doesn’t appear to be a clear way forward yet. And time is ticking.