I have a bunch of native ST automations and a several WebCore Pistons. I was thinking of migrating my native automations to pistons just because I prefer the format. Any thoughts? Are there benefits to keeping the native automations? Any downsides to making everything a piston?
I think you should actually consider the opposite. The future of webcore isn’t looking good since they haven’t started developing a non-Groovy app that works with the new SmartThings backend. As far as we know Groovy will be retired at the end of this year. Plus native automations can now run local.
Ditto Jimmy’s comments.
Reseve new pistons for things you can’t do any other way. For all else default to built in automations first.
Also, pistons can not fully manage some of the newer integrations
As much as I prefer pistons, and their superiority to anything that Smartthings could ever create, ST automations are the way to go.
As said above, webCore/groovy will be most likely going away by the end of the year. Sadly.
The native Automations are just a frontend for the Rules API. The Rules API can for sure handle your first example, the second maybe if it wasn’t for the variable (I don’t think Rules API has variables yet). You could dive in and create the first piston as raw JSON with the Rules API and Postman. Or SmartThings is working on a web-based complex rules builder that works with the Rules API that you can wait on.
I did not know that! I’ll go google Rules API and have some fun. Thanks all for the answers.
Definitely the first. I’d say no for the second, both for the lack of the variable and because ‘rises’ and ‘drops’ may or may not be available to the punters, but they certainly haven’t been documented (as is the case with much of the functionality that must exist to support Automations).
I spend a ridiculous amount of time on the webCoRE forum but am intent on bailing out as soon as I can, as I am with Smart Lighting, and also Automations as long as they can be deleted or edited without notification, let alone permission.
Graham you should develop a nice web-based UI for Rules API and sell it Maybe distribute through Glitch somehow?
Y’know - vswitches make great binary variables, just sayin’
the thing about this IOT thing, is that it’s too hard. I’m having a load of fun programing my shed do to basic stuff that has never been possible before. And now if sounds like I’m going to be spending winter doing it all again in a new tool. The only way this tech goes mainstream is if it becomes push-button simple and just works. This is too hard for 99.5% of the world.
The automations creator in the SmartThings app is pretty damn simple IMO. And is vastly more capable than automations through Alexa or Google Home. Probably even HomeKit, although I haven’t tried any of the 3rd party HomeKit automation apps. The people in this forum, and webcore users especially (including myself), represent a very small minority of the “IoT Thing” when you look at the big picture.
HomeKit has gotten vastly more powerful with Shortcuts (technically no longer a third party app since Apple bought them).
You’ll see from the list some items of particular interest, such as If, Wait, and Repeat. These overcome the lack of complex rules in normal HomeKit automations to a significant extend. With this you can create more complex conditional behaviors, and delayed actions.
The ability to extract data returned from web queries, and perform numeric calculations also stand out as very useful for creating more deterministic rules instead of static values.
In particular, the ability to run a script over SSH opens up some very interesting possibilities for more advanced users that want to interface with their own server based solutions.
If you’re a HomeKit power user, this added layer of control is well worth exploring.
There are also a lot more features for nonpower users than there used to be.
If all of this gets carried over into Apple home’s Matter support, The bar will be set pretty high for SmartThings to match on android. Which is my eventual hope.