Have you enabled custom endpoints?
If so, you are running locally. If not, you are using the webCoRE server.
No, I've not done any of that.
I'm hosting dashboard locally on my RPi and I totally forgot about doing the git pull on it (actually hadn't updated WC on Hubitat in months before putting the patched code in a couple of days ago).
Quite sure my test scenarios were working previously; so I reverted the WC app code on Hubitat to the pre-patch version; now I am getting the "There was a problem loading the dashboard data" error. Not having any luck getting past that right now...
That is only for editing. Your pistons are all resident on your HE hub.
You don't have to...that just means you'll use the cloud editor and the cloud endpoints for accessing the hub. The pistons will all still execute locally.
Well, this is all very strange.
Just changed the settings on my webCoRE instance on my HE to use the webCoRE server not my local RPi.
I'm using the code that I downloaded 8 days ago.
Went into the piston and edited it.
My piston that I set up earlier still works OK.
Anyone want my code? 
Ultimately, using a wait in this scenario is wrong anyway. You want to use the trigger that motion stays inactive for 15 seconds because the cancel is built in. With the wait you have to have the cancel policy set to allow for cancels, otherwise if motion goes active, the light will still turn off.
Yes I know. The code on the server though will be different than on the HE hub as it has been modified to run for HE. (As has the code that I run on my RPi).
Just wondering if that could be the issue, hence my testing using both above.
Just trying to find a solution for people.
The solution is to not use a wait in this situation because it's the wrong way to write the piston.
Lots of ways to skin the cat 
in webCoRE and off the top of my head I can think of at least 4 do to the job that was asked and they will all give the right result.
In this case, the way you described it, to have the cancellation policy set to never, even if motion went active within the 15 seconds, the lights would turn off. You can skin the cat however you want but with this piston you're going to be doing it in the dark.
1 Like
TBH I would never write the piston the way it was done originally.
This is not the issue though. The turn off command is not being sent after the wait command has matured.
Just gave your method a try @Ryan780 and this light came on instantly with motion. It took 15 seconds for the ST Motion sensor to go inactive then per the piston it counted down 10 seconds. That second If had been true for 10 seconds and then it went to false and that light did not change to Off.
I'd also tested this same type of piston using motion and a push notification using Pushover. Same thing happened in that test. 10 seconds of inactivity and then no push notification.
Maybe you can spot something in the log as to what's happening.
1 Like
Look between Execution stage Started and Execution stage Executed.
There should be 2 lines stating light has turned off.
As I said above, Look at my logs.
Hi
I do see there is a problem - have not found it yet.
As others have reported, the version as of Feb 21st does seem to work properly for these cases.
I suggest folks need to roll back to this version while I find the problem.
Select "History" in upper right
scroll down to Commits on Feb 21st
Select the Number next to the commit, and then "View File", then raw to copy and paste.
This would be 3 files of that date. Sorry for the troubles/hassle.
3 Likes
check the edited link above/below
Did webcore change repo's again ?
OK folks.
I've been doing some testing as my pistons work and others do not.
I just updated to the code from the link in the post above and now my pistons do not turn off the light.
From the logs no 'off' command is sent.
There is a bug in the above code.
Hi @bobbles
It would be good for you to enable private messaging so I can see your issues. I don't want to work individual issues that wastes others time in the forum.
