Smartthings user here, just received my first hubitat hub yesterday and am starting the slow migration process (I have quite a few devices and a pretty decent actiontiles setup at the minute).
Obviously there's a bit of a learning curve, and rule machine (at the minute) seems to be less intuitive... But I'm used to webcore, so I'd expect that.
Just wondering if there was an advantage to learning rule machine, or is sticking to webcore likely to give the same results but without the need to relearn how to ride a bike?
Also, I'll take a good look around later but I need to recreate some equivalent dashboards. Again, is it best to work with the built in hubitat dash's or is there an alternative that I'd be better off concentrating on? Want everything to be absolutely local, if poss.
You just answered your own question. RM is local WC is not.
You should also check out Simple Automation Rules for basic stuff, and Motion Light app, for well motion lighting. Both are built in apps you just need to install if you have not yet.
For complex stuff I have moved most rules from RM to Node-Red. I find it easier to create complex rules, and the processing of those rules does not impact hub performance. Plus we can share rules "flows" in NR. For me it is a nice balance.
As for dashboards I recommend using smartly to get a jump start. Once updated the dashboards run mostly local, and it's effectively a pretty 'skin' for the built in dash app (@spelcheck doesn't like me calling it an 'editor', but you can use it to edit stuff too ) In full disclosure, icons/images/fonts are hosted offsite (AWS), but can be changed via CSS if you have the ability/desire to host your own images/fonts/etc. One of my dashes run 100% local, but it took additional work, and I will most likely go back on next update (was testing the ability).
You may also want to check out HubConnect while you transitioning, or if any devices are not fully functional in HE yet. Don't keep your ST device on that hub long term, or again you won't be local.
If your wondering how local you are, unplug your internet for an hour to see what works, and what does not.
I could be wrong on that. I've not used webcore since my ST days when it was web-based. NR is more visual and works better for me. At least than the old webcore, again it has been years since I used it and things change.
I came from SmartThings using webCoRE..... and still 100% on webCoRE. Rule Machine is a very capable app but just not as capable as webCoRE when it comes to working with variables and expressions. Although I suspect most people wouldn't make use of those features anyway.
Before I ported over to Hubitat I gave Rule Machine a go and tried to recreate some of my more difficult webCoRE pistons and just couldn't do it. To be fair to Rule Machine, at the time was sorely lacking in the area a variables but has since improved.
So when I ported over from SmartThings over a year ago it was easier to keep webCoRE and all my pistons automations because Rule Machine couldn't do what I needed it to do. A year and a half later and still on webCoRE.. Call me lazy I guess.
IMO Rule Machine's UI just isn't that good and anyone that has written code on a fairly regular basis will have difficulty learning it. But, this isn't the fault of the author that wrote Rule Machine. I think the reason Rule Machine's UI is the way it is has everything to do with Groovy. If you look at any app, they all have the same look and feel because its a Groovy limitation.
My advise to you is before you make your decision give Rule Machine a fair shot. Sit down and work with it for a reasonable amount of time. Just as webCoRE has come along way in the past year, so has Rule Machine.
And in closing, webCoRE's pistons all run local. The only thing that is cloud based is the UI for creating, editing and saving pistons. Once saved they are on your local hub just the same as Rule Machine. (BTW: There is an option to run webCoRE's UI local if you want to go that route)
Webcore does run local on hubitat. I was a huge webcore user on smartthings. I tried rule machine and just despised the way you build rules even though it's quite capable. I'll put another vote in for node-red. There's a bit of a learning curve, but you could pick up the basics in an evening. I personally feel it superior to both webcore and rule machine. With hubitat you run it on an external device such as a pi, which has the added bonus of reducing load on the hub to keep it nice and speedy.
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.
You just answered your own question. RM is local WC is not.
) In full disclosure, icons/images/fonts are hosted offsite (AWS), but can be changed via CSS if you have the ability/desire to host your own images/fonts/etc. One of my dashes run 100% local, but it took additional work, and I will most likely go back on next update (was testing the ability).
