Should be much faster, especially if Parallel execution is turned (left) off for your piston
use Async http calls for http commands
should fix HSM command issue reported
Here is an updated webcore forked from the original in this thread.
It has quite a few changes, primarily to add pauses into long running pistons so as to not hang the hub.
This version is a bit faster in that a lot of parent/child calls have been removed, and several bugs fixed.
I also removed code for lifx, a lot of comments (that caused problems compiling/saving on hubitat).
While a noble goal to keep the source the same as ST, this is impractical because of sheer code size, and the inherent higher horsepower ST has running in the cloud (Pistons don't compete with each other as much as they do on hubitat).
Pistons that run a long time will automatically "be nice" and release the cpu so other things can run / operate.
As mentioned in other notes, it is a good idea to control your use of:
global variables - limit subscriptions (if you use multiple, see if you can subscribe to less variables for a trigger)
How many events a piston receives
avoid enabling parallel execution (in a piston, - this should not be needed normally) as hubitat has much less available CPU than a cloud. (and this is a big hog of hub resources)
I suggest you not enable log piston executions in the WebCoRE app as this adds a bit of overhead on the hub and database (this is a webcore setting; not a piston/code setting).
Control your use of logging, both in code in your piston, and in the dashboard when enabling logging on pistons. It is a good idea to leave it on "none" once you are done debugging to reduce load on the hub and the database. (I have thought about auto turning it down, but that may be a bridge too far for some)
Notes:
It is a good idea to reboot your hub before installing, and let it settle the db for a few mins.
The storage app is not used on Hubitat, so you can just not bother installing it.
You only need fuel stream installed if you enable local fuel streams.
@nh.schottfam or anyone, what might be generating this log message when sending to Pushover? Message makes its way through to Pushover but leaves that error.
@Ryan780 before I ask this question in the Webcore community I'll ask you here since we are running a slightly different version of WC
Why would this simple piston ignore the 15 second wait after the change to inactive? It's been months since I was doing anything with WC and I'm having to relearn everything.
I've played around with cancelation policy and could not cause a change. When I get rid of the wait that Ikea switch turns off the second inactivity is triggered.
To do that wait, webCoRE is going to hold the CPU for that time. Longer waits are scheduled differently. Why don't you try the trigger, INACTIVE for 15 seconds instead of putting a Wait in?
Something appears to be broken. I tried this simple loop; it works on ST WebCoRE (every 30 seconds the light turns on and 4 sec later turns off), but on Hubitat (with the latest patch) the light just turns on and stays on. This reminds me of an issue that I encountered very early on when WebCoRE was first ported to Hubitat. I'll try to dig into the forum posts to see if I can find out what the issue was (someone, not me, was able to fix it),
@Ryan780 your suggestion does work because it negates the need for a Wait. I was using that short 15 second time period for testing purposes.
@bobbles I'd already tried your suggestion and gave it another try this morning using a Wait. Even with TCP set to Never, once that motion sensor becomes inactive > True, WC begins counting and after 15 second or a 1 minute wait time that statement visually is no longer true but the switch does not go off.
It does look like a slightly different but similar circumstance to what @Tony gave an example of. I also followed the advice Tony got from a response in the thread he pointed to and > went to Piston Settings” screen, click cog, choose Command Optimizations and then choose Disable. That does not make a difference in how this piston responds to the Wait.
I'm good using Ryan's advice but would like to understand if how HT handles a Wait is different from how STs handles them. If this different method is part of optimization for running local on the Hubitat hub I'm all over that but we do need to make this clear to users. At the moment it's not.
Hmm. It should work.
Maybe something got screwed in the porting over to HE.
Why not just use something like this.
Ignore the set piston and the lux statements.
