Trigger light to go on/off/on within 3 seconds

I have an outdoor LED flood light that has a motion sensor. In the evenings, we’d prefer it to stay on all night. In order to do this, you have to turn the light off, on, off, on within 3 seconds (note, I originally had 10 here, then I read the directions again after my tests were not working) then it will disable motion and leave the LED floods on for 6 hours. I’ve tried to set this up so I can trigger/schedule this “on all night” action so that when I’m away, we can still trigger it. I’ve tried the following:

runIn(secs, function)

I’ve tried something similar to this with varying seconds and they never run consistently.

def appTouch(evt) {
startTimer(15, turnOn1)
startTimer(25, turnOff2)
startTimer(35, turnOn3)
log.debug “Execution complete”

Any ideas on how to consistently space out the off/on/off/on sequence so that I can trigger my light to work properly? I’m using an Aeon Z-Wave Micro Smart Energy Switch, 2nd Edition (DSC18103-ZWUS) in case that matters.


What do you mean by “consistently” and what have you observed happening instead?

From your description, the “off / on / off / on” events don’t have to happen with consistent timing in between the states, they just have to complete within 10 seconds, right?

So, in fact, you might not need runIn() at all, since sending the events as fast as possible is most likely to minimize the impact of network and ST Cloud latency delays.

The catch? Well, in a mesh network, the events are not guaranteed to reach the switch in the order sent (there’s been discussions about this, with @JDRoberts detailing how important it is not to rely on any “deterministic” assumptions). Mathematically, I guess delays between the events would increase the odds of them arriving in sequence. But my gut feel is that the risk of ST latency delays (i.e., the risk that all 4 commands will be completed in 10 seconds) is greater than the risk of local sequencing inconsistency.

Mesh networks like zwave and zigbee are intended for networks that have very small information packets and that are low cost in both energy and dollars. They are also what is called “resilient” meaning that the temporary absence of any one node will not prevent messages being sent. This works by allowing messages to bounce around the network finding an available path.

Because of this this architecture does not allow absolute sequencing, or absolute scheduling. It’s just not something that the architecture supports.

For this reason, it’s pretty unlikely that you can create the sequence you want reliably using zwave.

You would be better off controlling the sequence with a Wi-Fi switch. Wifi is normally set up in a star topology, which does allow for strict sequencing and scheduling.

1 Like

runIn() basically doesn’t work for times less than 60 seconds. Known limitation.

1 Like

Why all of the off, on, off bit? Why not just change modes, and mode restrict your motion not to be active in the all-night mode?

I believe the motion detector is built into the light itself, and this is its deactivate sequence. I don’t think he has a networked motion sensor, just a networked power switch.

1 Like

Correct. It’s built in. I suppose I could swap out the lights and get some without sensors built in, but the lights are already in place and I’d rather not swap them out.

I’ve observed the runOnce function above where I would put 5-10 seconds in as the run time for each item, and it would run one in 5 seconds, one 20 seconds later, and one not at all. Or run them all together sequentially. Or one in 5 seconds and then all together. It’s not consistent at all.

Running Off/On/Off/On consecutively right after each other is too fast for the light to even come on and register the action. So there needs to be some sort of sleep or pause action after the light cycle.


That is forced sequencing. It can’t be done in that short of an interval with zwave. See the scheduling documentation at the link given above.

So, yes, you could change to a different light, match with a separate networkable sensor, and control with modes, as @bravenel suggested. That would certainly be the easiest to integrate with SmartThings.

Alternatively, you could change to a WiFi switch and keep the current light fixtures, but then the ST integration might be harder.

As Gilda would say, Never Mind…

Notwithstanding the non-guarantee of order of receipt at the switch, I still believe that with only 4 events in 10 seconds, you have a high probability of getting it to work, if, indeed, you can pause the optimal time between events (i.e., short enough to reduce latency risk making the sequence longer than 10 seconds, but long enough so that each event arrives in sequence).

Only a theory.

So dirty method is to try a “busy-wait” between the events (a null loop that counts to 10,000 or similar).

Not at my PC at the moment, but we could figure out what types of busy-wait or similar pause options are available and most reliable. I like to be optimistic unless proven it’s hopeless, provided you don’t require 100% reliability.

Drop me a private message?

The other option is to put the timing intelligence at the switch by using an Arduino or similar, but that’s perhaps overkill.

OK… so per my immediately previous post, I say, “what the heck” and let’s try an impolite busy-wait loop just as a Proof of Concept.

Without a reliable short-duration runIn() or messing around with runOnce(), we need a true processor surrendering sleep() method to avoid a busy-wait loop, I think. For now… try some variation on this working code for your requirement. I tested with 1000 and 2000 milliseconds. Shorter values are better to ensure you stay within the 10 seconds window required by your motion sensing light, but too short may result in events not reaching the switch in sequence.


11:32:53 PM: debug Exec complete.
11:32:53 PM: debug ON at time Sun Apr 12 06:32:53 UTC 2015
11:32:53 PM: debug ... DONE pausing.
11:32:51 PM: debug pausing... at Now: 1428820371194
11:32:51 PM: debug OFF at time Sun Apr 12 06:32:51 UTC 2015
11:32:51 PM: debug ... DONE pausing.
11:32:49 PM: debug pausing... at Now: 1428820369154
11:32:49 PM: debug ON at time Sun Apr 12 06:32:49 UTC 2015
11:32:49 PM: debug ... DONE pausing.
11:32:47 PM: debug pausing... at Now: 1428820367112
11:32:47 PM: debug OFF at time Sun Apr 12 06:32:47 UTC 2015
11:32:47 PM: debug appTouch with Event:
11:32:38 PM: debug Updated with settings: [mySwitch:[Deuce Lamp], pauseMillis:2000]

Awesome. This works perfectly! I re-read up on my light as my earlier experiments were not working and its off/on/off/on in 3 seconds, not 10, but using the above example with delay time of 500ms works wonderfully.

Thank you for the concise example!

1 Like

You could also use a modified device type, and introduce a new command for the on/off/on sequence with 500 ms delay.

1 Like

Like this:

def onOffon() {
	delayBetween ([
    	delayBetween ([	zwave.basicV1.basicSet(value: 0xFF).format(),
        				zwave.basicV1.basicSet(value: 0x00).format()
        				zwave.basicV1.basicSet(value: 0xFF).format()], 500),	

I’m glad it works now, there’s no guarantee it will continue to work in the future. If you either add more devices, or increase network traffic, you may run into the mesh issues we mentioned. Or just inconsistencies in processing time, as you seen in your previous tests.

I am particularly concerned because you’re using this for home security purposes, and I just think it’s something that’s inherently antagonistic to the network topology.

i’m most worried about the last “on” being lost, and the lights not working at all while you’re away, even for episodic motion detection.

But obviously it’s a personal decision. We all have different factors that contribute to peace of mind. :blush:

I’m guessing (and too lazy to check), “delayBetween()” is not available inside SmartApps, but just in SmartDevice Type Handlers?

(And @JDRobertsI hope you don’t mind the little jab here: You’re coming across as a “wet blanket”. I’ve already conceded and we’ve detailed the risks involved due to the non-deterministic timing caused by implementing this particular solution across a mesh & cloud network, so no need to blowout our celebratory candles … no? :wink:).

1 Like

I’m glad it’s working, honest. :blush:

I just find that a lot of people coming from programming for a star network, like wifi, or a single machine, just aren’t prepared for the mesh reality that what works one time may fail another when attempting forced sequencing.

Better to be prepared than surprised, I think. But that’s just me. :wink:

1 Like

None of this has any certainty. The light bulb will burn out one day, for example. The power will fail at the wrong moment, etc. etc. I think it’s good to be aware of the potential failures, for sure. But, in these fairly small z-wave networks, the failures from z-wave sequencing have to be fairly rare unless one is beating on the network somehow. Of course, I don’t know how to quantify it.

I wrote a modified device type to handle a problem that a smart app was consistently failing with, namely setting a dimmer level and then immediately turning the dimmer off. Written in a SmartApp the failure rate was high enough to be bothersome. Upon moving that logic to the device type, I can honestly report that I have not seen a single failure since. I would have to think that z-wave mesh sequence issues are still in play, but two back-to-back z-wave commands in a device type seems to work pretty reliably.


I’ve only seen that code in device types, not in apps. It is used in all of the z-wave device types that I’ve looked at. The Dimmer Switch device type has some long delayBetween()s, as much as 5000 ms. Whereas the Z-Wave Switch device type apparently just uses delayBetween with no time specified. I don’t know more than that about it – just hacking code from the templates.

1 Like

I am looking for something similar to this later on. Would a flashing light smartapp with a virtual switch do the trick?