@furom @mailtomatte @dJOS and others.
No. No. No. It is not cloud dependent.
The pistons are stored and run locally on your hub. Defining/editing/deleting is done on the webCoRE server or you can, as I and others have done, use an RPi or the like to do this.
5 Likes
I thought the same, as weCore is webbased, on most platforms. For HE you can run WC on the hub. I don't use it I opted for NR, but I do agree with some of what is here (which is why I went to NR). I to wish RM could be streamlined, and someday it may be. Maybe even add NR local support 
1 Like
Well you could get rid of the if statements completely. It will only run the action if it changes to night mode and you don't need the if open. If it's closed after 15 mins it just won't do anything, otherwise it will close it.
If you want to base the close on how long the door has been open. You could setup up a global Boolean. In a separate rule have it set the the variable true when the door opens and then set it false after 15 mins. Then if the door is open and the boolean is false close the door immediately. Have another rule that if global changes to false and mode is night close. the door. Rules are free.
I am sure the are other ways to do this as well,
Couldnāt agree more with the op.
As a casual user who doesnāt want to mess with the system much I find working with RM extremely painful. What blows me away is the displayed output is so simple and basic. What I would give for a text editor and a compiler!
Even something as basic as the Arduino IDE would be welcome.
3 Likes
Ah fair enough. I really donāt want to Be relying on an external ārule Machine ā as my C7 is now my home security system (HSM is a great feature)
I think the confusion starts when all the defining/editing/deleting is done on the webCoRE server by default.
People then assume the pistons have to run on the cloud.
I was an early adopter of webCoRE on ST and did a lot of testing with Adrian, who's baby this is, and really got into it.
Being an old git I just find it easier to use than RM.
I still have some RM rules which are easier to do than on WC.
Ironically without Bruce and RM, there probably wouldn't be WC.
Bruce introduced RM on ST because the apps at that time were very basic to say the least, only to find ST implying, I think, that it was causing issues with peoples hubs on ST. Personally, it worked for me with no issues.
Bruce decided to leave ST and this left a hole and CoRE then webCoRE came along to replace it.
Another great thing is if you look at my piston in post 10 above, you will see a code.
You can use this to import this piston and then define your own devices and tweak as you see fit.
There was a lot of sharing of pistons in the early days.
5 Likes
Is the scope of a global variable hub-wide, or just within the RM system?
webCore on ST runs in the cloud, but on HE it runs local. Default is to use the cloud for editing rules, but you can set up a local device (many people use an RPi).
Edit: See that others have responded in kind, and you have already taken note. Cheers.
1 Like
This is a 100% subjective observation as me a 41 year old D- high school graduate left Vera solely because creating the automations (first with PLEG then with Reactor) was extremely too complicated.
It's very disingenuous for you (after only 2 weeks) to claim it's too complicated when what you are using to compare it to you've probably spent a year or more learning it.
Here is my "Thermostat Rule" which took me less than 5 minutes to create. Just one single page that fits into one single screenshot.
5 Likes
Iām not sure there is a distinction, but the globals are for use with RM.
You can, however, create a connector and use the global outside of HE. I actually use a change to RM global variable to trigger a webcore piston.
1 Like
I haven't tried it, but there is anther Node-esq project for HE being built and usable now that allows you to use Typescript or JS to build rules with HE:
1 Like
It's no secret that the RM UI leaves something to be desired, but to be fair to the Hubitat devs, they are working with a UI framework that they more or less didn't design (it's a near clone of the SmartThings SmartApp UI model, which was designed to show UIs on mobile devices since that is the only way to do this on that platform). RM 4 is quite a bit more powerful than earlier versions of RM, though some things may require a few more clicks than they did before. The tradeoff is great power. Staff have mentioned that they are not totally opposed to a UI framework revamp, but this is unlikely to be a priority for them at the moment, and even then, RM would likely not be one of the first beneficiaries (though it does probably push the limits of this UI framework the most).
I suspect that some of the comments on RM result from simply not being used to it. I don't doubt that Reactor on Vera is great, but honestly, from watching the video and looking at the screenshots for a few minutes, I seem about as confused as some people say they are with RM inititally. 
(I can say that I tried Vera back when PLEG was the closest alternative suggested for this purpose, and I left, though by no means for just for that reason.) There are lots of docs and examples (examples, examples, examples forum tag) for RM, and looking at some of those is likely to be helpful. Giving it time to get used to many also help.
PS - I'm not sure all of what that thermostat "rule" does, but Thermostat Manager built-in to Hubitat may help. Unlike a lot of other platforms I've played with, Hubitat has a lot of pre-built "apps"/automation templates to handle common tasks, reducing the need to write custom logic for everything in the first place.
PPS:
There are actually delays and waits, which behave in slightly different manners, but depending on what you want, either can be used to create this effect. The suggestions above are one way but may require two rules (which there is nothing wrong with). Within a single rule, something like this will do something if the door stays open for 15 minutes, for example:
Trigger: Door changed
Actions:
IF (Door open) THEN
Delay 0:15:00 (cancelable)
// Do things
ELSE
Cancel Delayed Actions
END-IF
Alternatively:
Trigger: Door open
Actions:
Wait for event: Door closed --> timeout 0:15:00
IF (Door open) THEN
// Do things
END-IF
The biggest difference (besides the fact that "Wait"s are generally intended to respond to events or conditions and not just durations) is that delays must be explicitly cancelled, whereas in-progress Waits are cancelled any time a trigger matches (and in any case, when a trigger matches, the rule begins running from the top).
These are just a couple other ways you could approach the same problem.
PPPS - All of your IF THENs appear to be missing END-IFs. Harmless if it's the last thing but would start to matter if you nest or have additional actions afterwards.
10 Likes
You're not alone. I find RM to be a weak spot in the Hubitat platform, and not only for the reasons you stated. I eventually decided to try out Node RED (somewhat begrudgingly, due to it being off-hub). I'm loving NR now, and I've moved just about all my rules over to it. I do wish I didn't need to run another device (RPI 4) for the purpose, but I'm happy with the results and performance.
3 Likes
I am using WebCoRe for ST and have just (for reasons which should be obvious) purchased an HE. It's on its way. I was reading through some WebCoRe commentary from 2018 and getting it to run on HE did not seem all that trivial. Is there easier integration now?
Mostly just copy the piston from the ST instance to the HE instance. The only thing I had to change in my pistons was for my buttons, as they work a bit different in HE than ST.
You can load Webcore using the package manager. So that is easy as well.
2 Likes
First of all, welcome to the HE community.
Super easy.
The first thing I would do is install the app (not built in) Hubitat Package Manager.
This is a custom app developed by a HE user which makes it easy to install custom apps and drivers built by users of HE.
You can the install webCoRE through HPM.
With HPM you can then receive notifications of any updates to these apps and drivers that you install or even update them automatically should you wish.
Once WC is installed you just use it as you did on ST.
Instead of using the WC server you can install it locally on an RPi or something similar which keeps defining/editing/deleting pistons all local.
All pistons run locally on your HE hub with, for me anyway, no issues.
Well that certainly is appealing. It's pretty cool that the pistons run locally on the hub, too. Defining, editing, deleting pistons doesn't need to be local for me. If my Internet connection goes down I can forego administration as long as they still work.
I'm a recovering Wink user who escaped to ST and then realized I had exchanged ridiculously horrible for just very sucky, so I am looking forward to HE. I don't suppose there's a device migration tool by any chance?
If you mean from ST to HE, I'm afraid not.
What you can do though is leave your devices on ST initially or as long as you want and then use an app called HubConnect to link your HE and ST hubs together.
Make HE the server and ST the client.
Copy/sync your ST devices on to HE and run all automations on HE.
This way everything runs locally (apart from cloud based integrations like Alexa and Google).
You can then, if you wish, gradually migrate your devices to HE and then when complete, turn off your ST hub.
Some people leave it on though as there are some things that do run better on ST than HE.
