Fade multiple house lights from current level to 20% over time

#1

1) Give a description of the problem
Hi, With Gentle wake up being broken now I am having to recreate the actions that were being performed by that app. In short the piston runs the devices sequentially (synchronous?) rather than simultaneously (Asynchronous?). I have read innumerable articles but can not quite grasp where to change to “Asynchronous” in the piston or if it will even work with fade vs wait (tried both).

2) What is the expected behaviour?
With the execution of a virtual switch 23 lights shall have their switch status and last known brightness level stored as a variable (works fine). The variable shall be applied dependent on switch status (Off= 0%, On={Current level}%)(works fine). Each individual bulb or switch (henceforth “device”) shall Dim / brighten accordinly from the current level to 20% over a period of 10 minutes (Error here), then proceed to turn off the virtual switch (works fine) and change the location mode (works fine).

3) What is happening/not happening?
When running the “do” loops for each device the piston… “waits” 10 minutes @ each light until the desired level % is attained. Running down the list of devices sequentially rather than all device simultaneously. this causes the piston to run 230 minutes rather than 10. What you cannot see in the log below is that after the piston runs one device it proceeds to the next. Dining Room Lamp to Dining Room Ceiling light. The start level% works, the end level% works it is just the sequential vs simultaneous that is eluding me.

4) Post a Green Snapshot of the pistonimage

image
image.png705×4085 292 KB

5) Attach logs after turning logging level to Full
9/2/2020, 3:21:02 PM +819ms
+0ms ╔Received event [GLR House].test = 1599074462818 with a delay of 0ms
+183ms ║RunTime Analysis CS > 23ms > PS > 29ms > PE > 131ms > CE
+188ms ║Runtime (88994 bytes) successfully initialized in 29ms (v0.3.110.20191009) (187ms)
+189ms ║╔Execution stage started
+204ms ║║Condition #2 evaluated false (11ms)
+205ms ║║Condition group #1 evaluated false (state did not change) (12ms)
+216ms ║║Comparison (enum) on is (string) on = true (1ms)
+218ms ║║Cancelling condition #65’s schedules…
+219ms ║║Condition #65 evaluated true (11ms)
+220ms ║║Cancelling condition #64’s schedules…
+221ms ║║Condition group #64 evaluated true (state changed) (13ms)
+224ms ║║Cancelling statement #72’s schedules…
+251ms ║║Skipped execution of physical command [Dining Room Lamp].setLevel([80]) because it would make no change to the device. (11ms)
+252ms ║║Executed [Dining Room Lamp].setLevel (13ms)
+260ms ║║Skipped execution of physical command [Dining Room Lamp].on([]) because it would make no change to the device. (6ms)
+261ms ║║Executed [Dining Room Lamp].on (8ms)
+284ms ║║Skipped execution of physical command [Dining Room Lamp].setLevel([80]) because it would make no change to the device. (9ms)
+326ms ║║Executed virtual command [Dining Room Lamp].fadeLevel (53ms)
+327ms ║║Requesting a wake up for Wed, Sep 2 2020 @ 3:31:03 PM EDT (in 600.1s)
+359ms ║╚Execution stage complete. (169ms)
+380ms ║Setting up scheduled job for Wed, Sep 2 2020 @ 3:21:13 PM EDT (in 9.918s), with 61 more jobs pending
+388ms ╚Event processed successfully (388ms)

Clear

Full

REMOVE BELOW AFTER READING

#2

Quick answer:

Nothing in SmartThings is truly ASYNC. Every command is handled one step at a time…
(as seen in a Full log)

The “pseudo- ASYNC” here in webCoRE only comes into play when there is a WAIT.
When the ASYNC WAIT is encountered, it sets a wakeup timer, but then continues along with the next command… One step at a time.

Translation:
On a Loop with WAITS, I would avoid using ASYNC.
On a fade (which is really a loop with WAITS), I would avoid using ASYNC.

I would also avoid trying to fade multiple devices with a loop.
(which is really a loop within another loop… ack!)

#3

From what I think I am understanding then is that the desired outcome cannot be accomplished in a single piston. Rather make 22 copies of this piston, delete 22 devices from each and have the single virtual switch execute 23 pistons? I also see that I somehow posted a snap shot of someting else other than the anonymized piston…

#4

202009021550
202009021550.png1178×6939 735 KB

#5

To be perfectly honest with you… SmartThings environment is not set up to handle all the spamming pistons. I am fairly certain that 22 pistons running simultaneously will be horribly unreliable.

If your heart is set on making this work, I would consider a single long piston, with no loops, no fades, and no ASYNC. (Simply use “set level” commands and normal WAITS)

For example:

With Bulb1
    Set level to Bulb1 + 10
END WITH

With Bulb2
    Set level to Bulb2 + 10
END WITH

WAIT X seconds

With Bulb1
    Set level to Bulb1 + 10
END WITH

With Bulb2
    Set level to Bulb2 + 10
END WITH

WAIT X seconds

etc…

Note: If you go with this method (avoiding fades and ASYNC), you may be able to incorporate the above into a basic loop, with minimal issues.

#6

I have something like that mostly set up, I would just need to re order the devices, put in waits and remove the do loops. I guess the sad thing is the Gentle Wakeup app did this seamlessly for six years until the forced migrations.

I am going to leave this here for a bit while I rewrite the original piston with waits and just in the case that some clever someone has a different (and more clever) mind than I. Thank you for your concise explanations, time and ideas.

#7

The key here is an outside, third party app handled all of the hundreds of spam commands.
Not SmartThings.

Please don’t take this the wrong way, but if I was taking a guess, it is probably spam pistons like yours that encouraged SmartThings to force us to update to the new app… With the intention of taking the stress and burden off of their servers. (and letting users spam using their own home network)

Visual graph from last November: Number of piston executions per hour