Newb from ST - Rule Machine vs Webcore

Apologies if this has been asked before but I didn't find any recent topics on this. Been using ST for several years and just got a C7. Installed Hub Link and am getting events from the ST hub.

Looking for pros and cons on Webcore vs RM (other than the obvious learning curve which I don't mind if it's the better way to go).

I'd prefer a more traditional code editor (I'm a 30+ year C++ programmer) but I'm ok with Webcore. Should I take the time to learn RM and port my pistons over to it, or continue to use Webcore? I'm especially interested in using Echo Speaks, which is one of the reasons I'm fleeing the ST train wreck.

Thanks in advance.

Personally, I like using nodeRed. It takes processing away from Hubitat hub to Raspberry pi or whatever you install it on, so it saves precious computing power in the HE hub. I don't have a lot of experience with WC lately, but RM is directly supported by HE, so I would probably lean in that direction. I know WC caused a lot of problems with HE at first, but I understand a lot of those problems have been resolved.

1 Like

I think it comes down to personal preference at this point. Both RM and webCoRE are efficient on HE, in different folks reports both are very fast and it is hard to pick out a pattern of which executes more quickly.

For basic automations, the features are similar. Going past that they show differences in the types of functions, etc one can use. Webcore has in these 'going past' in number of functions available.

1 Like

webCoRE has a slick UI and is very powerful... but there are all these rough edges (quirks, unimplemented features, tricky behaviors) and it is no longer being actively developed.

RM is equally as powerful, but has less of a polished UI. However, it has an active author and is well supported by Hubitat.

So while my ST still uses webCoRE (because that's all there is), when I switched to Hubitat I started to build my complex rules in RM.

And the funny thing is... right now I have no production rules in RM. All of the pistons I brought over I was able to recreate using either the Motion Lighting App or the Simple Automation Rules app, both of which are simple to use.

Thanks. Took a quick look at node red but I'm not a Linux guy and I don't want to get bogged down setting up a pi or a Docker image. I don't think the small number of rules I have will overload the HE hub. If I ever get to that point, I'll take another look at nodeRed but right now I just want to move my webcore pistons off of ST, especially the ones that use Echo Speaks.

Thanks. Was not aware of that, but looking around the WC forums, it does appear that nothing much has been happening for the past year or two. That's a bit of a red flag.

The few pistons I have are probably outside what anything built-in could handle. For example, I have a piston that queries my personal weather station every minute for nearby lightning strikes. If a strike is 10 miles or less away, it sends a notification to my Alexa devices, flashes the pool light and flashes the backyard lights. If subsequent strikes get closer, the announcements and flashing repeat. If the strikes move farther away, then I ignore them until they get closer than 10 miles again. We get lots of lightning down here in S Florida and it can creep up on you pretty fast.

In the interest of getting something running quickly, I might just recreate my existing pistons in Webcore, since ST killed off EchoSpeaks and nothing is working now. Then I can try to port them to RM.

The author of webCoRE was hired by SmartThings, after which his work on webCoRE seemed to stop. It doesn't mean it's abandoned, as he could pick it up again.

The other question is what feature in webcore are you requesting? There are folks that update for new features that gather support - changes have been made for weather changes, improvements in web functions, attribute subscriptions, time parsing, execution performance, resource reductions, etc.

So what change is being asked for?

I've been using webCoRE exclusively for 18 months and it has been rock solid the whole time. Profile - nh.schottfam - Hubitat has done an amazing job of streamlining and I find it far better in performance than it ever was on SmartThings. Rule Machine is just as capable when dealing with home automations but when it comes to more sophisticated tasks, especially with the use of expressions, webCoRE excels. Of course I am bias because I knew webCoRE and was always frustrated with the Rule Machine interface. Now that I have tested and confirmed that the webCoRE WEB UI can run local I am not too concerned what happens to it on the SmartThings platform. And finally in the 18 months of use I have not had any occasion where webCoRE was lacking in anything I've wanted to do. It is a well developed app that has it all. Oh, and one more benefit of webCoRE is you can choose to update it separately from the Hubitat platform. This is not to poo poo Hubitat but inveritably whenever there is a platform update there is usually some quirk or bug that presents discussion in the forums. Of the many, many platform updates I have only seen once where it interfered with webCoRE operation which was fixed within an hour or two, primarily because that update caused significant issues with other Hubitat applications. As Rule Machine becomes more mature I'm sure what I speak to here will be less and less of an issue.

I hope this helps you to decide on what is best for your situation.


Not sure if your reply was directed at me, but if so, I wasn't asking for any change. Was only asking as a noob about the pros/cons of WC and RM as it relates to Hubitat, before I go too far down one path. I've been using WC on ST without any issues (other than the poor documentation).

Thanks, it does, especially the reference to the maintainer of the Hubitat port, which led me to the 'webCoRE for Hubitat Updates' thread, something I clearly missed in my prior search. My comment about no updates to WC was based on looking at the repo at ady624/webCore, which hasn't had any commits in over a year. I didn't realize there was a separate repo for Hubitat, which seems to be very active.

After playing around with RM for a couple of days, I'm ready to tear my hair out. I'm sure it's quite capable, but the UI leaves something to be desired. Even though I can't directly enter code, WC's presentation looks enough like C++ or C# that I can immediately grasp the piston's structure without having to think about it

Wonder why Hubitat didn't adopt WC (or fork it) as its built-in rule engine.

1 Like

Personally I have kept with webCoRE after a brief foray into RM.
The main reason was that I just imported my ST rules in and changed the devices and fine tuned them to work with HE.
TBH I don't think there is much difference between RM and WC in functionality, but I do find the WC UI much easier to use. (Probably as I've been using it since Ady introduced it).
You pays your money, you takes your choice............... :wink:

Below is a brief history lesson. It seems that RM created originally for ST was the genesis for the creation of Hubitat and is Bruce's "baby".

Not mentioned is that WebCore filled the gap left in ST when RM was pulled.

1 Like

Rule Machine was first on SmartThings and for certain reasons there was a fallout and the author along with others left SmartThings to create their own platform, Hubitat. webCoRE was born out of the Rule Machine vacuum left on SmartThings. I was using Rule Machine even after they left the platform because it was the only game in town. I got used to the UI and got pretty good at it but making changes was a real indever. Understand the Rule Machine UI is not the fault of the author but has everything to do with the constraints of Groovy language. webCoRE could never be what it is without the WEB interface. It is totally possible the Hubitat hub could host the webCoRE interface directly on Hubitat but it's been explained that is not likely to happen because of the added security issues running the http server. Maybe someday things will change but for now we have webCoRE that works and should continue to do do so even if they pull the plug on SmartThings, which IMO is inevitable. I think there will be a webCoRE like replacement but if Groovy is going away, so will webCoRE

They've never said anything about this publicly, but my guess is that they probably considered this once, at least as a supplement to RM. Long before I knew what Hubitat was going to be, I noticed references to something "hubitat" in webCoRE's source code (I can't remember where now...) and didn't think much of it other than wondering what it was. Further, when the platform was brand new to the public (January of 2018) and the similarity of Hubitat's development environment to that of SmartThings was a selling point for a lot of early adopters, staff bragged that it was so similar that someone in the "community" had managed to adapt webCoRE, probably the largest and most complex SmartApp out there. That being basically day one, someone clearly had a leg up--but whether it's because staff was working with the idea or Ady himself was just one of their alpha or beta testers (presumably before going to work full time for ST, which may have also affected the trajectory of this story)--or if it was another intrepid tester entirely--we don't know. All just guesses based on what we can observe...

Further, staff seem quite familiar with how webCoRE works, and that's actually one of the things they've commented on and probably a reason they aren't interested in supporting it: they consider it inefficient in that pistons get stored as JSON and then interpreted via the webCoRE piston app (though with the latest Hubitat fork updates, many people find it to perform well; writing a Groovy app directly would certainly be a more difficult task, even if more efficient).

Rule Machine itself has changed quite a bit on Hubitat. The Rule 4.0 UI we see today allows the creation of automations that more or less is what you could do on webCoRE: an ordered script, actions to perform, possibly conditionally. I know it's hard to remember now, but older versions of Rule Machine just let you choose actions and ran them in a pre-determined order, usually based on the truth value of a "rule," which was then actually a specific concept in RM (a specific combination of conditions evaluated for truth), though other types of rules like "Triggers" (basically what we've got now with more power behind them) also existed.

Oh, and don't forget that CoRE predated webCoRE--and personally, I find the "web" thing to have helped a lot. I could not wrap my head around CoRE. :slight_smile: Part of the limitations of both RM and CoRE have to do with the UI model that that they're using (more or less the same) and that RM in particular is pushing the boundaries of. Some day, we might get something more flexible here that would allow better UI's--they have conceded that webCoRE's UI would indeed generally be considered better.

Not necessarily: all that needs to happen is that webCoRE would need to adapt to the ST changes. In a recent-ish developer video, they actually very specifically mentioned that webCoRE (the editor portion) could be just a front end that uses ST's new Rules API behind the scenes--so instead of interacting with your ST hub/account via classic Groovy SmartApps (creating pistons that get interpreted by webCoRE on your account), it uses ST's new Rules API instead (creating Rules for you, something new in the "new" ST model). ST even toyed that Rules might be able to run locally some day. How far along the development of this API is, I don't know...and I think it's safe to assume the second thing is still years off if it even happens. :laughing:

1 Like

That's kind of what I was imagining with WC being the default rules system for HE. The front end would just generate whatever back end output is optimal for the given platform.

Far as pistons being stored as json, perhaps that's been retained so pistons can be copied from one platform to another. They don't necessarily need to be interpreted by the piston app though; maybe they could be precompiled to platform-native code at the time the piston is saved. Or perhaps they are on HE, and that's why they execute faster than on ST. But modern code interpreters (or jit compilers) aren't necessarily inefficient either.

I personally think in a manner closer to WC then to RM. Because of this, WC makes more sense and its easier for me to write automations.

I used RM when it was on ST, and I found it easier to use / more intuitive at that time, but it has obfuscated the traditional if/then/else to triggers and actions as it has gotten more "mature".

Technically it's not a constraint of the Groovy language, but instead a constraint of the app UI APIs provided by the platform (which happen to be in the Groovy language).

The UI is HTML/javascript, which is served up by Jetty, an embedded web server that runs on Java. Your browser is doing all the heavy lifting as far as rendering the UI and executing javascript libraries such as jquery and datatables.

Whether the HE hardware has sufficient power to generate the HTML and handle the ajax calls required for an interface like WC is probably the issue, if it's even an issue at all. Much of the WC UI is probably static HTML, and the dynamic part can't be all that compute-intensive to generate. For that matter, you could just pass a json representation of the piston to the browser and have the UI generated via javascript.

Yes, but app UIs in Hubitat are generated by methods provided by Hubitat's app UI framework. These are pretty limited, being inspired by the same methods on SmartThings that were basically intended to allow inputs for SmartApp UIs in the SmartThings mobile app. You could not get something like WebCoRE directly from that. For people's best attempts, see things like the original CoRE (not WebCoRE)--or really RM on Hubitat, too. :slight_smile:

You could serve arbitrary HTML (not just HTML; a full web page) from an OAuth endpoint. I do wonder if anyone has ever tried something like that for user input in a Hubitat app...

But in the meantime, if you prefer WebCoRE, it's still pretty easy to set up, especially if you use their cloud Dashboard. Even if that goes away, you can host it locally (or not) yourself...just not directly on the hub as it currently stands. :slight_smile:

1 Like