1) Give a description of the problem
I want all the lights in my house to flash blue if ring detects motion, then turn lights to colour they were before they were blue. If they were off, then off again.
2) What is the expected behaviour?
I’m new to webCoRE, don’t know how to get this up and running…
Any help at all would be greatly appreciated!
P.S. LIFX & Philips bulbs
Hi there,
to get the lights back to where they were you’ll need to use variables.
You’ll need to save all the attributes to variables once the motion detected… After the blue flashing warning, you’ll assign them back to the bulbs.
here is an example of how to save lights status to variables.
Got it. I appreciate the example for that. Would you know how I could integrate it into my Ring Doorbell detecting motion? I’m getting an issue where I’ve asked the bulb to change from blue to white as a flash color every 2 seconds for 5 times, and it often stutters. It will pause for an extra second then speed up and flash fast then slow down again. I have no idea what is the cause and it has been bugging me for days. It can’t be my piston, as it’s a simple execute of simply just ‘Flash Color’.
Any ideas?
that will happen…
Since not everything is local, signal and communications issues are a thing for smart homes.
You should be able to see Ring Door bell in webcore. (I use two of them) and once you pick the device in webcore piston, you can see available commands. And in your - and in mine - acts as a motion sensor.
My front door is called FRONT DOOR :)) LOL
and it’s ring door bell, the piston is something like.
IF Front Door motion is activated
Then
Do this do thatSmartThings has a hard limit of 20 seconds for the maximum duration of any automation. Because of this, webCoRE tries to stay under 10 seconds. Anything beyond the 10 second mark, will be “put on hold” until the piston schedules a wakeup… At which point, webCoRE tries to continue where it left off. (SmartThings thinks it is a new event, so the 20 second max is reset)
This means, at every ten second mark, the timing will be off a couple of seconds.
You can see a great example & discussion of this over here.
Essentially, if you keep the total piston duration at 8 or 9 seconds (or less), your flashing light pattern will be much more consistent, with no schedules. (This is my preferred method)
Alternatively, if you want a longer flash, then you can set each cycle event somewhere between 6 and 9 seconds. This will cause (at most) two commands per “session” before a new wakeup is scheduled. This method is also be pretty consistent. (although 6 sec might really turn out to be about 8 seconds)
Lastly, if each cycle/event is set to 11 seconds or more, then no more than one event can happen at each scheduled wakeup. This one is also fairly consistent… but it often seems more precise, since the human eye can not usually detect the difference between 11 and 13 seconds. (This is my second favorite method)
Edit:
Notice in the list above, the first is based on the total time the piston executes. (line 1 to line 501)… The second and third are based on the time between each command sent. This distinction was intentional. The only way the wakeup might be avoided, is if the total duration of the entire piston is under 8 or 9 seconds.
Pro Tip:
The 8.5 to 10 second range is kind of “on the fence”, and can fall either way, depending on network commotion at the time (among other factors). Best to avoid.