Simulated Contact Sensor

So, I was playing around with simulated (virtual) devices and wanted to modify the Simulated Contact Sensor. I tried to create a device handler using the Simulated Contact Sensor as a template. It’s not there?? In fact, none of the “input” style simulated device handlers are available as templates. Any ideas on how to solve this? If I use another device handler, what is special about the virtual ones that allow me to change the state of the open close status from the “Things” section of the app.

Edit: I would also settle for the device handler of a virtual switch as well. I can modify it to have the door sensor capabilitites I want.

Garrett

You can find all the Simulated (virtual) DTH code and much much more here…

4 Likes

Have you done this Simulated Contact Sensor that can be set ?

@zbuh I think I need a little more detail. Are you combining this thread with another I started? I’m not sure what you mean by being “set”. Thanks!

I’m trying to set the status open/closed via mqtt.
I managed to do it with other kinds of virtual devices but not with contact sensors, due to read only limitations.

I don’t think I know what mqtt is, but I think i’m following you now. The modifications I was making was too automatically have the device handler show open/closed with the status of another contact. For debugging I think i did add some manual switches to open and close it.

I added the following to the definition:

capability "Switch"

Threw in some nice little tiles:

standardTile("open", "device.door", inactiveLabel: false, decoration: "flat") { state "default", label:'open', action:"door control.open", icon:"st.doors.garage.garage-opening"}

standardTile("close", "device.door", inactiveLabel: false, decoration: "flat") { state "default", label:'close', action:"door control.close", icon:"st.doors.garage.garage-closing" }

Then I sent the contact event based on that action:

def open() {
sendEvent(name: "contact", value: "open")
}

This is my best estimate looking at the device. I removed and commented a lot out after I finished debugging so I couldn’t accidentally open or close the simulated device.

Better yet, here’s the whole thing. I didn’t have a tile to show the contact state, only the “door” state. It has the ability to delay on and off. I ended up not even using that functionality and put it all in a SmartApp that I use to control the delay. I ended up writing that because I needed something to monitor another switch anyway, and I wanted to know what Home mode I was in.

/**
 *  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 Garage Sensor", namespace: "packerprogrammer", author: "Garrett Hensley") {
		capability "Contact Sensor"
		capability "Sensor"
        capability "Door Control"
                capability "Actuator"
        capability "Light"
        capability "Switch"	
        preferences {
    	input name: "delay", type: "number", title: "Delay Time", description: "Delay in Seconds", range:"0..999", required: true,
        	displayDuringSetup: true
    	}
        //attribute "DoorState", "string", ["open", "closed", "OPEN DELAY", "CLOSE DELAY"]
	}

	// simulator metadata
	simulator {
		}

	// UI tile definitions
	tiles {
		standardTile("toggle", "device.door", width: 2, height: 2) {
			state("closed", label:'${name}', action:"door control.open", icon:"st.doors.garage.garage-closed", backgroundColor:"#00A0DC", nextState:"OPEN DELAY")
			state("open", label:'${name}', action:"door control.close", icon:"st.doors.garage.garage-open", backgroundColor:"#e86d13", nextState:"CLOSE DELAY")
			state("OPEN DELAY", label:'${name}', icon:"st.doors.garage.garage-opening", backgroundColor:"#e86d13")
			state("CLOSE DELAY", label:'${name}', icon:"st.doors.garage.garage-closing", backgroundColor:"#00A0DC")
			
		}
		standardTile("open", "device.door", inactiveLabel: false, decoration: "flat") {
			state "default", label:'open', action:"door control.open", icon:"st.doors.garage.garage-opening"
		}
		standardTile("close", "device.door", inactiveLabel: false, decoration: "flat") {
			state "default", label:'close', action:"door control.close", icon:"st.doors.garage.garage-closing"
		}

		main "toggle"
		details(["toggle", "open", "close"])
	}
}
def on() {
	log.trace "ON was sent"
    // if the current state is open, change the state to close delay. 
    // I don't want to do this if the close command is still timing
    def doorState = device.currentState("door").getValue()
    log.debug "current state is " + doorState
    if (doorState == "CLOSED") {
    	sendEvent(name: "door", value: "OPEN DELAY")
    }
    runIn(120, finishOpening)
}

def off() {
	log.trace "OFF was sent"
    // gets the user-defined label for this device
	def doorState = device.currentState("door").getValue()
    log.debug "current state is " + doorState
    // if the current state is open, change the state to close delay. 
    // I don't want to do this if the open command is still timing
    if (doorState == "OPEN") {
        runIn(1, finishClosing)
    }
    else {
    	runIn(10, checkState)
    }
}
def open() {
	log.trace "OPEN command sent"
	sendEvent(name: "door", value: "OPEN DELAY")
    runIn(5, finishOpening)
}

def close() {
	log.debug "CLOSE command sent"
    sendEvent(name: "door", value: "CLOSE DELAY")
	runIn(5, finishClosing)
}
def parse(String description) {
	log.trace "parse($description)"
}

def finishOpening() {
    sendEvent(name: "door", value: "OPEN")
    sendEvent(name: "contact", value: "open")
    log.trace "Contact Open"
}

def finishClosing() {
    sendEvent(name: "door", value: "CLOSED")
    sendEvent(name: "contact", value: "closed")
    log.trace "Contact Closed"
}
def checkState() {
	log.debug "checking state"
	runIn(1,off)
}

There are some simulated contact sensors DH, but all do not allow value change.
But in another hand, using a simulated lock, its possible

Here is the switch I ended up using. It’s just a contact sensor with some delay functions I don’t use. I have one tile that allows manual override to close the contact, but nothing to accidentally open it setting off my alarm. sorry for the confusion.

/**
 *  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 Door Sensor", namespace: "packerprogrammer", author: "Garrett Hensley") {
		capability "Contact Sensor"
		capability "Sensor"
        capability "Actuator"
        capability "Switch"    
        command "timing"
		
		
	}

	// simulator metadata
	simulator {
		}

	// UI tile definitions
	tiles {
		standardTile("contact", "device.contact", width: 2, height: 2) {
			state "open", label: '${name}', icon: "st.contact.contact.open", backgroundColor: "#e86d13"
			state "closed", label: '${name}', icon: "st.contact.contact.closed", backgroundColor: "#00A0DC"
            state "timing", label: '${name}', icon: "st.Health & Wellness.health7", backgroundColor: "#00A0DC"
		}
        standardTile("close", "device.switch", inactiveLabel: false, decoration: "flat") {
			state "default", label:'close', action:"switch.off"
		}

		main "contact"
		details "contact","close"
	}
    preferences {
    	input name: "autoReset", type: "bool", title: "Auto Reset?", description: "Force Sensor to Auto Reset to Closed", required: false, defaultValue: false	
        input name: "resetDelay", type: "number", title: "Reset Delay", description: "Number of Seconds to Hold Open", required: false, defaultValue: 1
        input name: "delayOpen", type: "bool", title: "Delay Open?", description: "Delays Opening of Contact", required: false, defaultValue: false	
        input name: "openDelay", type: "number", title: "Open Delay", description: "Number of Seconds to Delay Open", required: false, defaultValue: 120 
        
	}
}
def on() {
    
    log.debug "ON was sent"
    if (delayOpen == true) {
    	log.debug "Timing"
        sendEvent(name: "contact", value: "timing")
        runIn(openDelay, openContact)
    }
    else {
    	log.debug "Open Contact Without Delay"
    	openContact()
    }
}

def off() {
	log.debug "OFF was sent"
    sendEvent(name: "contact", value: "closed")
    log.debug "Contact is closed"
}

def timing() {
    log.debug "Timing was sent"
    sendEvent(name: "contact", value: "timing")
}
def openContact() {
	
    sendEvent(name: "contact", value: "open")
    log.debug "Contact is open"
    if (autoReset == true) {
    	log.debug "Performing Auto Reset"
    	runIn(resetDelay + 1, off)
    }
}

I can’t tell what device you are using this child with, but quite a lot of off the shelf devices do delays, and would be managed by the device (for example Fibaro devices). This means you turn it on, and it auto turns off after X seconds - would be an easier and more reliable solution to using timings from ST. Just a thought!

I used it with a virtual switch. Like I said this is where I started and don’t use the delays anymore since I had to end up writing a smart app to achieve my goal. I wanted a virtual switch to follow the state of any physical switch. I did want a delay open, but only when the alarm is set. That way when I leave, the virtual device isnt still timing when I set the alarm.

Ill keep the fibaros in mind for future projects. I could use them for this project, but I’d still need the smart app. Do they have a tilt sensor?

Sadly I don’t think they do a tilt sensor natively, but their contact sensor has pins where you can connect other devices to it, and if you put a tilt sensor across these pins it may do what you want.

I found another thread that had others looking at this. Hopefully this is helpful

virtual-alexa-switch & button

Clip from my reply to the other post:
“As of this post Alexa can only uses sensors as triggers (no support for switches) This thing makes it a sensor and a switch at the same time, so it shows up as a sensor in alexa routines and shows as a switch in smartthings). I know this will be helpful for someone like me trying to save some money on color led bulbs. I bought some Merkury $12 LED Color changing bulbs from Walmart (That are awesome btw)”

2 Likes

I am just good enough to be able to follow directions so far and I have a general understanding of some of the things you use to make smarttings do stuff they didn’t bake into it.

I have been trying to create virtual contact sensors so I can make routines on Alexa to do things when conditions are met on the hub that trigger the sensor but to no avail. Specifically, I have a water sensor next to my pool pump and a WiOn (unable to be controlled by smarttings) controlled pool pump. I want to create a " contact switch" that opens when my sensor is wet and another that opens when it gets to freezing temperatures so Alexa will turn the pump off or on.

I found this topic for simulated virtual sensors but when I finally figured out I had to create it in the IDE I did that but I don’t know how to make it change states based on whatever state something else is in.

Is this even possible?

OK. If you take devices that implement the standard Switch capability you find they act as both a ‘sensor’ - they have the switch attribute, and an ‘actuator’ - they have the on and off commands that tell the switch to turn on and off.

If you look at devices that implement the Contact Sensor capability they are just ‘sensors’ - they have the contact attribute. There is nothing to set the attributes because that isn’t something you can normally do with the actual devices.

A Simulated Switch works everywhere because the on and off commands are in the real thing. When it comes to the other Simulated devices, the standard capabilities have to be augmented with custom commands to set the attributes.

For the Simulated Contact Sensor the commands are open and close. The trouble is that these are custom commands and Automations and Smart Lighting and various other apps don’t know about them so can’t call them. WebCoRE is one exception to this as it can see and use the custom commands.

The situation will improve once custom capabilities are widely implemented and the app starts supporting them in Automations.

You will find there are a number of community created simulated/virtual devices that combine a switch with a contact sensor to get around the issue.

1 Like

Thank you very much for the information. I really appreciate it. Would you happen to know a project that combines the switch and sensor thatI could look at using?

I find it odd that my “old” simulated contact sensors are still working. I created new ones today using the stock DTH and the one that @orangebucket listed above. Neither of them work.