[DEPRECATED Thread: visit community.webcore.co for assistance] webCoRE - Piston Design Help (ask your fellow members for assistance)

@blinduvula what Ady said, but you also have to enable the grab bars first to move things around, using the <> in the top left.

You can reorder tasks from inside the task editor dialog. The dialog lists all the tasks before and after the current one, just click on the one you want to move away and make room

That seemed to take care of it!

1 Like

Here’s what I was thinking of. First piston manages some lights that have different behavior in 3 different modes. Modes are:

  1. Evening
  2. Movie
  3. Party

Mode switches from Evening to Party to Movie to Party to Evening. Let’s look at the captures:

  1. Mode switches from Evening to Party - Capture 1
  2. Mode switches from Party to Movie - Capture 2
  3. Mode switches back from Movie to Party - Restore Capture 2
  4. Mode switches back from Party to Evening - Restore Capture 1.

To do this with a global store and a local store, I could use the global store in step 1 and the local store in step 2 and back it out from there in steps 3 and 4.

Second piston, manages another set of lights based on settings of the lights controlled by the first piston when in Evening or Party mode. This piston will have access to the lights as they were set in the Evening mode because these are in the global store but not the lights as they were set in the Party mode as these are in the local store of the first piston.

Hence the ask for named stores. Happy to answer other questions.

Thank you.

Ha ha, request denied.

(gang of minions, he doesn’t probably know what that means, right?)

3 Likes

I’m having issues getting the Flash command to work with my Hue Lights since last week. I tested this out on a extremely simple piston but the flash works fine on my other bulbs but not on my Hue Color bulbs like it used to. I’m using tmleafs version of Hub B Smart so not sure if this is a webCoRE issue or issue with this custom Smartapp/Device Handler: [UPDATED 4/19/17] Hue B Smart (Smart and FAST Hue Lighting)

WebCore Logs:

6/12/2017, 10:24:33 PM +618ms
+1ms	╔Received event [Front Door Sensor].contact = closed with a delay of 782ms
+219ms	║RunTime Analysis CS > 21ms > PS > 98ms > PE > 100ms > CE
+230ms	║Runtime (32305 bytes) successfully initialized in 98ms (v0.2.0bd.20170612) (228ms)
+232ms	║╔Execution stage started
+253ms	║║Comparison closed is open = false (3ms)
+256ms	║║Cancelling condition #4's schedules...
+258ms	║║Condition #4 evaluated false (14ms)
+260ms	║║Cancelling condition #1's schedules...
+261ms	║║Condition group #1 evaluated false (state changed) (19ms)
+266ms	║╚Execution stage complete. (34ms)
+275ms	╚Event processed successfully (274ms)
6/12/2017, 10:24:32 PM +926ms
+3ms	╔Received event [Front Door Sensor].contact = open with a delay of 1098ms
+337ms	║RunTime Analysis CS > 125ms > PS > 111ms > PE > 101ms > CE
+381ms	║Runtime (32307 bytes) successfully initialized in 111ms (v0.2.0bd.20170612) (376ms)
+382ms	║╔Execution stage started
+403ms	║║Comparison open is open = true (3ms)
+406ms	║║Condition #4 evaluated true (12ms)
+407ms	║║Condition group #1 evaluated true (state did not change) (14ms)
+411ms	║║Cancelling statement #2's schedules...
+453ms	║║Executed physical command [Living Room Hue Light (by Front Door)].flash([2000, 2000, 5, null]) (26ms)
+455ms	║║Executed [Living Room Hue Light (by Front Door)].flash (28ms)
+459ms	║╚Execution stage complete. (77ms)
+471ms	╚Event processed successfully (471ms)

The door closes too fast and cancels the flash. Click on the with and click the options cog and set TCP to Never cancel.

I have a similar Piston that just stops working every once in a while. Pause/Resume works again

Rick

The parent app will eventually get a smart recovery module - ST misses time events once in a while.

I’m getting the same results changing TCP to Never Cancel. If I change this to my GE Bulbs or any of my switches, it works fine.

webCoRE logs:
6/12/2017, 11:00:59 PM +639ms
+1ms ╔Received event [Front Door Sensor].contact = open with a delay of 571ms
+202ms ║RunTime Analysis CS > 21ms > PS > 85ms > PE > 95ms > CE
+211ms ║Runtime (32295 bytes) successfully initialized in 85ms (v0.2.0bd.20170612) (209ms)
+213ms ║╔Execution stage started
+233ms ║║Comparison open is open = true (4ms)
+236ms ║║Condition #4 evaluated true (11ms)
+237ms ║║Condition group #1 evaluated true (state did not change) (14ms)
+241ms ║║Cancelling statement #2’s schedules…
+283ms ║║Executed physical command [Living Room Hue Light (by Front Door)].flash([2000, 2000, 5, null]) (25ms)
+284ms ║║Executed [Living Room Hue Light (by Front Door)].flash (28ms)
+289ms ║╚Execution stage complete. (76ms)
+297ms ╚Event processed successfully (298ms)

What happens if you do not close the door? The first example had you closing the door within one second, this example does not show the door closing

Well ady624, I thought I had my virtual switch issue resolved with your suggestion to use switch is on instead of switch changes to on. But this morning at sunrise, things didn’t go as planned.

On line #27, Dimmer 7 is my virtual switch. I also had to turn on the Always subscribe option for that line.

On line #42, sunrise is a trigger that should result in the two lights turning off. But since the virtual switch was in the ON position, it resulted in both lights turning on at sunrise (which was not my intention).

Do you have any other suggestions on how I can fix this piston?

Logs? Do you have any logs?

@ady624 o well. you did ask for real world benefit, so tried.

thanks for considering it. And denying it. :slight_smile:

I modified the piston so instead of trying to turn the lights off at sunrise, it should try turn them off at “368 minutes before sunrise” (or 11:29pm). I turned on FULL logs, turned both lights off, left the virtual switch on, and then waited for 11:29pm. The piston ran and my lights turned on instead of staying off. Here are the logs:

‎6‎/‎12‎/‎2017‎ ‎11‎:‎28‎:‎59‎ ‎PM +91ms
+1ms
╔Received event [My Home].time = 1497328140000 with a delay of -910ms
+160ms
║RunTime Analysis CS > 22ms > PS > 84ms > PE > 54ms > CE
+174ms
║Runtime (33953 bytes) successfully initialized in 84ms (v0.2.0bd.20170612) (170ms)
+177ms
║╔Execution stage started
+223ms
║║Comparison :b0877b20e8cfd015291ae908f0c75159: is_not :12b020925300bb83870c0f79587caf29: = true (12ms)
+227ms
║║Condition #1 evaluated true (33ms)
+230ms
║║Condition group #null evaluated true (state did not change) (36ms)
+265ms
║║Comparison off is off = true (5ms)
+272ms
║║Comparison off is off = true (4ms)
+277ms
║║Cancelling condition #16’s schedules…
+279ms
║║Condition #16 evaluated true (39ms)
+314ms
║║Comparison 1497328139372 happens_daily_at 1497317220000 = false (1ms)
+317ms
║║Condition #17 evaluated false (35ms)
+319ms
║║Cancelling statement #17’s schedules…
+329ms
║║Requesting time schedule wake up at Tue, Jun 13 2017 @ 8:12:00 PM CDT
+333ms
║║Condition group #15 evaluated false (state did not change) (94ms)
+350ms
║║Comparison on is on = true (3ms)
+352ms
║║Condition #19 evaluated true (16ms)
+354ms
║║Condition group #18 evaluated true (state did not change) (18ms)
+355ms
║║Condition group #12 evaluated true (state did not change) (120ms)
+360ms
║║Cancelling statement #13’s schedules…
+430ms
║║Executed physical command [Bedroom Light].setLevel([20]) (61ms)
+431ms
║║Executed [Bedroom Light].setLevel (63ms)
+495ms
║║Executed physical command [Upstairs Hallway Light].setLevel([20]) (62ms)
+496ms
║║Executed [Upstairs Hallway Light].setLevel (64ms)
+522ms
║║Comparison turningOn is on = false (4ms)
+525ms
║║Cancelling condition #24’s schedules…
+527ms
║║Condition #24 evaluated false (22ms)
+528ms
║║Condition group #23 evaluated false (state did not change) (25ms)
+530ms
║║Condition group #20 evaluated false (state did not change) (27ms)
+540ms
║╚Execution stage complete. (364ms)
+542ms
║Setting up scheduled job for Tue, Jun 13 2017 @ 8:12:00 PM CDT (in 74580.368s)
+559ms
╚Event processed successfully (558ms)

Here’s logs of open and close events listed below. It does show like it’s executing the flash command but none of my hue lights do anything when flash command executes.

6/12/2017, 11:01:00 PM +733ms
+3ms ╔Received event [Front Door Sensor].contact = closed with a delay of 660ms
+608ms ║RunTime Analysis CS > 49ms > PS > 414ms > PE > 145ms > CE
+620ms ║Runtime (32306 bytes) successfully initialized in 414ms (v0.2.0bd.20170612) (615ms)
+621ms ║╔Execution stage started
+654ms ║║Comparison closed is open = false (9ms)
+657ms ║║Condition #4 evaluated false (21ms)
+660ms ║║Condition group #1 evaluated false (state did not change) (24ms)
+665ms ║╚Execution stage complete. (44ms)
+673ms ╚Event processed successfully (673ms)
6/12/2017, 11:00:59 PM +639ms
+1ms ╔Received event [Front Door Sensor].contact = open with a delay of 571ms
+202ms ║RunTime Analysis CS > 21ms > PS > 85ms > PE > 95ms > CE
+211ms ║Runtime (32295 bytes) successfully initialized in 85ms (v0.2.0bd.20170612) (209ms)
+213ms ║╔Execution stage started
+233ms ║║Comparison open is open = true (4ms)
+236ms ║║Condition #4 evaluated true (11ms)
+237ms ║║Condition group #1 evaluated true (state did not change) (14ms)
+241ms ║║Cancelling statement #2’s schedules…
+283ms ║║Executed physical command [Living Room Hue Light (by Front Door)].flash([2000, 2000, 5, null]) (25ms)
+284ms ║║Executed [Living Room Hue Light (by Front Door)].flash (28ms)
+289ms ║╚Execution stage complete. (76ms)
+297ms ╚Event processed successfully (298ms)

Is it really necessary to have the conditions be so drastic? You want them off at sunrise, right? Why only turn them off IF they are ON and IF they are at 20%? Why not just turn them off? The problem is the bulb says its switch is “turningOn”, not “on”, which is not according to standards. So the problem is with the hue bulb, the switch attribute never became “on”.

Can you please NOT close the door right away? What happens then? Leave the door open for say 10 seconds…

has something been changed in the last update to do with the “changed in the last” condition?
I have pistons set to use the “changed in the last” condition and they have worked exactly as expected up until last night after I updated to the current version v0.2.0bd. now whenever i check the TRACE it shows that the most recent trigger doesn’t update the Changed in the last count but the second trigger of the same piston does?

Is there an option anywhere to use something like “changed to ON in the last” or “Changed to OFF in the last”

appreciate all the help by the way :slight_smile:

I’ll try tonight when i get home, i did try that already before setting TCP to Never Cancel but don’t have the logs for that incident.