Help with delays on Device Handlers

General Discussion
1

Hi there,

I’m having issues understanding how to implement the delay ability correctly. Whatever I do doesn’t seem to work right. Can someone offer some clues on how to fix this?

Note – I know it’s messy. Ideally, I’d like the function to show that its enabled and waiting, but I’m just trying to test getting the delay to work correctly.

/**
 *  DELAYED Simulated Switch
 *  Modification by Angela Morley
 *  For reasons....
 *  ----------------------------------
 *  Copyright 2015 SmartThings
 *
 *  Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
 *  in compliance with the License. You may obtain a copy of the License at:
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 *  Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
 *  on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
 *  for the specific language governing permissions and limitations under the License.
 *
 */
metadata {

definition (name: "Simulated Delayed Switch", namespace: "smartthings/testing", author: "Angela") {
		capability "Switch"
    	capability "Relay Switch"
		capability "Sensor"
		capability "Actuator"

		command "onPhysical"
		command "offPhysical"
	}

	tiles {
		standardTile("switch", "device.switch", width: 2, height: 2, canChangeIcon: true) {
			state "off", label: '${currentValue}', action: "switch.on", icon: "st.switches.switch.off", backgroundColor: "#ffffff"
			state "on", label: '${currentValue}', action: "switch.off", icon: "st.switches.switch.on", backgroundColor: "#79b821"
		}
		standardTile("on", "device.switch", decoration: "flat") {
			state "default", label: 'On', action: "onPhysical", backgroundColor: "#ffffff"
		}
		standardTile("off", "device.switch", decoration: "flat") {
			state "default", label: 'Off', action: "offPhysical", backgroundColor: "#ffffff"
		}
    main "switch"
		details(["switch","on","off"])
	}
}

def parse(description) {
}

def on() {
	log.debug "$version on()"
	sendEvent(name: "switch", value: "on", [delay: 5000])
}

def off() {
	log.debug "$version off()"
	sendEvent(name: "switch", value: "off", [delay: 5000])
}

def onPhysical() {
	log.debug "$version onPhysical()"
	sendEvent(name: "switch", value: "on", type: "physical", [delay: 5000])
}

def offPhysical() {
	log.debug "$version offPhysical()"
	sendEvent(name: "switch", value: "off", type: "physical", [delay: 5000])
}

private getVersion() {
	"PUBLISHED"
}
2

Should read this post:

3

Did you ever manage to get this working in the end?

Ive tried everything from delayBetween([ , ]) to runIn() to sleep/wait/delay/pause, but cant get any of them to work.

Im trying to have a delay between sendEvents, which is a bit different to delaying a function or ZWave command, so I have a feeling that is causing the problem. It does work in a SmartApp, but not in a device handler, hence the link above is sadly not helping me much.

Thanks

4

I see a lot of 1-post threads on this subject. It seems ST doesn’t have a simple delay(n) function that works? I also need a garden variety delay:

def on() {
	log.debug "---ON COMMAND--- ${DevicePathOn}"
    sendEvent(name: "triggerswitch", value: "triggeron", isStateChange: true)
     if(DevicePathOn2){
     	runCmd(DevicePathOn)
        log.debug "---ON COMMAND #2--- ${DevicePathOn2}"
        //need a delay in here
    	runCmd(DevicePathOn2)
    	}
     else {runCmd(DevicePathOn)}
     }
5

@MouthBreather
I never managed to get my delay working, and ended up doing it in the Arduino chip that was giving information to ST… However in my experimentation I did find out a few things that you could experiment with and you might have more luck:

  1. RunIn seemed like it had the best reliability from the things that did work, hence do runIn(5,runCmd(DevicePathOn2)) for a 5s delay and give that a go.
  2. Trying to delay a sendEvent seems to cause all kinds of issues, hence if that is the command you are trying to delay then you will probably need to think of an alternative.
  3. The sendEvent commands can also mess up the delays, something that I noticed was that if sendEvent was at the top it performed differently compared to at the end of a function. I found that if the sendEvent was at the end then it gave best function, but also I found that some commands before it never triggered… even if they werent attached to a delay! Very strange!

It might not be a solution to you in this situation, but they were the most useful things I learnt in the process!!