Is the IDE Really Going Away?

Bad questions are the unasked ones…

Yes, and?
It’s more like HTML vs. NotePad and (insert your favorite HTML IDE here)

In this case, Rules API is the base language - the method for communicating your hopes and dreams to the SmartThings API in a way that it can interpret and do…
Just as in the Groovy environment where you can use the IDE to upload a text file, you can actually use Notepad to create a Rule in the SmartThings Rules API if you understand the protocols / syntax at that level and use PostMan to send it. I think Graham has it down to that level - I can read it, but I’m still very bad at writing it - I have trouble thinking in JSON files.
SmartThings staff (someone please find the link I think it was Blake) said that they know this is a limitation to adoption and there’s a Rule Builder in development. <<< THIS would be your direct analog to WebCoRE and also where any updated version of WebCoRE would likely live if it becomes a reality in the future.


That really depends to what level you want to learn the system mechanics? I suspect we wont be able to do some of the really neat tricks without using Rules API directly But It depends on how rich the upcoming builder will be. That’s an unknown - so until that’s not, I’m reading and understanding the Rules API so I can understand what it can (currently) do. I will probably try portin gsome of my simpler pistons all while hoping this alluded to rule builder becomes reality soon so I can make a determination on how to break up my current webcore environment. (so read: you’re not alone with your uncertainty.)

I’d love to say yes the Rules API is worth trying now. The trouble is that only some basic parts of its functionality have been documented and although the Core SDK seems a little more enlightened, it isn’t by much. Given that Automations are implemented in the Rules API there must already be a lot more functionality implemented than is documented. I only need to do Noddy and Big Ears stuff but I can’t get close at the moment.

When you work with webCoRE you quickly realise that a lot of heavy lifting isn’t done by the basic logical structures, it is performed by the custom logic behind the scenes - stuff like the Task Cancellation Policy. Even trivial pistons need to be able to access event and match variables. You need a lot of functionality.


Just to follow up in nauseating detail, and recognising I am taking the thread ever further away from the original topic:

webCoRE has been wonderful in many ways, but it is every inch the beta product it claims to be and getting worse, and there is a lot of bloat with it. Its future is on Hubitat. I don’t want to still be using it but I still need it, and not for anything complex either.

Smart Lighting is great at what it does, though it has a couple of infuriating quirks. One is that its toggle command assumes nothing else is changing the state of switches (unlike webCoRE which looks to see the current state and toggles that - though even that behaves suspiciously on occasions). The really big one for me is that if you specify multiple motion sensors it does not do the obvious thing of ‘motion on any of the motion sensors’, it uses them independently (curiously I was convinced it did work sensibly for several months but then stopped, but maybe I imagined it). So I have to use separate automations to maintain virtual motion sensors (I use Rules, but used to use webCoRE) . As a legacy app its days must be numbered. Quite whether it will be reimplemented or its functionality absorbed into Automations isn’t clear.

Automations are infuriating. They seem to be maintained as Rules and reverse mapped into Automations by the mobile apps (with independent implementations) which seems to be asking for trouble and getting it. Also it just isn’t clear what the functionality is that is being implemented, for example when timers start and whether they run to completion or can get automatically cancelled. The worst thing is that if you delete a device that they use they are as likely as not to completely vanish (to be more precise the condition or action with the device in is removed and if the automation is no longer complete it is deleted, so you either end up with no automation or one that may not do what you want). I use them as little as possible for simple ‘if … then …’ automations where I have no choice or the convenient ‘on/off’ option comes in handy.

I am still using Smart Lighting for the basic ‘turn on a switch when motion is detected and turn it off x minutes after motion is no longer detected’ because it knows to cancel the timer and reset itself if motion starts up again. Similar functionality in webCoRE would use the stays condition or you could do much the same thing yourself using a wait and exploiting the Task Cancellation Policy. I believe the equivalent in Rules will be remains but if it has been implemented no one has said anything about it and I’ve no idea if a TCP equivalent is planned.

I am using webCoRE for the most basic of announcements like ‘the front door has been opened’ or ‘so and so has arrived’ because I really don’t want to have to write individual Automations and Rules when I can write one and use variables in the announcement. I am also using it for handling buttons for two reasons: one is that I am using toggle and I am too lazy to replicate that manually in a Rule; the other is that buttons report their last attribute change and don’t have a standby state so checking their current value isn’t helpful (although you can get away with it when there is only one button and it is the only possible trigger), neither is changes (which despite being in the proof of concept of webCoRE using Rules, is not documented in the Rules API) as there is no change of state, and there is no sign of an equivalent of gets.

I use Automations for two main reasons (or three if you include simple, quick and dirty automations). One is that Security Mode handling in Rules is barely documented and if the Core SDK is used as a source of undocumented functionality you discover that the Security Mode as a condition and the Security Mode as an action seem barely related which doesn’t inspire confidence. The other is that executing Scenes from Rules is also not documented. Clearly Rules can do all this stuff as Automations are implemented as Rules, but if it is available outside of Automations, it isn’t documented.


i really need to start working on porting from ST to home assistant. but don’t know if home assistant automation even has support for user defined custom device type, user config input aside from picking selection from device list, persistent local variables and nested if for triggers and conditions with user input config as part of the expression.

also for anything i consider secure like camera and locks it’s HomeKit native only for me.

there’s been some small features and fixes i have done in the groovy code last few months, but not motivated to release those anymore.

You can connect your Smartthings to Home Assistant. Then run the systems in parallel and migrate as you feel comfortable. Or keep your Z-Wave & Zigbee devices connected to Smartthings, but use Home Assistant for the logic. Home Assistant has an optional Node-Red add-on, so you could migrate your automation and logic to that. Lots of options that don’t require completely getting rid of Smartthings.


thanks, makes sense. yes, might start with ST acting like a dumb hub just for zwave/zigbee device connectivity. but not keen on leaving ST in there because they might decide to deprecate my V2 hub just when i get comfortable with that setup. so blue with the nortek stick is where i am going to end up if i can figure out how to get rooms occupancy kinda sorta working on home assistant.

I’m a little concerned that 1. We haven’t heard anything about the replacement yet and 2. There is zero developer enthusiasm for writing smartapps for the new API based platform

1 Like