Need Help

So RM has been getting me about 80% of where I want to be after I ditched ST+WebCoRe. I know HT has webcore, but I am not wanting my rules and notifications dependent on a cloud server.

So I have a notifier that when any door lock status changes, it sends '%text%. %date% %time%.' on our phones. The date & time is there since Android push notifications display time it decides to notify, not when HT created the notification.

What I did with Webcore previously was to status all of the locks at the same time. So for example, "Front Door was locked. Side door and Back Door still unlocked. 1/14/2020 12:15 PM". Webcore would allow me to essentially print out / display an array that was created by devices still unlocked.

In HT, notifier and RM are seperate rate apps. I was going to try and stash all unlocked door names into a global variable when a door lock changes and the call that in the notifier, but 1) I don't understand how to do that and 2) I doubt I have control on which app runs first when a trigger happens.

Thoughts? Suggestions?



You can call a notification in RM as well. Notifier is just a simple app designed to make easy notification rules.

Also... Around here we use HE (Hubitat Elevation) :yum:

1 Like

Autocorrecting from the phone split the word on me.

I didn't notice the notification options on RM. Ops. I still don't know how to collect up states in the same rule.

I did just find out that although the interface is in the cloud, webcore pistons are stored and ran locally. This is going to be what pushes me to move back to webcore.


Not sure what an up state is but in general RM can handle this.

Your trigger would be if any lock was * changed *

Then your conditional action (if/then) would check to see the state of each lock and send a notification if unlocked.

Collect the states of the devices. So if any device lock changes, trigger the rule. The action would need to be to store all devices in an unlocked state to a variable such as presently_unlocked. The send a notification that states '%text%. %presently_unlocked% still unlocked. %date% %time%.'. This allows me to report the current state change of the device that triggered the rule AND report on any devices that are still in the unlocked state in a single notification. It's great for when you lock a door and the app quickly pushes a notification that other doors are still unlocked.

I think you can run Webcore on a local server not the cloud... I did that early on but the HE hub performance with WC was really bad and it crashed frequently. I understand it's much more stable now thanks to the hard work by @nh.schottfam and others.

Given the odd resource issues we've been having natively I'd be hard pressed to add it back in even though I really like the interface.

Oh man. This is going to suck me in!

I know right? Soo tempting.

Just be careful though the folks at HE will not provide support if WC is installed - it's been too much of an ongoing pain for them I think.

You might consider (apologies in advance) getting another hub for these kinds of services and apps and keep it separate from your main device hub. I have 3 - an upstairs hub (devices/local apps & rules), a downstairs hub (devices/local apps & rules) and a controller (cloud/services) hub. I use an awesome custom app called HubConnect to link them..

webCoRE has always run pistons locally on the Hubitat hub. Only the webCoRE editor runs in the webCoRE cloud.

You can run the editor locally as well, but that does not impact the performance of running the webCoRE pistons whatsoever.

As others have mentioned, webCoRE has been known to degrade the Hubitat hub's performance, so YMMV. I moved everything over to RM and the built-in Hubitat Apps when I moved over from ST 2 years ago.


You can get the latest information here:

Much of the above information is out of date.


@Frank_XLT I think the newest webCore update processes all webCore pistons locally. Please correct me if I am wrong.

It does run all pistons locally, and is pretty fast based on my testing and other folks reports.