Did a fix for the issue with global variable values makes its way to the code on github yet?
After the recent issues I decided to move everything back to HE and run the majority of things using around 90 pistons.
Before doing this I had most things running on HE RM.
I have noticed that things run significantly slower on webCoRE than the native HE apps.
I have been through every piston on the HE hub and clicked DONE but this doesn't seem to make much difference for me.
Anyone else seeing noticeable delays when using webCoRE on HE?
PS. I am at the latest version for all the webCoRE apps.
(My guide for timings is a cupboard door opening and a light coming on/off when contact sensor opens/closes).
How are people finding webCoRE vs RM? Is it worth the effort of setting up RPI and installing this?
Can you turn your logging on to full for that piston and post a sample? Having the green snapshot would help as well. It could be the piston itself, or there might be multiple subscriptions to that event slowing it down. If it's simple enough, it might be worth moving over to the simple lighting app as there isn't a lot of overhead for getting it to run there if speed is what you want.
These are my timings with around 50 other pistons running:
| +0ms | ╔Received event [Closet Contact Sensor].contact = closed with a delay of 85ms |
|---|---|
| +191ms | ║RunTime Analysis CS > 116ms > PS > 56ms > PE > 20ms > CE |
| +208ms | ║Runtime (48681 bytes) successfully initialized in 56ms (v0.3.107.20180806) (207ms) |
| +210ms | ║╔Execution stage started |
| +215ms | ║║Comparison (string) :816f38e28cdd1fd8454ef8a81aaf909f: is_not (string) :80ff8adc87cc6d0d790b1bb31708f282: = true (1ms) |
| +217ms | ║║Condition #8 evaluated true (4ms) |
| +219ms | ║║Condition group #1 evaluated true (state did not change) (6ms) |
| +222ms | ║║Comparison (enum) closed changes = true (1ms) |
| +224ms | ║║Condition #2 evaluated true (3ms) |
| +228ms | ║║Comparison (enum) closed is (string) open = false (1ms) |
| +230ms | ║║Cancelling condition #3's schedules... |
| +231ms | ║║Condition #3 evaluated false (6ms) |
| +233ms | ║║Cancelling condition #1's schedules... |
| +235ms | ║║Condition group #1 evaluated false (state changed) (14ms) |
| +237ms | ║║Cancelling statement #6's schedules... |
| +256ms | ║║Executed physical command [Closet].off() (15ms) |
| +258ms | ║║Executed [Closet].off (17ms) |
| +261ms | ║╚Execution stage complete. (50ms) |
| +276ms | ╚Event processed successfully (275ms) |
OK. Here is the piston.
And the logs for the door closing. With HE the light is off before the door is fully closed. With webCoRE it is sometimes after the door is closed.
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.
1 Like
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:
Code mhb24
Code habvm
|+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)|
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.
1 Like
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.
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.
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.
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)"
Ah thanks! I cleared the logs to see if it keeps appearing.
2 Likes
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
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.
1 Like
Thanks mate, yeah I have never installed an app on HE, so was not sure. But just worked it out about 5 mins ago 
2 Likes
