As @an39511 says, webCoRE and RuleMachine (RM) are both capable solutions. RM is powerful but is hobbled by a User Interface (UI) that makes it appear more difficult.. ok, is more difficult. But the resulting Rules execute as well if not better than webCoRE. Node-Red runs locally too and has a UI that is like no other. It runs on a device you build locally, a dedicated RaspberryPi is popular, but it is just a NodeJS app and thus will run on almost any always on computer, Mac, PC, NAS.
As mentioned, you can use 'interconnect' tools (Apps) to smooth your transition from ST. You install apps on both and they allow the devices to be 'mirrored', one hub to the other. There's a built-in app (pair) called Link to Hub and HubLink, as well as a much more popular Community created app called HubConnect.
Link to Hub/HubLink will not 'mirror' all attributes, while HubConnect 'mirrors' all attributes.
Three Hubitat Hubs, a Homebridge "hub", and SmartThings too, to suggest what's possible.
It's hard to predict the future, of course, but Rule Machine is a built-in app that will presumably be updated and supported for the foreseeable future as the platform continues to grow.
Webcore, while a very capable app, may or may not continue to be supported since it's a community-developed app, and in the worst-case scenario it could stop working entirely due to platform changes.
I found Webcore's GUI appealing when I used it on ST. And I can't argue that rule machine's UI is a piece of cake to use. But SmartThings didn't have a rule engine. I'm sticking with Rule Machine as long as it's a major component of the Hubitat platform.
Ah, cheers all for the replies... Very detailed, educational and spot on!
I had a crack with rule machine whilst I should really have been off to bed. I think for ease of use, it sounds like webcore is still going to be my preferred route. Mostly because I have a few kick-■■■ pistons in there controlling my central heating etc, so it'll be very (very) difficult to translate to RM (it took a fair while to write the sods after getting some help and ideas over at the webcore forum). Some of my pistons have quite an extensive use of variables and its far easier to have them stay put.
I do need to actually get things up and running. Obviously the processing over at ST has this far been done on their cloud, so I'm not confident in just how optimised the code is... I'd hate to have this suck my new hub dry. Side note.... Is it possible to see a 'cpu usage' style report to see just how loaded it becomes once I chuck all of my crap on it? =p
I'll also take a look at smartly, so thanks for that.
I guess smarttools hasn't been on anyone's recommend list either, it seems. Any reason.?
As you get more familiar with the platform, you might find that it works to try to move automations over from webcore to rule machine in stages. OTOH if webcore continues to work for you, then that’s super.
Not possible, and FWIW Hubitat staff have mentioned in the past that it wouldn’t be that useful (not specifically for webcore, but in general for trying to track down problematic apps/drivers).
Not sure I’m familiar with that one. Do you mean Sharptools? ActionTiles (formerly known as SmartTiles)?
at the risk or being wrong twice in one thread sharptools is not local at all (and I had double checked lol). I used it back in the day and it's a good solution as well. If you do use consider smartly or HE dashboards, don't access them via the app. You can save a local/cloud link to you mobile device home screen and make the experience much more enjoyable, as described here. If your feeling really adventurous check out the first few post on this one.
I have just moved from ST to HE. Webcore works well and it is pretty easy to migrate your pistons over.
That being said I rewrote most of my easy stuff in RM. As someone else mentioned, the state of webcore could change quickly since it is a third party app that HE does not really recommend.
The beauty is you can move over your pistons quickly and then move to RM at your leisure if you so desire.
Webcore is also setup in the Hubitat package manger and is easy to install and. setup.
The other thing I don't see mentioned is that Rule Machine is a built in officially supported app. The developers are committed to maintain and fix bugs and/or improve things as time goes on. In theory it also ensures interoperability with other apps and the hub as a whole.
With community based apps like Webcore, there is no guarantee of anything. Not saying that Webcore is bad (never tried it, I have no opinion either way) but if it were to somehow make your hub lock up, or whatever Hubitat support can not and will not help you to diagnose it. It could also stop being supported, or pulled by the developer, which has happened quite a few times in the past.
And just to make it clear, I am not rooting for either official or community based apps. I use both pretty freely, and usually without any trouble either way.
The really cool thing here is CHOICES! we can use RM (built in & officially supported, amazingly capable but a bit hobbled by the somewhat clunky UI), webCoRE (for ease of migration for legacy ST users), and Node-RED (so graphical, easy to share flows, a little complex to learn and requires an additional always-on device). Oh, I almost forgot - or build your own app using Groovy.
I held off on Hubitat Rule Machine initially due to some of the quirks with earlier version of the app. With 4.0 I was able to bring all my pistons from WebCore into Rule Machine. I keep looking at WebCore on Hubitat on my test hub and it's gotten much better as the developers continue to optimize the code for a local execution.
As a proponent of Keep It Simple Stupid and I have to support clients deployments I keep to known working apps and device drivers to keep the devices stable. Lots of choices on how to automate is great but my goal is to keep the platform stable and and reduce my time to support the platform for myself, the wife and family, and the locations I am supporting.
Before chiming in with a simple question, I scoured this thread yet saw nothing matching too closely... curious to know whether you can use Rule Machine to "fire" a WebCoRE piston directly. That is, without expressly setting up a dedicated ____ (variable, virtual switch, or other contrivance), is there an action one can deploy within an RM rule such that it causes the desired Piston to do its thing?
I'm thinking in terms of a Piston that doesn't necessarily have (or subscribe to) its own Trigger(s), and would otherwise just sit around like orphaned code unless/until summoned by Rule Machine.
Thanks in advance, y'all.
P.S. Yep, I took a gander at the WC docs, but they mostly reference SmartThings and nowhere in the "Triggers" section did it mention doing something "hybrid" like I'm proposing here.
That's kinda what I assumed, but didn't want to lash that together until I was sure some other, more "direct", path did not exist. Thanks for confirming, @thebearmay!
On the strength of your advice, @thebearmay , I took my Piston in that direction -- being called via a GET request in an RM rule -- BUT...
• GOOD: When I execute the Piston's (local) external URL in a browser window, it works (result: "OK") and the variable computed by the Piston gets updated as expected.
• BAD: When the RM rule runs and does its call to the same (local) URL, the Piston does not execute (per its Last Execution timestamp), and the variable remains unchanged.
I consider this unexpected behavior. Am I doing something so wrong it's obvious? Or do you think I should have sent the RM rule's HTTP Request as a POST [EDIT: Nope, that didn't help], use the Cloud URL with GET instead [EDIT: Yep, that worked!], etc.?
Weirds me out when two near-identical moves don't produce the same result. Testing seems to indicate that using the Piston's Cloud URL to invoke it is preferred for use with RM rules.
I assume the local endpoint is a hub URL? If so, try port 8080 instead of the default (80). There could be issues with using the same port for both sides of this call, and port 8080 is an alternate on the hub for port 80, so the result should be the same if it works.
YES! We have a winner. I added ":8080" to the GET URL and it worked perfectly. Makes sense, too, but I worry most users will not know to make such a modification.
I'd almost advise the WebCoRE dev to include a 3rd URL type -- call it "Hub URL" or something to distinguish it from calls from other network devices -- that includes the port 8080 stipulation.
THANKS for the suggestion. I honestly would never have thought to try that.
TCP/IP doesn't work that way. The outgoing port is chosen randomly and rarely matters. The incoming port matters because a listening socket must specify which port it listens on.
It does. The Webcore UI only shows the external URL, perhaps because pistons cannot execute locally on SmartThings.
In HE under apps in the webCoRE section, click on the piston you want to run locally. Then click the "Test run this piston" button. Besides testing the piston, the resulting screen will also display the cloud and local endpoints to execute the piston.
