Patched webCoRE for Hubitat (2018/09/09)

Hubitat does not support sendNotification type commands.

I'll post a new version that puts an error in the log for these un-supported commands the the HE platform does not support.

No, it doesn't. But it does support deviceNotification commands, which is what I said.

1 Like

nh saw what I'd selected in error to cause that. In that piston I chose the proper selection for one push and the wrong one for the second push.

1 Like

@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.

What am I forgetting?

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),

Edit: I encountered this behavior before (last March, when WebCoRE was first ported) as described in this post:
Using webCoRE with Hubitat

Set TCP to never in your second statement.
The reason being your inactive trigger will turn to false after around 10 seconds.

@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.

Just spotted what you may be doing wrong.
The TCP should be against the WITH statement NOT the IF as in my example above.

Tried that suggestion @bobbles and no luck. I also can't go back and get @Ryan780 suggestion to work again.

You have a trigger for the active statement and a condition for the inactive statement.
Try changing it to changes to.
IF you look in the left column you will see the lighting bolt.

At this point something is broken @nh.schottfam. This simple setup is not working under any of these recommended methods. Both Ifs are triggers and this is as basic as it can get.

It's because of the modified webcore.

Just defined this piston and the light turns off after 30 seconds.
Working for me.

Thanks for that effort @bobbles. I think this is a duplicate of yours and still no lights off.

Yeah. Looks the same.
What version are using?
I downloaded this about a week ago I think.
Unfortunately there is no version statements to tell you when it was last updated.

Brand new piston and same result.

Is there anything in the logs.
Could it be that it is telling the light to turn off but the light is ignoring it.
Just trying to explore all the avenues.

BTW. When you have the piston open does the trace go green for the active and then change to green in the inactive statement with a countdown timer counting down against the wait statement?