The fact that devices are responding with variable delays (based on their physical location-- you said the last bulb responds instantly vs. the other two when you initiate the commands directly from the Hubitat user interface) makes me suspect that zigbee mesh or routing issues (or possibly something environmental) might be a factor.
As an experiment, if you change the piston to turn on the last light first (which responded quickest in your manual test) does it also turn on quickest when webcore initiates the turn on? If so then the variable delays you are seeing maybe because of the mesh-- there could be some MAC level retries going on to compensate for some data transmission problems in the mesh.
I have thought about the mesh problems and cannot 100% rule that out. Will put in a few more zigbee power outlets around the house to see if that helps.
I've found I get a delay if the hub has been rebooted and it can be 30s +. Then once it's worked it's then super fast! So I disabled command optimization on the piston, because I'm under the impression that ask's the device what state it is before the piston runs? That seems to have improved it but it still struggles a bit when It's been rebooted. But as I only have 2 devices on hubitat at the moment, that may also be something to do with it.
I've been having the same problem. I posted to the webcore forums about it:
Its driving me nuts. I moved some of my simplest pistons over to simple lighting and its now super fast, but most of my pistons are too complex for that.
also, just updated webcore in both hubitat and my server and i'm now getting this displayed on the webcore page:
A newer UI version (v0.3.105.20180628) is available, please hard reload this web page to get the newest version.
Thanks to all for keeping the Hubitat fork updated and to ady264 for his original code and his ongoing efforts. I could not do the Hubitat hub without WebCore.
I’ve now noticed that my rule machine rules have an intermittent delay also. I don’t know if this is a mesh networking problem, or if it is insufficient processing on the part of the hubitat. I’m wondering if a second hubitat setup as a slave on the other side of the house would be helpful.
Have been looking at the logs. It appears that webCoRE is getting a delay, at time of up to 7,000 ms when a motion changes to active state. On good times, it's about 100+ ms.
For this particular motion sensor, it is not part of any other piston and the only other app on Hubitat using it is the dashboard.
What's your opinion on why there is this massive delay and how can i troubleshoot further?
I rebooted the hubitat and that warning in webcore finally went away.
seems like my delays are getting worse the past few days for some reason. After the reboot it seemed a bit faster for a while, but that may have been in my head.
I have been completely swamped in the past few months, with a new job, moving to a new city and other life changes. As a result of this, I have been unable to do any kind of justice to the webCoRE thread, or the projects I was working on, when I started using Hubitat. I regret that there is so much needed on this project and yet, I have not been able to contribute to anything.
@jp0550 on the other hand, has been consistently doing a stellar job of rolling our numerous fixes and helping out the community with all their queries and I am really glad that the webCoRE effort didn't fizzle out after what I released initially. Hats off to his dedication and drive to help. I couldn't think of a better option than for me to take down the links to my GitHub repo and modify the OP to completely reflect his work, so that there is no need for him to push commits to me and wait for a merge.
I have messaged him to inquire if he is okay with this change. If he is, then I will make the needed changes. Until then, please be sure to use his repository for getting the latest version of webCoRE and not the one in the OP.