Are there any loops?


#21

Here’s an example of what I mean. Switch 1 & Dimmer 13 were supposed to turn on but never did. How come? Is it bec “sceneActive” was false at 6:07? Or can it be that because Dimmer 10 or 11 were turned off before 10 mins? Or is it something else?

This should help explain what I mean:

Logs:
11/8/2018, 6:00:51 AM +192ms
+1ms ╔Received event [Master Bathroom].switch = off with a delay of 65ms
+122ms ║RunTime Analysis CS > 17ms > PS > 88ms > PE > 17ms > CE
+124ms ║Runtime (39671 bytes) successfully initialized in 88ms (v0.3.108.20180906) (122ms)
+125ms ║╔Execution stage started
+147ms ║║Comparison (enum) off changes_to (string) on = false (0ms)
+149ms ║║Cancelling condition #9’s schedules…
+150ms ║║Condition #9 evaluated false (12ms)
+152ms ║║Cancelling condition #8’s schedules…
+153ms ║║Condition group #8 evaluated false (state changed) (16ms)
+158ms ║╚Execution stage complete. (32ms)
+160ms ║Setting up scheduled job for Fri, Nov 9 2018 @ 5:00:00 AM EST (in 82748.649s), with 1 more job pending
+170ms ╚Event processed successfully (170ms)
11/8/2018, 5:59:59 AM +338ms
+1ms ╔Received event [Home].time = 1541674800000 with a delay of -662ms
+186ms ║RunTime Analysis CS > 23ms > PS > 137ms > PE > 26ms > CE
+189ms ║Runtime (39671 bytes) successfully initialized in 137ms (v0.3.108.20180906) (187ms)
+190ms ║╔Execution stage started
+216ms ║║Cancelling statement #13’s schedules…
+225ms ║║Executed virtual command setVariable (3ms)
+230ms ║╚Execution stage complete. (40ms)
+233ms ║Setting up scheduled job for Thu, Nov 8 2018 @ 6:07:16 AM EST (in 436.733s), with 2 more jobs pending
+242ms ╚Event processed successfully (242ms)
11/8/2018, 5:57:16 AM +77ms
+2ms ╔Received event [Master Bathroom].switch = on with a delay of 121ms
+175ms ║RunTime Analysis CS > 35ms > PS > 122ms > PE > 17ms > CE
+178ms ║Runtime (39680 bytes) successfully initialized in 122ms (v0.3.108.20180906) (174ms)
+179ms ║╔Execution stage started
+200ms ║║Comparison (enum) on changes_to (string) on = true (1ms)
+202ms ║║Cancelling condition #9’s schedules…
+203ms ║║Condition #9 evaluated true (13ms)
+209ms ║║Comparison (boolean) true is (boolean) true = true (2ms)
+211ms ║║Cancelling condition #10’s schedules…
+212ms ║║Condition #10 evaluated true (8ms)
+213ms ║║Cancelling condition #8’s schedules…
+214ms ║║Condition group #8 evaluated true (state changed) (25ms)
+217ms ║║Cancelling statement #15’s schedules…
+224ms ║║Executed virtual command [Kitchen 1, Office].wait (0ms)
+225ms ║║Requesting a wake up for Thu, Nov 8 2018 @ 6:07:16 AM EST (in 600.0s)
+233ms ║╚Execution stage complete. (55ms)
+236ms ║Setting up scheduled job for Thu, Nov 8 2018 @ 6:00:00 AM EST (in 163.688s), with 2 more jobs pending
+247ms ╚Event processed successfully (247ms)
11/8/2018, 4:59:59 AM +134ms
+1ms ╔Received event [Home].time = 1541671200000 with a delay of -866ms
+158ms ║RunTime Analysis CS > 20ms > PS > 108ms > PE > 29ms > CE
+161ms ║Runtime (39680 bytes) successfully initialized in 108ms (v0.3.108.20180906) (159ms)
+163ms ║╔Execution stage started
+188ms ║║Cancelling statement #2’s schedules…
+197ms ║║Executed virtual command setVariable (4ms)
+204ms ║╚Execution stage complete. (41ms)
+207ms ║Setting up scheduled job for Thu, Nov 8 2018 @ 6:00:00 AM EST (in 3600.66s), with 1 more job pending
+216ms ╚Event processed successfully (216ms)


#22

Here’s how I would do it… Stop using the “sceneActive” as a restriction and just use real restrictions (Only When):

I also set the Task Cancellation Policy to “never” (denoted by the “N”) on the WITH statement.

It reads as follows:
If either Dimmer 12 or Dimmer 13 turns on between 5-6am, then wait 10 mins from that event and turn on Dimmer 14 and Dimmer 15.


#23

Regarding the “real restrictions”, will it cause the piston to stop running through it’s code if the restriction is true (meaning that the piston’s actions aren’t wanted at the time)?

I’m just nervous about having so many pistons running every time a switch is flipped. For example the original piston is only active a few hours a week. (I only want it to run based on a specific $locationMode (which is controlled by a SmartApp and can be at any time). This is causing it to run through all the code every time one of the switches it controls is flipped.


#24

This is why you should use restrictions…
piston subscribes to the events of a device…
piston starts evaluating because it saw an event from that device…
piston first check restrictions, and if it doesn’t pass the restriction, execution of code block is stopped right there.

And your original piston wasn’t just running a few hours a week. It’s constantly sitting there waiting on events from any of the switches. Only when it sees an event that it’s subscribed to does it start evaluating the code on what to do.

Bottom line, use restrictions when possible. Click the “options” window in top-right of the piston editor window and choose “show restrictions”


#25

Got it.

I really appreciate your help! As you can probably tell, I’m new to this:)


#26

No problem, hope you learned something!


#27

I actually did. I think I got more clarity today than ever before:)