Super newbie here. I’m glad I found this thread. I was going to ask how to do EXACTLY what is illustrated in the first example. I created a super simple piston to turn on my front porch light when motion is detected and then turn it off after three minutes, but I used a wait timer. I figured that if someone were still standing at the front door and motion were still active, the light would shut off on them anyway because of the timer that was set when the light was turned on. So this looks like it should solve that problem. Question: Will this only shut off the light if it was turned on by this piston? We have a rule to turn on the porch light at sunset, and if we walk out the front door and trigger motion, I don’t want the light to shut off three minutes later. (My intent for this piston is to have the lights motion-activated when we are sleeping and location mode is Night, when the light would normally be off. In the evenings before bed, the light comes on at sunset, and I don’t want it to shut off if motion stops but that motion was not what turned the light on.)
Are you a Newbie, this is your post
if you want same light, same motion sensor to behave different, under different circumstances, you need to get your hands dirty and start using VARIABLES.
or atleast using TIME FRAMEs as a CONDITION…
If motion sensor changes to active
AND
time is between X and Y
then
Do this do that…
I tried the following so the piston would only activate between sunset and sunrise and when the porch light is off (so that it doesn’t shut off after motion stops if it was already on when motion started):
With just the Date & Time restriction, the light comes on when motion is activated and then shuts off as expected. Once I added the switch off condition, the light will come on with motion, but not shut off.
7/27/2020, 10:38:56 PM +92ms
+2ms ╔Received event [Doorbell].motion = inactive with a delay of 65ms
+79ms ║RunTime Analysis CS > 18ms > PS > 47ms > PE > 13ms > CE
+81ms ║Runtime (38613 bytes) successfully initialized in 47ms (v0.3.110.20191009) (79ms)
+82ms ║╔Execution stage started
+102ms ║║Comparison (datetime) 1595903936177 is_between (datetime) 1595896860000 … (datetime) 1595846760000 = true (2ms)
+103ms ║║Time restriction check passed
+105ms ║║Condition #10 evaluated true (21ms)
+112ms ║║Comparison (enum) on is (string) off = false (1ms)
+114ms ║║Cancelling condition #11’s schedules…
+114ms ║║Condition #11 evaluated false (9ms)
+115ms ║║Cancelling condition #null’s schedules…
+116ms ║║Condition group #null evaluated false (state changed) (32ms)
+117ms ║║Piston execution aborted due to restrictions in effect
+121ms ║║Comparison (enum) inactive changes_to (string) active = false (0ms)
+122ms ║║Cancelling condition #2’s schedules…
+123ms ║║Cancelling condition #1’s schedules…
+131ms ║║Comparison (enum) inactive stays (string) inactive = true (1ms)
+132ms ║║Cancelling condition #7’s schedules…
+133ms ║║Cancelling condition #6’s schedules…
+137ms ║╚Execution stage complete. (56ms)
+138ms ╚Event processed successfully (138ms)
7/27/2020, 10:38:16 PM +734ms
+2ms ╔Received event [Doorbell].motion = active with a delay of 67ms
+242ms ║RunTime Analysis CS > 20ms > PS > 204ms > PE > 18ms > CE
+244ms ║Runtime (38613 bytes) successfully initialized in 204ms (v0.3.110.20191009) (241ms)
+245ms ║╔Execution stage started
+267ms ║║Comparison (datetime) 1595903896982 is_between (datetime) 1595896860000 … (datetime) 1595846760000 = true (2ms)
+268ms ║║Time restriction check passed
+269ms ║║Condition #10 evaluated true (21ms)
+276ms ║║Comparison (enum) off is (string) off = true (1ms)
+277ms ║║Condition #11 evaluated true (7ms)
+278ms ║║Condition group #null evaluated true (state did not change) (30ms)
+283ms ║║Comparison (enum) active changes_to (string) active = true (1ms)
+284ms ║║Cancelling condition #2’s schedules…
+285ms ║║Condition #2 evaluated true (5ms)
+286ms ║║Cancelling condition #1’s schedules…
+286ms ║║Condition group #1 evaluated true (state changed) (6ms)
+288ms ║║Cancelling statement #3’s schedules…
+757ms ║║Executed physical command [Front Porch Light].on() (467ms)
+758ms ║║Executed [Front Porch Light].on (468ms)
+765ms ║║Comparison (enum) active stays (string) inactive = false (2ms)
+767ms ║║Cancelling any timed trigger schedules for condition 7
+767ms ║║Cancelling statement #7’s schedules…
+768ms ║║Cancelling condition #7’s schedules…
+769ms ║║Condition #7 evaluated false (8ms)
+770ms ║║Cancelling condition #6’s schedules…
+771ms ║║Condition group #6 evaluated false (state changed) (9ms)
+772ms ║╚Execution stage complete. (527ms)
+773ms ╚Event processed successfully (773ms)
It appears that each IF block checks the conditions at the top, and the second IF block fails to execute because one of the conditions is now false. I would have thought that the conditions are only checked once and then the entire piston either executes or does not. How can I make this happen? Please be specific! I appreciate any help, but the last reply was not very useful to me.
Quick Answer:
I would avoid using ONLY WHEN. They often do not do what you’d expect.
Instead, I would create an IF condition inside your current blocks.
IF Motion changes to active <-- Trigger
Then
IF Time is between X & Y <-- Condition
Then
do stuff
END IF
END IF
Pro Tip:
I would also invert your times to:
IF Time is NOT between sunrise and sunset
Thanks! No problem adding the time condition to the first IF block so that the light only comes on during certain times. What conditions could I use in the second IF block so that the light ONLY shuts off IF it was turned on by this piston? The light should stay on if it was already on.
Why invert the times?
Honestly, this answer is not easy, and should be in a new thread.
(although @bangali has a great thread over here)
The inverted times helps when spanning midnight.
Ah, that sounds exactly like what I’m looking for. I’ll explore it tomorrow and post over there if I’m having trouble with it. Thanks!!
Just be aware in the first post, there are two pistons.
- One is for a dumb bulb / smart outlet… and
- One is for a smart bulb / dumb outlet.
Make sure you start with the appropriate one.
If your bulbs are “dumb”, then you want the piston for a dumb bulb / smart outlet.
(I forget if that is the first or second on the page, but the info is over there)
WAITs are incredibly useful, if the piston is coded correctly.
The default method will abort the WAIT if conditions change.
First, thank you for putting this together. I have many (over 100?) smart-home devices and used to use Stringify before it closed its doors. webCoRE seemed scary, but some other tutorials walked me through setting it up and here I am with almost everything working as I would like.
However, I keep running into this stupid problem and I feel so frustrated!
When my office motion sensor is active, turn on my office light. And when my office motion sensor stays inactive for 10 minutes, turn off my office light.
Those two pistons worked for a long time, but every once in a while, they just stop working. I’ll leave my office for an hour, come back, and the light is still on.
Troubleshooting attempts:
- Smartthings shows the office motion sensor correctly reporting motion/no motion.
- I can control the office motion sensor via any of a number of other ways (Smartthings app, Action Tiles, voice, etc.)
In the past, when this has happened, I could pause/resume the piston and that would fix it, but this time, that “fix” isn’t working. I even deleted the old piston and created a new one from scratch, but it never executes.
I ended up pausing both of the pistons and creating corresponding automations in Smartthings to do the same thing, but that seems like a weak solution. Surely I must be missing something obvious?
Here’s an anonymized screenshot of the piston, although I can’t imagine I’ve mangled something
And I apologize if it’s not good form to rekindle an old thread, so if there’s a better home for my question/frustration, please redirect me. Thank you! -Andy
I am not going to respond on the pistons. 
I am going to warn users that webcore for ST users will probably cease by the end of this year or whenever groovy is shut down by ST. Users should start planning ahead and looking at automations in the ST app or take a look at Rules API which is not yet finalized. Avoid the Smart Lighting smartapp as it will also be shutdown with the demise of groovy.
I have looked into Hubiat for some time. If you have basic zwave and zigbee items all is good. But if you have Ring, MyQ or want to manage TV’s it’s a mess. Things work sometimes, work once and not again. So for the basics works fine. To much work for me…
Thank you all for the feedback…
This round i want to start simple… dimers, lights, maybe a harmony hub etc…
i believe im going to be happy with hubitat