Sanity Check - Lighting Automations - combining pistons and maintaining attrib states for restores


#1

1) Give a description of the problem
Looking for a sanity check

  1. will this work as expected (see below)
  2. is this the most efficient way to execute the expected behavior?

2) What is the expected behavior?
The piston has two parts
What happens if the Garage backdoor opens
capture state of an exterior light turn it on for 4m and then restore the state
capture state of 2 interior lights (if the variable is not empty), turn them on for 5m and then restore the state

If any of the following (Gararge Bays or kitchen door open) OR if there is motion detected in the garage
capture the state of the interior lights (if the variable is not empty)
turn on the lights for 5m
restore the saved state

My expectation is that the exterior light will work fine… its straight forward.

The interior lights…
If the lights are off and I open the back door the state will be captured as “Off xx%” (state and level). after 4minutes I trip the motion sensor in the second If block - that would maintain that state as “Off XX%” and restart the wait timer?

If I am barking up the wrong tree please let me know …first time that I am looking at combining a couple of similar pistons into one and want to make sure I’m on the right track :smile:

3) What is happening/not happening?
Will test when I get home Friday :slight_smile:

4) Post a Green Snapshot of the pistonimage


5) Attach any logs (From ST IDE and by turning logging level to Full)
TBD

TIA!


#2

Just to close the loop - it seems to be working as expected - need to test a few usecases when I get home, but from the logs I am seeing it all looks good…

1/19/2018, 5:44:06 AM +884ms
+1ms â•”Received event [Motion - Interior Garage].motion = inactive with a delay of 114ms
+117ms â•‘RunTime Analysis CS > 13ms > PS > 29ms > PE > 75ms > CE
+119ms â•‘Runtime (44519 bytes) successfully initialized in 29ms (v0.2.102.20180116) (117ms)
+121ms â•‘â•”Execution stage started
+166ms ║║Comparison (time) 20647011 is_between (time) 1516399380000 … (time) 1516364580000 = true (9ms)
+167ms â•‘â•‘Time restriction check passed
+169ms â•‘â•‘Condition #25 evaluated true (43ms)
+170ms â•‘â•‘Condition group #1 evaluated true (state did not change) (44ms)
+179ms â•‘â•‘Condition #16 evaluated false (6ms)
+179ms â•‘â•‘Condition group #2 evaluated false (state did not change) (7ms)
+195ms â•‘â•‘Condition #23 evaluated false (13ms)
+198ms â•‘â•‘Comparison (enum) inactive changes_to (string) active = false (0ms)
+200ms ║║Cancelling condition #24’s schedules…
+201ms â•‘â•‘Condition #24 evaluated false (5ms)
+202ms ║║Cancelling condition #3’s schedules…
+202ms â•‘â•‘Condition group #3 evaluated false (state changed) (22ms)
+206ms ║╚Execution stage complete. (86ms)
+207ms â•‘Setting up scheduled job for Fri, Jan 19 2018 @ 5:49:03 AM EST (in 296.057s)
+219ms ╚Event processed successfully (219ms)
1/19/2018, 5:44:02 AM +837ms
+1ms â•”Received event [Motion - Interior Garage].motion = active with a delay of 146ms
+159ms â•‘RunTime Analysis CS > 32ms > PS > 39ms > PE > 89ms > CE
+162ms â•‘Runtime (44519 bytes) successfully initialized in 39ms (v0.2.102.20180116) (160ms)
+164ms â•‘â•”Execution stage started
+218ms ║║Comparison (time) 20643008 is_between (time) 1516399380000 … (time) 1516364580000 = true (10ms)
+219ms â•‘â•‘Time restriction check passed
+221ms â•‘â•‘Condition #25 evaluated true (51ms)
+222ms â•‘â•‘Condition group #1 evaluated true (state did not change) (52ms)
+232ms â•‘â•‘Condition #16 evaluated false (7ms)
+233ms â•‘â•‘Condition group #2 evaluated false (state did not change) (9ms)
+251ms ║║Cancelling condition #23’s schedules…
+252ms â•‘â•‘Condition #23 evaluated false (18ms)
+257ms â•‘â•‘Comparison (enum) active changes_to (string) active = true (0ms)
+258ms ║║Cancelling condition #24’s schedules…
+259ms â•‘â•‘Condition #24 evaluated true (6ms)
+260ms â•‘â•‘Condition group #3 evaluated true (state did not change) (26ms)
+263ms ║║Cancelling statement #17’s schedules…
+272ms â•‘â•‘Executed virtual command [Garage Interior Light 1].saveStateLocally (1ms)
+276ms â•‘â•‘Executed virtual command [Garage Interior Light 2].saveStateLocally (1ms)
+280ms â•‘â•‘Skipped execution of physical command [Garage Interior Light 1].on([]) because it would make no change to the device. (2ms)
+281ms â•‘â•‘Executed [Garage Interior Light 1].on (4ms)
+286ms â•‘â•‘Skipped execution of physical command [Garage Interior Light 2].on([]) because it would make no change to the device. (3ms)
+286ms â•‘â•‘Executed [Garage Interior Light 2].on (4ms)
+296ms â•‘â•‘Skipped execution of physical command [Garage Interior Light 1].setLevel([100]) because it would make no change to the device. (6ms)
+297ms â•‘â•‘Executed [Garage Interior Light 1].setLevel (7ms)
+305ms â•‘â•‘Skipped execution of physical command [Garage Interior Light 2].setLevel([100]) because it would make no change to the device. (6ms)
+305ms â•‘â•‘Executed [Garage Interior Light 2].setLevel (7ms)
+309ms â•‘â•‘Executed virtual command [Garage Interior Light 1, Garage Interior Light 2].wait (0ms)
+310ms â•‘â•‘Requesting a wake up for Fri, Jan 19 2018 @ 5:49:03 AM EST (in 300.0s)
+317ms ║╚Execution stage complete. (153ms)
+318ms â•‘Setting up scheduled job for Fri, Jan 19 2018 @ 5:49:03 AM EST (in 299.993s)
+422ms ╚Event processed successfully (421ms)
1/19/2018, 5:43:55 AM +377ms
+1ms â•”Received event [Garage Door - Right Bay].contact = open with a delay of 141ms
+128ms â•‘RunTime Analysis CS > 16ms > PS > 39ms > PE > 72ms > CE
+131ms â•‘Runtime (44521 bytes) successfully initialized in 39ms (v0.2.102.20180116) (129ms)
+132ms â•‘â•”Execution stage started
+181ms ║║Comparison (time) 20635514 is_between (time) 1516399380000 … (time) 1516364580000 = true (9ms)
+182ms â•‘â•‘Time restriction check passed
+183ms â•‘â•‘Condition #25 evaluated true (46ms)
+184ms â•‘â•‘Condition group #1 evaluated true (state did not change) (47ms)
+194ms â•‘â•‘Condition #16 evaluated false (7ms)
+195ms â•‘â•‘Condition group #2 evaluated false (state did not change) (9ms)
+207ms â•‘â•‘Comparison (enum) open changes_to (string) open = true (0ms)
+209ms ║║Cancelling condition #23’s schedules…
+210ms â•‘â•‘Condition #23 evaluated true (14ms)
+211ms ║║Cancelling condition #3’s schedules…
+212ms â•‘â•‘Condition group #3 evaluated true (state changed) (16ms)
+214ms ║║Cancelling statement #17’s schedules…
+223ms â•‘â•‘Executed virtual command [Garage Interior Light 1].saveStateLocally (1ms)
+226ms â•‘â•‘Executed virtual command [Garage Interior Light 2].saveStateLocally (1ms)
+249ms â•‘â•‘Executed physical command [Garage Interior Light 1].on() (21ms)
+250ms â•‘â•‘Executed [Garage Interior Light 1].on (22ms)
+271ms â•‘â•‘Executed physical command [Garage Interior Light 2].on() (20ms)
+272ms â•‘â•‘Executed [Garage Interior Light 2].on (22ms)
+294ms â•‘â•‘Executed physical command [Garage Interior Light 1].setLevel([100]) (19ms)
+295ms â•‘â•‘Executed [Garage Interior Light 1].setLevel (20ms)
+315ms â•‘â•‘Executed physical command [Garage Interior Light 2].setLevel([100]) (18ms)
+315ms â•‘â•‘Executed [Garage Interior Light 2].setLevel (19ms)
+319ms â•‘â•‘Executed virtual command [Garage Interior Light 1, Garage Interior Light 2].wait (1ms)
+320ms â•‘â•‘Requesting a wake up for Fri, Jan 19 2018 @ 5:48:55 AM EST (in 300.0s)
+325ms ║╚Execution stage complete. (194ms)
+327ms â•‘Setting up scheduled job for Fri, Jan 19 2018 @ 5:48:55 AM EST (in 299.995s)
+336ms ╚Event processed successfully (336ms)


#3

One case to test when you’re home is your ability to restore a light to the “off” condition. Using dimmers, I had to add a wait between restoring LEVEL and SWITCH attributes. It works fine when the switch is being turned on, but if it’s being turned on:

  • Whether the level is sent first or 2nd seemed irrelevant
  • The problem is the dimmer will interpret a Set Level as a “Switch On” command
  • Restore level followed by restore switch would leave the light on
  • Restore switch followed by restore level would leave the light on
  • Restore level, waiting 2 seconds, then restoring the switch had the outcome I was after

#4

Interesting - I haven’t had that issue with the dimmers yet in other pistons … perhaps its specific to the device? Mine are all Lutron Caseta’s so they are hitting out to the cloud which perhaps is enough of a delay to work right?

I’ve heard this before, but have yet to experience it happening …


#5

Yeah, Lutron may be more immune to it based on having their own hub/cloud interactions. I’ve used them in the past, then went with GE/Jasco because I wanted to be able to differentiate between physical switch inputs, and use double-tap features. Not all of that panned out though… pros and cons to each manufacturer!

If your lights are working, definitely leave the piston as-is! I was just offering a “you might want to make sure THIS scenario is working the way you think it is”… in case you only verified “turn/leave the light on” cases in person. That’s how I got caught out by mine. :slight_smile:


#6

I’ll let them run a few days and see … worst case is my garage lights stay on till I get home :bulb: