Yep! I agree and am now 100% RM and other system apps and things are working well. I do try and stick with the native stuff as much as possible.
However if WC ever stabilizes for HE I'm definitely going to take another look - for me it's just easier to see and control the logic.
Is there a source for example Rule Machine examples rules we can learn from?
I suggested a category for people to display their RM Rules for people to look at, copy or just get ideas from.
As you cannot find it I guess you know what the response was. 
Are there plans from Hubitat to fully integrate Webcore in a supported fashion or is rule machine the decided rules engine? As many have stated the logic layout is quite readable. Has countless capabilities including http post which I leverage.
While I'm sure they won't publicly commit either way to future plans of any sort beyond the information they already provide, my opinion is that I sincerely doubt you will ever see webCoRE integrated as an official part of HE. Some history, which you may know: Rule Machine was originally created on SmartThings, then pulled when ST platform instabilities caused frustration for end users or at least the developers, who apparently then (or had already?) started work on the very platform we are using now. So we've got ST to thank for HE (and I'm guessing the ability to develop apps in a Groovy environment on HE that so closely resembles the ST sandbox is a side effect of how they got RM to work on HE).
In the meantime on ST, CoRE and then webCoRE were created to fill this void. The main developer behind webCoRE is now employed by ST, so it's likely official support from that channel will never happen (though it's quite clear the webCoRE devs knew about Hubitat during the creation of webCoRE, as Hubitat URLs were/are whitelisted--before its release--along with ST cloud URLs for access to the public webCoRE Dashboard; I'm not sure what to make of that). WebCoRE, including the web-hosted "IDE"/dashboard code, is open-sourced under the GPL, so anything is possible--including the community-maintained Hubitat fork and running your own Dashboard locally should the public one ever go down or block Hubitat--but the Hubitat devs are quite proud of RM (and generally unwilling to help with webCoRE-on-HE problems aside from modifying some HE changes that caused massive slowdowns a few firmware updates ago). I don't see that changing anytime soon...or really ever. 
Despite these challenges, many people who use webCoRE still find it to work well on Hubitat. Hubitat Support, however, finds many (most?) hub slowdowns that do happen happen to webCoRE users. Personally, I still have a couple webCoRE pistons that I'm converting either to RM or custom apps, and my hub is usually OK, though sometimes it seems to freeze for a bit after a reboot (or firmware update and reboot). Clicking "Done" in each webCoRE piston child app helps the piston run faster the first time, but sometimes just loading these apps in the UI for the first time also takes a while.
WebCoRE in general will also always run a bit slower than a native app due to the fact that it's effectively another layer of interpretation on top of Hubitat's existing interpreted Groovy environment. If you can stand to write a native app, I think the effort is worth it, though it's obviously a bit more work (and subject to some things that webCoRE's largely point-and-click nature saves you from, like syntax errors). As a workaroud, if you don't mind the cloud, you can always try the community Other Hub integration to use relevant HE devices on ST, then keep webCoRE on ST where it either runs well or pushes the problem to the ST cloud where nobody notices. 
The execution for automation between RM and WebCORE is fairly significant for me. Right now light automation happens instantly via motion with RM whereas that same environment will feel laggy (feel exactly like ST) in WebCORE. After experiencing RM and the difference I honestly canāt go back to something that causes that much lag.
New section added last week
CoRE (Community's own Rule Engine) later went web based, hence webCoRE. Community owns it and always will. Not a Hubitat responsibility.
I saw that about the same time I started linking to that old thread. Thanks for posting your great examples Chris.
I've given rule machine a chance but it feels like a huge step backwards from webcore. I feel severally limited and frustrated when using RM.
Like WebCoRE, Rule Machine takes some learning. If you haven't looked at the docs and examples, I'd recommend starting there. Actually, I'd recommend starting with the built-in apps first to see if any meet your needs (there are a lot with lots of options to handle various situations). Finally, if you get stuck with RM, feel free to ask the Community for help--lots of people here are willing to help.
You may have seen that you can also run WebCoRE on Hubitat. Some people reported problems (hub slowdowns) in the past, but I believe the recent and currently maintained fork has addressed those. I'd still encourage you to take a look at stock apps, including but not limited to RM, but it's still an option.
And welcome to Hubitat!
Thanks, I always try to give the native apps first try. Granted I've only given RM about two weeks of use but after a few dozen rules I've found it to be more like a ST smart app.
Navigating feels like a ST smartapp, where every step is a separate page, lots of "next" "save" "done" buttons needed to progress the logic stream. I thought this was a limitation of the SmartThings app so I find it strange that Hubitat imposed the same restraints...
I haven't given up on RM but, I don't feel that there is much left to learn. I understand how to accomplish all that is needed but to do so is tedious compared to webcore.
Hubitat implemented a Groovy sandbox very similar to that of SmartThings. You may be aware of Rule Machine history--it actually originated on SmartThings. The limitations you mention are an artifact of this app paradigm that Hubitat "inherited." You can find comments from staff saying that they're not opposed to developing a new UI framework but it's likely not a priority at this time. RM would likely be able to benefit from that.
The same limitations are likely what turned CoRE into WebCoRE. You aren't wrong that some things take a lot of clicking.
This is not a plug for any particular rules engine as both do their jobs well and both are efficient. My only argument against using "built in" applications, be it on SmartThings or Hubitat, is that you are subjected to quirks, bugs and "improvements" every time the platform updates. This isn't a dig on Hubitat but every release they do introduces bugs of which most are smashed in the first, second or third hot patch. The same situation applies to almost every software release (ie. Windows, Apple, Android). The problem using built in platform apps is you only can rewind to the previous release which is an all or nothing choice. When you run your own groovy code or any third party code for that matter you are not as vulnerable because nobody is tinkering with that specific app. YES, platform updates can effect third party apps, but much less often. Over the year and a half and many, mant platform updates there has only been one update that interfered with installed the third party code I run, which was fixed within hours. On SmartThings that happens more often but its the same story. There is a platform "improvement" and invariably the users of their "built in" apps are complaining of things not working anymore. It is that situation that caused me to leave SmartThings for Hubitat. Another SmartThings example is the depreciation of some of their built in procedures moving from the old classic model over to the new "improved" model. People using there built in solutions are forced into looking for alternative solutions. Or on Hubitat with the sunset of RM3 onto RM4. During that transition there was a fair amount of frustration from those used to the older ways.
Again, this isn't meant to be plug or a dig on anyone's preference, its just what I have learned since the beginning of the home automation boom, starting with SmartThings years ago, Having all the eggs in one basket may work for others but not for me. That is why I came to Hubitat and I'm sure there are quite a few others in the same camp.
You left out the part that a permanent means of using RM3 was provided as part of that transition, so that anyone who preferred RM3 could go on using it.
We allow you to roll back to 3 prior releases.
SmartThings was notorious for introducing new bugs in a release, and then never fixing them. I dare say, that is not what happens with Hubitat. We are responsive to bug reports and put out fixes asap.
Again, not attacking or criticizing. Its just the way it is. The more complex a software platform is, the more things that can go wrong. If something breaks, you fix it, that is why I am on Hubitat.for the reasons you outline. I am simply pointing out when updates are made, be it a hubitat platform (improvement) update, which can include any of its built in apps, and/or devices, things can go wrong. The most recent performance improvements have been remarkable. But my experience using non builtin apps has been less problematic. As I said before, of all the updates made in the last year and a half, only one time did it affect the third party app I was using. I know it goes against the grain and creates problems for support, but the way I see it, if things aren't broken then I'm not in need of support. The most important thing home automation needs to shoot for is consistency and stability. Now that the hub's performance no longer needs to be baby sat, Hubitat is well on the way to achieving that mark.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
