Strange Triggering of Device by Piston

OldPro · 2020-03-01 19:47:38 UTC

I get odd triggering of some lights using my Piston to randomize lights.

SmartThings Smart Lighting turns my lights on and off for convenience every day. That has worked really well.

I use webCoRE as an “overlay” to randomize some lights when we are away from the house. This Piston is provided below.

I’ve been having problems for several months with one or two lights turning on between midnight and two AM. I was tweaking the Piston last night and a light turned on at 12:48:09 AM. Unfortunately, the webCoRE log has been overwritten.

I added a backstop “Else / Only When” block to turn off any lights that may have come on. But that did not turn off the light that came on at 12:48 AM.

I have carefully set up the times in the Piston to avoid adding jobs to the queue after 10:30 pm. The “Wait Randomly” will wait 10 to 19 minutes to toggle a device. All of those “Wait Randomly” periods should have timed out by a maximum of 10:30 + 19 = 10:49 pm. I don’t see any way a pending “Wait Randomly” could toggle a light back on at 12:48 AM.

I’m really stumped by this and not sure what to do. Can I add a “Cancel all pending tasks” task around 11:00 PM?

Here is the SmartThings Event log for the light that went on. It definitely got the command from the webCoRE piston.

Here is the webCoRE piston. The device that turned on the light at 12:48 AM is highlighted in the red box.

WCmore · 2020-03-01 20:16:55 UTC

Setting your Log levels to Full to capture errors is the next step towards a proper diagnose.

(although with 7 overlapping WAITS, it may be tricky to catch the error before it vanishes)

orangebucket · 2020-03-01 20:42:50 UTC

I think your intention is that the piston will run all those 10-19 minute waits asynchronously? Does the ‘async if’ actually make that happen? I’ve never tried it but my natural assumption would be that the 10-19 minute waits would still execute sequentially and that it would be a 70-133 minute block executing asynchronously with nothing.

Worse still, as the timer is firing every 20 minutes, I don’t like to think what might be happening with all those waits. The Task Scheduling Policy could be kicking in, for example, and overwriting them.

Logs might be diagnostic, but they will be a nightmare to read.

WCmore · 2020-03-01 20:52:12 UTC

How right you are… I forgot about the “Every 20 minutes” portion of the code…
Yes, it is a WAITing nightmare…

Although, 10:30 + (19 * 7) = 12:43, which is still a few minutes shy of 12:48…

WCmore · 2020-03-01 20:59:16 UTC

Side Note:

If Switch 8 ever turns on (or is on) after midnight (IE: 12:48am), then the rest of the piston will be processed. (since 12:48am is “before” 10:30pm)

OldPro · 2020-03-01 21:46:09 UTC

Here’s some design strategy information:

We have a north-facing living room with a big porch overhang, so the living room gets dark early in the afternoon in the winter. Switch 8 is part of an automation to turn the living room lights on earlier in the afternoon on dark winter days.

Switch 8 is a virtual switch. There is a SmartThings Smart Lighting automation which turns on the living room lights when an Aeotec MultiSensor reads Lux <=200 after 1:00 PM. This same Smart Lighting automation turns on the virtual Switch 8 in addition to the living room devices.

Virtual Switch 8 is turned off by another SmartThings Smart Lighting automation which runs at 1:00 AM every day. All it does is turn off Virtual Switch 8.

There are two ST Smart Lighting automations to turn on the living room lights:

Every day at 60 minutes before sunset
Every day after 1:00 PM if Lux <=200

The sole purpose of Virtual Switch 8 is to communicate to this Piston that the living room is dark in the afternoon. The goal of this is to start the randomization of the living room lights in the afternoon if it is a dark day.

Summary:

Switch 8 turns on after 1:00 PM on those days when Living Room Lux <=200
Switch 8 turns off every day at 1:00 AM

Here you see the Switch 8 Events List from the SmartThings IDE:

orangebucket · 2020-03-01 21:48:16 UTC

Yes, and the sum should probably be 10:30 + (19 * 5) for the offending light.

I am also pondering how after 60 minutes to sunset might evaluate if a new value for sunset hasn’t been pulled down yet. The before and after comparisons use datetime and sunset has a date on it too.

WCmore · 2020-03-01 22:13:25 UTC

Now that I better understand the outside logic, I think you may resolve it:

If Switch 8 turned off at 11:59pm daily
…OR…
Changing line 30 to: IF Time is between 60m to sunset and 10:30pm

Either method should stop it from firing past midnight, but my preference is the latter.

WCmore · 2020-03-01 22:14:51 UTC

Good catch. That light was not the last block.

OldPro · 2020-03-02 00:29:30 UTC

Thanks. Changes made. I made both of your recommendations.
The “OR” for Time Between and z Lux Is Low seems odd. I don’t have a complex statement after the OR, but brackets are there for a complex statement. That’s the only way I could find to do it. Is that correct? Any way to use a simple OR?

WCmore · 2020-03-02 01:05:06 UTC

For the record, I was not recommending adding another trigger to this piston…
I was referring to your other automation that is already in place:

I was recommending changing the time there to 11:59pm

I hate this too… I usually delete the offending line, and then add a new condition to get rid of the extraneous brackets.

OldPro · 2020-03-02 01:39:42 UTC

Got it. Another “Duh” moment. Just after I told you I had the automation doing this! Change made and new trigger removed from this piston.

I tried deleting the “OR” clause, but that didn’t work. I then deleted the “Time is between…” clause and re-added it back. Then re-added the OR clause (“z Lux is Low”) back. That worked. Looks much better. Thanks for your help today.