Patched webCoRE for Hubitat (2018/09/09)

community_app

#786

I'd like to echo what @ogiewon has said. I was heavily invested in webCoRE but have moved 95% of my pistons over to Rule Machine rules. It was tough but in the end my hub is responding a lot faster. If you do choose to keep any of your webCoRE pistons, I give you these pieces of Advice:

  1. Avoid all global variables. I've seen these begin to degrade system performance before of the resources required when they are updated.
  2. Avoid calls to other pistons. Keep all your functions tied into as few pistons as possible.
  3. Avoid device variables. These also seem to be a resource hog.

I have webCoRE running with 6 pistons, all of which have functions that Rule Machine cannot. All of the parse JSON data from a webrequest, which Rule Machine can't do. If I could code in Groovy, I'd write something to do it but alas, outside my scope of knowledge. So far I haven't had any system performance issues. Good luck!!


#787

I have an updated webcore that performs pauses if it runs more than a short time.

@putnamjwp is there a way to put this in your git?


#788

I assume you realise that if you have any issues with hub performance, the first thing you will be asked is ti uninstall webCoRE?


#789

Sure thing, if you open up a pull request on the git branch, I'll take a look.


#790

In my reading of all the notes:

Support may ask you to uninstall any 3rdparty devices or apps if you have a problem. So no need to focus on webcore - it is anything they don't provide.

Bruce suggested that pauses be inserted into webcore as that was what he had to do in rule machine. I just followed up on his suggestion.

No one is forcing anyone to run apps they don't wish to.


#791

That is very true.


#792

How is this working thus far? Nice to see some work done on this front!


#793

Here is an updated webcore forked from the original in this thread.

It has quite a few changes, primarily to add pauses into long running pistons so as to not hang the hub.

This version is a bit faster in that a lot of parent/child calls have been removed, and several bugs fixed.

I also removed code for lifx, a lot of comments (that caused problems compiling/saving on hubitat).

While a noble goal to keep the source the same as ST, this is impractical because of sheer code size, and the inherent higher horsepower ST has running in the cloud (Pistons don't compete with each other as much as they do on hubitat).

Pistons that run a long time will automatically "be nice" and release the cpu so other things can run / operate.

As mentioned in other notes, it is a good idea to control your use of:

  • global variables - limit subscriptions (if you use multiple, see if you can subscribe to less variables for a trigger)

  • How many events a piston receives

  • avoid enabling parallel execution (in a piston, - this should not be needed normally) as hubitat has much less available CPU than a cloud. (and this is a big hog of hub resources)

  • I suggest you not enable log piston executions in the WebCoRE app as this adds a bit of overhead on the hub and database (this is a webcore setting; not a piston/code setting).

  • Control your use of logging, both in code in your piston, and in the dashboard when enabling logging on pistons. It is a good idea to leave it on "none" once you are done debugging to reduce load on the hub and the database. (I have thought about auto turning it down, but that may be a bridge too far for some)

Notes:

  • It is a good idea to reboot your hub before installing, and let it settle the db for a few mins.

  • The storage app is not used on Hubitat, so you can just not bother installing it.

  • You only need fuel stream installed if you enable local fuel streams.


Community Apps
#794

Nice! I know that global variables and incoming HTTP calls (like from IFTTT) were my big problem. Every time a global variable changes it re-evaluates every piston that subscribes to ANY global variable. Change a GV 3 or 4 times and you can see what kind of mess you're going to end up with.
And the same is true of HTTP calls. Whenever an IFTTT trigger is received it re-evaluates every piston that subscribes to ANY IFTTT trigger.
An alternative for anyone looking to use webCoRE for limited functions is to install it in the ST cloud. I am running it currently and don't even have my hub plugged in. I'm able to use cloud links to the HE maker API and webcalls from RM to pass info/commands back and forth. Not the type of setup you'd want to use for basic automatons but highly custom functions that RM can't do yet, it works great for.


#795

@Ryan780 - I would like to message you but you have messaging turned off?


#796

For you guys and gals out there still using webCoRE, how are you finding it working.
Any issues?
If so, what are they.
Just wondering.


#797

@bobbles are you referring to @nh.schottfam's new build?


#798

Just webCoRE in general. I stopped using it months ago but was just wondering how people were finding it.


#799

I really want to know if any folks have started using the new 'pause included' version of webcore. I have made the move to RM, but miss webcore and there are a few things I have my ST hub still around as I can only handle it in webcore.

Very excited to see where this goes! Thanks @nh.schottfam


#800

I have not updated yet, as I am on the road. But I have webcore running for 2 pistons. One to set thermostat mode based on webcall and the other to do TTS notifications of upcoming events on my Google or Office 365 calendars. The rest I have moved back to my hubless ST setup. And I have no lockups or slowdowns that I can attribute to webCoRE.


#801

Still running about 20 WebCoRE pistons without problems. Not doing anything crazy (aside from a couple of global variables) but never had any lockups or slowdowns. Will try the new patched version soon.