Patched webCoRE for Hubitat (2018/09/09)

community_app

#547

There ultimately is no way that running an app on an interpreter (webCoRE) on top of another interpreter (Groovy) can be as fast as running directly on Groovy. Pretty much this is just laws of computer physics.

We definitely recognize the appeal of webCoRE, and reasons that people want to continue to use it. My suggestion is that you should identify those of your pistons for which response time is important to the experience of the automation, and those where it is not so important. Motion and contact sensor based lighting automations in particular have very critical timing due to the sensitivity of human senses. A typical Motion Lighting app instance runs in about 70 msecs, start to finish.


Hub has ground to a halt. Extremely slow
#548

Looks like it's the piston itself rather than the hub, looking at the semaphore, that means the piston had to wait for 8 seconds because it was already running so it had to wait for the other one to finish. Your timings otherwise look normal. I'll pull it in and see if I can improve it. The webcore forum also has some tips for piston design.


#549

No worries. I'm already going to take @bravenel's advise.
I'm also going to change it to 2 separate statements of 'changes to' to see how it behaves.
Thanks for looking though.


#550

I performed a similar test with a light automation this morning. Comparing Simple Lighting to webCoRE. I saw no differences between the two, although a "very" slight delay on both too. I put this down more to the ST motion sensor, rather than the execution itself. I saw no errors or delays in logging for both.


#551

I pulled it in and the biggest thing I saw as that the piston was having to fire immediately back up when the light changed for the second if statement.

In the future with other pistons if you see semaphores like that try separating it into two pistons instead so it's not competing with itself:

Code mhb24

Code habvm
image

|+1ms|╔Received event [Garage Door Contact].contact = closed with a delay of 1215ms|
|+211ms|║RunTime Analysis CS > 151ms > PS > 45ms > PE > 15ms > CE|
|+218ms|║Runtime (48524 bytes) successfully initialized in 45ms (v0.3.107.20180806) (217ms)|
|+218ms|║╔Execution stage started|
|+221ms|║║Comparison (enum) closed changes = true (0ms)|
|+222ms|║║Condition #2 evaluated true (2ms)|
|+222ms|║║Condition group #1 evaluated true (state did not change) (2ms)|
|+225ms|║║Comparison (enum) closed is (string) open = false (0ms)|
|+225ms|║║Cancelling condition #12's schedules...|
|+226ms|║║Condition #12 evaluated false (2ms)|
|+226ms|║║Cancelling condition #11's schedules...|
|+226ms|║║Condition group #11 evaluated false (state changed) (3ms)|
|+227ms|║║Cancelling statement #15's schedules...|
|+245ms|║║Executed physical command [Garage].off() (14ms)|
|+245ms|║║Executed [Garage].off (15ms)|
|+247ms|║╚Execution stage complete. (29ms)|
|+248ms|╚Event processed successfully (247ms)|


#552

If you're wanting to try it out, you don't have to set up an raspberry pi instance, that's only for a local dashboard instead of dashboad.webcore.co and has a few features like local fuel streams and fixes for piston execution links.

Though, the main site will probably get those as well when Hubitat's version gets merged back into the main codebase.


#553

Just arrived here at Hubitat... I gave Rule Machine a few goes but I am so used to webCoRE that I just installed it. Haven't done too much testing but I hope I can continue to use it as my primary rules engine... I really hope it becomes official, or Rule Machine evolves into it's final form and can give webCoRE a good run for it's money.


#554

I did that, as the instructions recommended but I still get the log message... I have much testing to do to see how slow operation truly is.


#555

Very odd, as I get it a couple of times after creating a new Piston, do the "done" thing, and don't see it again.


#556

It will show one more time after updating it to "Done." If you don't do it, it adds about ~150ms to the piston's runtime and you'll see a log saying something like "Grabbing device from parent...(150ms)"


#557

Ah thanks! I cleared the logs to see if it keeps appearing.


#558

Sorry so, where is the guide for the none RPI install? Is there a simple guide/video on doing this? I found few but all for ST


#559

@coops8d Just follow the in stall instructions at the top of the thread.


#560

It's very similar to the manual install for smartthings described here. Paste all your code for the 5 apps in the apps code section in hubitat, enable oath for the main webcore app, go the apps section and click load new app, and click Webcore to go through the install process.


#561

Thanks mate, yeah I have never installed an app on HE, so was not sure. But just worked it out about 5 mins ago :stuck_out_tongue:


#562

Today I was just trying to get back into my webCoRE dashboard for my hubitat (not running dashboard locally, just using regular cloud site), but it seems to be refusing to cooperate. All I see in the Logs view for webCoRE is:

error Dashboard: Authentication failed due to an invalid token null

logged each time I try to access the dashboard.

I don't recall changing anything with webCoRE in the past few days, and I'm running hubitat fw 1.1.3.116


#563

Hubitat's cloud timeout is around 15 seconds. Sometimes if the the dashboard hasn't been loaded in awhile and you're starting fresh, it can go over this limit. It took me 2-3 times for it to load the first time after clicking dashboard and it worked fine after that.

I also found a bug today where if the registration fails (looks like there is a cert error on the webcore api instances) the endpoint will not update to the cloud url, and will stay on a custom url if you've used it in the past. If that is your issue, you need to update your webcore.groovy file to the latest and click "Done" on the webcore settings page for it to reset the endpoint to Hubitat's clould link. You can verify it worked by clicking the little blue "i" next to the main webcore instance and looking for the "endpoint" variable. It should start with cloud.hubitat.com

image


#564

I've updated my instance and did as you say. I wonder if Hubitat is having some issues with their cloud servers, I'm getting 502 errors when opening a piston. The dashboard loads slowly, and I do get a 502 error there too, but it does load. I'm not running the dashboard locally.

webCoRE.min.js:110 GET https://cloud.hubitat.com/api/-removed-
net::ERR_ABORTED 502

My endpoint matches yours:

image


#565

@putnamjwp
Wouldn't be better to compile as groovy and present it to the user to paste as a app ? What's the difference between compiling on the hub then doing it this way ?


#566

What have peoples expirance been going from web based Webcore to locally hosted? Much of a speed improvement?