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.
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.
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.
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.
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:
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.
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.
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)"
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.
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
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
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.
@jp0550
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 ?
